API Rate Limits and Order Weights: Why Your Script Gets Throttled

Two budgets that fail differently

A throttled script usually has one of two problems: it asks for too much market data, or it places too many orders. Binance measures the first in request weight per IP and the second in unfilled orders per account. Fixing the wrong one produces a script that still fails, because adding an API key does not add weight headroom and lowering request weight does not lower the order count.

The distinction matters most for automation. A market-making loop that quotes and cancels all day is not request-heavy in the way a depth scraper is, but it can exhaust the order budget while trading almost nothing. A read-only dashboard can be the opposite: no orders at all, and a wall of 429s by mid-morning.

The limits Binance publishes

The rateLimits array in GET /api/v3/exchangeInfo is the authoritative list for the moment it is called. On 2026-10-25 it returned four entries for the spot API:

Weight is not the same as a request count. Each endpoint carries a weight, and heavier endpoints consume more of the minute. The order book is a clean example: GET /api/v3/depth costs 5 weight at 1–100 levels, 25 at 101–500, 50 at 501–1,000 and 250 at 1,001–5,000. A loop that pulls 5,000 levels spends 250 of the 6,000 weight on every call, so 24 calls exhaust the minute before the script reads anything else.

The order limit is counted differently again. Binance’s unfilled order count documentation states that orders which are partially or fully filled do not count against the rate limit. What counts is the order that sits on the book. This is why a maker strategy that cancels frequently can be throttled while a taker strategy of similar notional trades freely, and why the FAQ frames the venue’s view in terms of conversion rate and traded weight per order.

Two response headers make the budget visible without guessing: X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter) on every request, and X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter) on successful order responses. There is also GET /api/v3/rateLimit/order for the unfilled order count. A client that ignores these and estimates from its own request log will drift out of sync with the server.

The limits OKX publishes

OKX separates its limits by authentication. Public unauthenticated REST calls are limited by IP address. Private REST calls are limited by User ID, and sub-accounts have individual User IDs, so a sub-account is a separate bucket rather than an extension of the master’s.

The per-endpoint rules are explicit. Placing an order is limited to 60 requests per 2 seconds with a rule of User ID plus Instrument ID. Retrieving an order book is limited to 40 requests per 2 seconds by IP. Trading limits are shared across REST and WebSocket, and placing, amending and canceling are counted independently.

On top of the per-endpoint rules, OKX applies a sub-account cap: 1,000 new and amendment order requests per 2 seconds. Batch requests count each order individually, and the per-instrument rules continue to apply in parallel. OKX documents the higher-tier fill-ratio adjustments separately for VIP5 and above; the base number is the one a new integration should design against.

The responses you will see

Binance uses HTTP 429 when a request rate limit is broken and HTTP 418 when an IP has been auto-banned for continuing to send after 429s. The 418 ban is tracked and scales from 2 minutes to 3 days for repeat offenders, and both responses carry a Retry-After header in seconds. A 403 is a different failure: the documentation attributes it to a WAF rule, which the API FAQ says typically lasts around 5 minutes.

The JSON code is more specific than the status. -1003 TOO_MANY_REQUESTS covers three documented cases: too many requests queued, too much request weight used with the current limit printed, and too much weight used with the IP banned until a timestamp. Those are three different situations, and only the first is worth a short retry. Rejections that are not about rate at all — filters, permissions, insufficient balance — follow a different path; why an exchange rejects your order covers those.

OKX returns 50011 when a rate limit is reached, with the message directing the client to throttle. 50061 is the sub-account order cap. 51513 is a different constraint: an amend request submitted while three amends are already in progress on the same order. A generic retry handler that treats all three as “busy” will retry the amend that the venue has already refused on a structural rule.

There is also a category that no counter shows. Binance’s API FAQ describes machine-learning limits based on trading behavior — repeatedly one-upping the best bid or ask, creating and canceling orders without executing, low conversion rate — with restrictions applied to accounts and lasting from 5 minutes to 3 days. A script can be inside every published number and still be restricted for the pattern it creates.

Backoff that drains the queue

The goal of backoff is not to wait. It is to stop adding work to a queue that is already full.

1. Honor Retry-After before your own timer. The venue knows when the window resets; your exponential curve does not. If the header says 37 seconds, sleeping 1, 2, 4 and 8 seconds first only adds requests to a closed door.
2. Never retry a 418 in a loop. The ban has a deadline. Sleep until it, then resume at a reduced rate. Binance documents that repeated violations extend the duration, so a retry storm is a self-inflicted longer outage.
3. Use full jitter. When several workers share one IP, identical sleep intervals reconverge into a new burst. Randomize the wait across the interval.
4. Track the budget locally. Parse X-MBX-USED-WEIGHT on every response and keep a token bucket that matches the venue’s interval. Do not infer weight from request count.
5. Separate queues by purpose. Market data, order entry and cancellation should not compete for one worker pool. When the budget tightens, cancels go first, then order entry, then reads.
6. Use client order IDs that survive a retry. A timeout is not a failure; Binance documents 5XX responses as having an unknown execution status. Reconcile by client order ID before resending, the same way an execution report reconciles fills after the fact.
7. Prefer streams to polling. Binance’s own error text suggests WebSocket streams for live updates to avoid polling the API. A user data stream replaces a per-order status poll with an event.

Weight is a design decision

Most weight problems are decided before the first request is sent. A dashboard that loads 5,000 depth levels to draw a sparkline is spending 250 weight per refresh for data it will discard. The spread, depth and slippage explainer shows how much of that depth a market order actually consumes, which is usually a small fraction of the window. A bot that polls every open order individually is paying a per-request cost for information the user data stream already pushes.

The practical reductions are unglamorous: request only the depth you display, cache reference data that changes daily rather than per request, batch cancels where the venue documents a batch endpoint, and keep one in-flight request per endpoint instead of fanning out. On OKX, the documentation explicitly suggests separate sub-accounts when a single account’s request rate is the constraint, because each sub-account has its own User ID and its own bucket.

None of this creates headroom that the venue did not grant. It stops a script from spending headroom on work that produces nothing.

Measure the thing that is actually limited

Log the endpoint, the weight, the status code, the JSON code, Retry-After and the used-weight header for every request. Then compute weight per minute and unfilled orders per interval, not requests per second.

Alert on the first 429. By the time a 418 arrives, the incident is already in progress and the remaining question is how long it lasts. After the incident, replay the log against the published table: the endpoint that consumed the budget is usually visible in the first five minutes, and it is rarely the endpoint the developer suspected.

Risk note. All numbers in this article were read from Binance’s Spot API documentation and live exchangeInfo response, Binance’s API FAQ, and OKX’s API documentation on 2026-10-25. Limits are changed by the venues without notice, and account-level limits can be tighter than the published table. Nothing here is investment advice.