A bot is running and the exchange API suddenly starts returning errors whose text says nothing about the market. The bot usually does not read it either: it sees that the order failed to send, retries, and gets refused again. Every retry pushes a little further past the limit and the loop feeds itself.
The limit is weight, not request count
Most exchanges do not run a simple “how many requests a minute” counter. Each endpoint carries a weight, and the per-minute budget drains through those weights.
The difference is large in practice. A single price query might cost one unit while a call pulling the full depth of the order book costs fifty, which means the sentence “I only send ten requests a minute” says nothing at all about the budget. Which calls you send does.
There is a second layer too: on some exchanges a separate, tighter counter runs for order placement. Filling the data budget can eat into your right to send orders.
What happens when you cross it
Three stages, each harsher than the last.
Refusal. The request comes back with a 429. Usually a wait period comes with it.
Temporary ban. If the behaviour continues, your IP address is blocked for anything from a few minutes to a few hours, and through that entire window you cannot touch an open position. The market does not wait.
Permanent flagging. After repeated violations the API key can be restricted, and reversing that runs through support.
The second stage is the real risk. The bot loses money not because it cannot pull data but because it cannot close a position.
How to write the retry
Retrying at a fixed interval makes the problem bigger. The right shape is exponential backoff: the wait doubles on every attempt, with a small amount of randomness on top.
The randomness matters. Several components hitting the limit at once will, if they retry on the same interval, hit it together again.
Set a ceiling too. After five attempts the bot should stop retrying and raise an alert, because nothing suggests the sixth will succeed.
Keep the order path separate
One of the most practical protections: if data pulls and order placement share a budget, put a cap on the data side.
How many calls a minute your indicators need can be known in advance: fix that number, reserve the whole of the remaining budget for orders, and it becomes impossible for an ordinary chart refresh loop to block a stop order from going out. One line of configuration.
The one number to watch
Exchanges report the remaining budget in response headers. Log that value and track the peak usage per minute.
Once usage starts crossing seventy per cent of the ceiling, you will hit the limit on the next market move, because a bot queries more often when volatility rises. Watching that number is far cheaper than learning the limit live.
