Server Request Ceiling
Also known as: request cap, API call ceiling, request budget, call quota
What is it?
A server request ceiling is the maximum number of API calls a venue will accept from one account or key in a given window, and every call your automation makes spends part of it. The number is published and unforgiving. A venue might allow 1,200 weighted requests per minute per key, where a price poll costs 1, an order placement costs 2, and a full order-book snapshot costs 20. A bot polling six symbols every second already spends 360 of that budget on prices alone, before it has placed a single order.
-
Price polling, 6 symbols 360 / 120030% of limit used Before a single order is placed
-
Order-book snapshots 400 / 120033% of limit used 20 a minute, weight 20 each
-
Order placement and amends 392 / 120033% of limit used Manages the open positions
-
All three, in a volatile minute 1152 / 120096% of limit used One burst from rejection
Go over the ceiling and the venue does not queue the extra calls - it returns an error, and repeated breaches usually escalate from a rejected call to a timed key ban measured in minutes. The reason this matters more than it sounds is what gets rejected. Request budgets are spent evenly across a quiet market and consumed fastest exactly when volatility spikes, because that is when a bot re-checks prices, re-prices orders, and tries to close positions. The call that fails is therefore far more likely to be an exit than an entry.
Designing to sit well under the ceiling, and reserving headroom for order management rather than polling, is what keeps the ceiling from becoming a risk to open positions. Your capital is at risk.
Why it matters: Bots spend their request budget fastest during volatility, so a ceiling breach usually rejects an exit rather than an entry - the call you least want to lose.
Requests per minute = symbols x polls per minute x weight per call
A rejected call during a fast move can leave a position without its intended exit, which is a live risk rather than a missed opportunity.
Real-world example
A bot polling six symbols once a second spends 360 of a 1,200-weighted-request minute on price checks alone, leaving 840 for every order it wants to place or amend.
How SignalBots handles it
SignalBots pushes each signal to your platform as it is published instead of asking your terminal to poll for it, so your request budget stays available for the orders you actually place. See /risk-warning.
Pro tip
Budget the ceiling in two parts - a capped allowance for market data and a reserve that only order management may spend - so a data loop can never starve an exit.
Common pitfalls
Sizing the loop against the average request rate. Ceilings are breached in the busy second, not the quiet minute, so the peak rate is the only number that matters.
Frequently asked questions
What happens the moment I exceed the ceiling?
The venue rejects the call with an error rather than delaying it, and most venues escalate repeated breaches into a temporary key ban. Assume rejection, not a queue, and handle the error path explicitly.
Do all API calls cost the same?
No. Most venues weight them - a single price check might cost 1 while a deep order-book snapshot costs 20 or more. Counting raw calls instead of weight is the usual reason a bot breaches a limit it thought it was under.
Is the ceiling per key or per account?
It varies by venue, and some apply both. Running two bots on one key halves each one's usable budget, so check whether separate keys give separate ceilings before splitting strategies.
How does a push feed change the arithmetic?
A streaming or webhook feed delivers updates without a request per update, so market data stops consuming the budget and the ceiling is spent almost entirely on orders.
How much headroom should I leave?
Enough that a burst of order activity during a fast move cannot reach the limit. Sizing steady-state usage at a fraction of the ceiling and reserving the rest for order management is the common approach. Your capital is at risk.
Trading involves substantial risk of loss. Historical and backtested results do not guarantee future performance. Read the full risk warning.
