Getting "too many requests" mid-burst: what is actually being counted?
Posted: Sat Oct 31, 2026 10:59 am
A fast news move can go like this. Three entries go out, two get adjusted, one closes, and then the terminal answers "too many requests" and refuses everything for a few seconds. The annoying part is that the rejection usually lands on the one order that mattered most.
Most servers count requests, not trades. A request is anything sent to the trade server: a new order, a modify, a delete, a close, a pending order cancel. Ten small housekeeping messages burn the same allowance as ten real entries. The window is also usually rolling rather than tied to the clock minute, so a burst at 12:00:59 followed by another at 12:01:01 can still trip it.
Some things make the problem worse without being obvious:
- An EA that retries instantly after a failure. Each retry is another request, so one rejection can snowball into a longer lockout.
- Several EAs or scripts on one account sharing a single allowance, each unaware of the others.
- Manual clicking on top of automation, where a double-click on a button counts twice.
The exact limit, and whether it is enforced at all, differs between servers and is rarely published clearly. Support will sometimes confirm a figure if asked directly, though the answer may be vague.
A sensible fix is boring: queue outgoing requests, space them by a fraction of a second, and back off progressively after any rejection instead of hammering. Priority matters as well. A close should always jump ahead of a trailing adjustment.
Has anyone found the real threshold on a broker by testing, and how did the rejection behave when it hit?
Most servers count requests, not trades. A request is anything sent to the trade server: a new order, a modify, a delete, a close, a pending order cancel. Ten small housekeeping messages burn the same allowance as ten real entries. The window is also usually rolling rather than tied to the clock minute, so a burst at 12:00:59 followed by another at 12:01:01 can still trip it.
Some things make the problem worse without being obvious:
- An EA that retries instantly after a failure. Each retry is another request, so one rejection can snowball into a longer lockout.
- Several EAs or scripts on one account sharing a single allowance, each unaware of the others.
- Manual clicking on top of automation, where a double-click on a button counts twice.
The exact limit, and whether it is enforced at all, differs between servers and is rarely published clearly. Support will sometimes confirm a figure if asked directly, though the answer may be vague.
A sensible fix is boring: queue outgoing requests, space them by a fraction of a second, and back off progressively after any rejection instead of hammering. Priority matters as well. A close should always jump ahead of a trailing adjustment.
Has anyone found the real threshold on a broker by testing, and how did the rejection behave when it hit?