WebRequest APIs, bot security, and why remote copiers are risky
Understand the security trade-offs of sending bot or copier data over HTTP APIs from MQL5.
Lesson outcomes
- Know what WebRequest does and why allow-listed URLs matter.
- Design API calls without exposing secrets in code or logs.
- Recognise the extra risk of remote copier infrastructure.
Workshop lab
Complete the demo, notebook, platform, or code task before treating the lesson as finished.
Evidence pack
Keep screenshots, exports, logs, calculations, or code versions in a dated learning folder.
Pass standard
You should be able to explain the failure modes, show your work, and name the stop rule.
Free education, not signals. This lesson is part of EarnSouthAfrica's free forex course. It does not tell you what to buy or sell, it does not promise income, and it should be practised on a demo account before any real-money decision.
A local file copier is one learning path. A remote copier that sends events through an API is another. Remote systems can support multiple devices, dashboards, and account linking, but they also introduce privacy, uptime, security, and abuse risks.
MQL5 WebRequest is powerful enough for legitimate integrations, but power is not the same as safety. A beginner should understand what is being sent, where it is going, and how the terminal grants permission.
What you should be able to do after this lesson
- Know what WebRequest does and why allow-listed URLs matter.
- Design API calls without exposing secrets in code or logs.
- Recognise the extra risk of remote copier infrastructure.
What WebRequest changes
The official MQL5 WebRequest documentation says requests go to specified servers and that required server addresses must be added to allowed URLs in platform options. That permission step is important. It prevents random EAs from silently contacting arbitrary servers without user configuration.
- Use HTTPS endpoints only.
- Do not put account passwords or bank details in API payloads.
- Use short-lived tokens or revocable keys where possible.
- Log request status without dumping secrets.
- Set timeouts and handle failures gracefully.
Remote copier risk
A remote copier can fail because of network outage, server outage, delayed events, duplicated events, token leaks, wrong symbol mapping, database bugs, or malicious access. That is why receiver-side risk limits still matter even if the provider and server are trusted.
If someone sells a remote copier and asks for your main trading password, remote desktop access, or personal documents without a clear regulated reason, walk away. Copying trade events does not require surrendering your financial identity to a stranger.
API design checklist
- Use a provider endpoint for publishing normalized trade events.
- Use a receiver endpoint for pulling only authorised provider streams.
- Sign or authenticate requests.
- Reject duplicate, old, malformed, or unauthorised events.
- Keep an audit trail that the user can export.
Academy-grade study plan
Automation is software engineering under financial pressure. The lesson standard is not 'the code compiles'; it is that the logic, risk controls, logs, tests, and failure states are explicit before the EA is trusted even on demo.
| Course element | What you must produce |
|---|---|
| Primary artifact | EA design specification |
| Lesson focus | WebRequest APIs, bot security, and why remote copiers are risky |
| Working environment | Demo account, notebook, exported platform data, or local code sandbox. Never live funds for first practice. |
| Completion standard | You can explain the concept, reproduce the exercise, identify failure modes, and show evidence without relying on a seller's claims. |
Instructor workflow
Use this workflow as if an instructor were marking the lesson. The important question is not whether the topic sounds familiar. The question is whether your notes, screenshots, calculations, logs, or code prove that you can apply webrequest apis, bot security, and why remote copiers are risky under controlled conditions.
- Write the strategy and safety rules in plain language before opening MetaEditor.
- Separate signal generation, position sizing, order execution, trade management, logging, and emergency stop logic.
- Use magic numbers, symbol filters, spread limits, max-trade limits, and daily-loss limits from the first prototype.
- Treat every code change as a new version that needs a new demo test record.
Worked case study: EA opens repeated trades on every tick
A beginner EA compiles and appears to work, but it opens several positions because the entry condition remains true across many ticks. The paid-course response is to add state management: new-bar checks, open-position checks, magic-number filtering, max-trade limits, and logs that explain why a trade was allowed or rejected.
After reading the scenario, write the decision you would make before checking the suggested workflow above. Then compare your decision with the operating model. The gap between those two answers is the part of the lesson that deserves another demo repetition.
Professional template
Complete this template in your own notebook. A paid course would normally hide this kind of operating document behind worksheets; here it is part of the free lesson.
| Field | Standard |
|---|---|
| Requirement | Plain-language rule that a non-programmer could review. |
| MQL5 component | Function, event handler, class, or input used to implement the rule. |
| Safety gate | Condition that prevents oversized, duplicated, stale, or forbidden trades. |
| Test evidence | Compiler result, Strategy Tester report, forward-demo log, and versioned settings file. |
Failure-mode lab
Paid courses often sell confidence. A serious course teaches you how the idea breaks. Before continuing, test the failure modes below on demo, paper, or code review. If you cannot describe the failure, you are not ready to trust the concept.
- Confusing a compiling EA with a tested EA.
- Forgetting that OnTick can fire many times while the same condition remains true.
- Hard-coding risk, symbol names, or trade volume without receiver/account context.
- Removing logs because they look messy, then being unable to explain behaviour later.
Evidence pack and pass standard
Do not mark this lesson complete because you read it. Mark it complete only when you can show the evidence below. Keep the files in a dated folder so your learning history survives platform updates, memory gaps, and sales pressure.
- A one-page note explaining webrequest apis, bot security, and why remote copiers are risky without sales language or copied definitions.
- A screenshot, export, calculation, log, or code file that proves the practical work was completed on demo.
- A written stop rule that says when this topic must not be used with real money.
- A versioned EA specification with inputs, risk gates, and known limitations.
- A demo test folder with compiled file, settings, report, journal logs, and change notes.
Assessment rubric
| Level | What it looks like |
|---|---|
| Not ready | You can repeat the vocabulary but cannot complete the demo task, calculate the risk, explain the failure mode, or show evidence. |
| Course pass | You can complete the practical task on demo, explain the decision rules, show evidence, and name the conditions where the idea must not be used. |
| Strong pass | You can teach the concept to someone else, find edge cases, document a rejected example, and improve the template without weakening risk controls. |
Advanced homework
- Add one safety gate, then create a test that proves the gate blocks a bad trade.
- Refactor one EA idea into signal, risk, execution, and logging sections.
- Write an incident report for a demo EA failure as if it happened in production.
Practical drill
Do this lesson as a controlled exercise, not as a reason to trade live. Open a demo account or notebook, write the lesson title, and record what you changed, clicked, calculated, or checked. If the lesson includes code, compile it only in a demo environment and keep the original version unchanged so you can compare edits safely.
- Write a one-paragraph explanation of webrequest apis, bot security, and why remote copiers are risky in your own words.
- Take one screenshot or note that proves you completed the platform, maths, research, or code task.
- Record one risk rule that would stop you from using this idea with real money.
- If anything feels unclear, repeat the lesson before moving to the next module.
How scammers misuse this topic
Scammers often take real concepts and wrap them in urgency. They may use platform jargon, bot screenshots, copied profit charts, or official-sounding language to make a paid offer feel safe. A real concept is not the same as a safe offer. Before paying anyone, ask whether you can verify the provider, reproduce the calculation, test the claim on demo, understand the risk, and walk away without pressure.
Checkpoint before continuing
- You know where allowed WebRequest URLs are configured.
- You can name at least five remote copier failure modes.
- Your design keeps receiver risk limits local.
Official references
These lessons are written as free education. When platform features or rules matter, verify against the official source before using real money.
Risk note: leveraged forex and contracts for difference can lose money quickly. EarnSouthAfrica is an educational publisher, not a broker, adviser, signal provider, or money manager.
Keep exploring
Read the latest guides, take the side-hustle quiz, or contact the editorial desk if you spot a correction.