WebRequest in an MT5 EA: the URL list, the freezes it can cause, and why the tester ignores it

[Fairman]

WebRequest in an MT5 EA: the URL list, the freezes it can cause, and why the tester ignores it

WebRequest from an EA, for Telegram alerts, a news feed or a webhook, has a few quirks that tend to show up at the worst time.

1. The address has to be added under Tools, Options, Expert Advisors, in the list of allowed URLs. Without it the call fails and returns -1, and GetLastError tells you why. The entry is the base address with the scheme, for example https://api.telegram.org.

2. It's synchronous. The EA waits until the server answers or the timeout you gave, in milliseconds, runs out. A 5000 ms timeout against a slow server is five seconds in which that EA does nothing else, and it can miss ticks on that chart.

3. Called from an indicator it raises error 4014, since the function isn't allowed there. It belongs in EAs and scripts.

4. It doesn't work in the Strategy Tester. Whatever sends your alerts can't be tested there.

Practical habits: keep timeouts short, 1000 to 2000 ms for alerts, so a slow server costs a second instead of five. And put alerts in a separate small EA on its own chart where possible, because each chart's EA runs in its own thread, and a blocked alert helper then can't hold up the trading EA.

[FXS HongKong Scalper]

The synchronous nature is the main risk. One option is to move WebRequest calls into a separate EA or a service in MT5, which runs on its own thread and does not block trading logic. The trading EA can write messages to a file or a global variable, and the service sends them. That keeps OnTick fast even if a server is slow. In Asia, servers in other regions can be slow to respond at times, so keeping timeouts short also helps.

[Fairman]

The allowed URL list belongs to the terminal installation, not the EA. Moving the EA to a VPS, or running a second terminal for another account, doesn't carry the list across, so it has to be added again in each one. It's an easy thing to forget on a new machine, and the symptom is just a -1 from WebRequest with nothing in the chart to say why. Writing the required addresses in the EA's description or a readme next to the file makes setup on a new terminal a checklist item, and printing GetLastError after any failed call puts the reason into the Experts log. On a VPS rebuilt from an image the list may come back empty, so have the EA print a clear message the first time WebRequest returns -1, naming the URL it tried.

[Amanhasnoname]

The freeze issue bit me during a Telegram alert setup on a VPS. I had a 5000 ms timeout and one evening the Telegram endpoint was slow for a while. The trading EA on that chart sat waiting on each alert call and missed a trailing stop update on a GBPUSD position that reversed fast. It only cost me a few pips, but it was enough to make me move all alerts out of the trading code.

What I ended up with is close to the service approach described above. The trading EA writes one line per message into a small text file in the common folder, and a separate service reads that file every couple of seconds, sends anything new, and marks it as sent. If the service hangs or the server is down, the worst that happens is the alerts arrive late.

The tester limitation was the other surprise. I'd built a backtest that relied on alert logic being reached, and the call quietly failed there. Now I wrap WebRequest in a function that checks MQLInfoInteger for tester mode first and just prints the message to the journal instead.

[Fairman]

The cost of a block depends on what the market is doing. Illustrative: a chart that gets 3 ticks a second and an alert call that blocks for 5 seconds means about 15 ticks go past without OnTick running on them. In a quiet minute nobody notices. During a news second, with 30 ticks a second, 150 ticks pass while a trailing stop update waits for a web server in Frankfurt to answer. That's the moment you least want it. If the alert has to be sent from the trading EA, send it after the order and the stop have been handled, never before them.

[Fairman]

Telegram's bot API documents limits of about one message a second to a single chat and no more than 20 messages a minute to the same group. An EA that alerts on every tick or every bar close can reach them, after which the server answers with HTTP 429, Too Many Requests, and asks you to wait. WebRequest returns the HTTP status code, so the EA can check for 429. Queue messages, send at most one a second, and merge repeated alerts into one line with a count. Treat any status other than 200 as a failure and log it, rather than assuming the message arrived.

[Fairman]

Since the tester can't run WebRequest, wrap it in a function that checks MQLInfoInteger(MQL_TESTER) and returns without sending when it's true. Otherwise the tester run fills with errors. Keep the bot token and chat ID as inputs, not typed into the source, because source files and .set files get shared. Inputs also show in screenshots of the Inputs tab and may appear in logs. If a token ever gets pasted into a forum post, it should be treated as burnt, and revoked through BotFather, which issues a new one in seconds.