What is request weight in the Binance API?

Request weight is the cost Binance assigns to each API endpoint, and its request-weight limit caps the total weight spent from one IP address over a time interval — so a heavy call uses more of the budget than a light one, and the budget belongs to the IP, not to your API key.

This page explains the metering model behind that sentence: the three kinds of limit Binance publishes, how each one is scoped, how the response headers expose your usage, and how to build a client that spends weight deliberately. It deliberately quotes no quotas; those change, and they live in Binance’s own endpoint tables.

Why this matters now

Two misunderstandings cause most weight problems, and neither is about the numbers.

The first is the unit. A client that budgets “requests per minute” will behave unpredictably, because endpoints do not cost the same and the mix of calls changes from minute to minute. The error handling side of that — -1003, and the step from 429 to 418 — is covered in Binance API rate limits and error -1003.

The second is the scope, and it is the one this page is about. Binance states that “the limits on the API are based on the IPs, not the API keys.” Order counts, by contrast, are tracked per account. Those two scopes decide which of your processes can starve which, and no amount of per-key throttling fixes a problem that lives at the IP.

How it actually works

1. Binance publishes the limits in exchangeInfo. The rateLimits array returned by GET /api/v3/exchangeInfo covers three types: RAW_REQUESTS, REQUEST_WEIGHT and ORDERS, each attached to an interval.
2. Every endpoint has a documented weight. The per-endpoint tables in the API docs give it. Look it up for each call you actually make, in the form you make it, rather than assuming calls are interchangeable.
3. Every response reports weight used. The header is X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter), and it reports weight used for the IP. The suffix names the interval, so there can be one header per interval.
4. Successful order responses report order count. The header is X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter), and “the number of unfilled orders is tracked for each account”. Rejected orders “are not guaranteed to have” this header.
5. Going over returns 429; continuing returns 418. 418 is an automatic IP ban. Both carry a Retry-After header in seconds. The -1003 messages say which limit you hit, including “Too much request weight used…” and “Way too much request weight used; IP banned until…”.

USDⓈ-M futures follows the same model: weight tracked per IP, order rate “counted against each account”, repeated 429s escalating to 418, and bans that “are tracked and scale in duration for repeat offenders”. Its limits appear in GET /fapi/v1/exchangeInfo.

Request weight vs order count

	Request weight	Order count
What it meters	The cost of every call	Orders placed
Scope	Per IP	Per account
Where you see it	X-MBX-USED-WEIGHT-… on every response	X-MBX-ORDER-COUNT-… on successful order responses
What spends it fastest	High-weight endpoints, tight polling	Rapid placement, cancel-and-replace loops
Published as	REQUEST_WEIGHT in rateLimits	ORDERS in rateLimits

The scopes produce consequences that are easy to miss:

• Several keys on one server share one weight budget. Giving each bot its own API key isolates permissions and makes attribution easy, but it does not give any of them more weight.
• Separate accounts on one IP share weight but not order counts. They can starve each other of reads while never touching each other’s order limit.
• A read-heavy tool can block an order router. A dashboard, a notebook and a trading process on the same host draw from the same weight pool even with different keys and accounts.
• A missing header is not zero. Because rejected orders may lack the order-count header, a client that only trusts headers will under-count. Keep your own counter and use the header to correct it when it is present.

Request weight vs how other venues meter

Weight is one design among several. Mixing up the models is how a client ported from one venue misbehaves on another; the details are in rate limit models compared.

Venue	Unit	Main scope
Binance	Weight per call, plus order count	Weight per IP; orders per account
Bybit V5	Request count, per endpoint, rolling per second	Per UID, plus a separate per-IP layer
OKX V5	Request count, per endpoint	Per IP (public), per User ID (private), per instrument (trading)
Hyperliquid	Aggregated weight per IP, plus an address allowance earned by volume	Per IP and per address

Bybit reports remaining budget per endpoint in X-Bapi-Limit-Status, X-Bapi-Limit and X-Bapi-Limit-Reset-Timestamp. OKX limits trading endpoints per instrument, shared across REST and WebSocket. Hyperliquid is the closest to Binance on the IP side — requests carry weights, and an exchange request’s weight grows with the length of its batch — but it adds a second, per-address meter for actions that is earned by trading volume, so a new account starts with only its initial allowance.

Where the boundary should sit

• Budget in weight, correct from the header. Keep a local limiter that charges each call its documented weight, and overwrite your estimate with the X-MBX-USED-WEIGHT-… value whenever a response arrives. The estimate keeps you safe before the response; the header keeps the estimate honest.
• Parse the suffix, do not hard-code the header name. The interval is part of the header name, and there may be more than one.
• Put one limiter per outbound IP, not per key. If several processes share an address, either route their calls through one limiter or split the budget between them explicitly.
• Reserve weight for exits. Routine polling should never be able to spend the headroom a cancel needs. Separate read traffic from order traffic.
• On 429, stop the whole IP. Honour Retry-After across every process behind that address, not just the thread that received it. The ban that follows is per IP too.
• Stamp requests after the limiter, not before. A request that waits in your limiter with its timestamp already set spends its time window locally — see what is recvWindow.
• Move continuous data to streams and cache static data. Polling for prices a WebSocket would push, or re-fetching exchangeInfo every loop, are the usual ways weight disappears. See WebSocket vs REST for trading.
• Do not let a model spend the budget unsupervised. A model calling tools re-fetches freely; the server behind it should enforce the limiter, as rate limits in an MCP trading setup describes.

FAQ

What is request weight in the Binance API?

It is the cost Binance assigns to each endpoint. The request-weight limit caps the total weight used from one IP address over an interval, rather than the number of calls, so which endpoints you call matters as much as how often. Per-endpoint weights are listed in Binance’s API documentation and can change.

Is the Binance rate limit per API key or per IP?

Request weight is per IP; Binance states that the limits “are based on the IPs, not the API keys”. Order counts are tracked per account. So several keys on one server share one weight budget, while separate accounts keep separate order counts.

What does the X-MBX-USED-WEIGHT header mean?

It reports how much request weight your IP has used in the interval named by the header’s suffix. It appears on every response, so a client can throttle on actual usage instead of estimating. Successful order responses also carry X-MBX-ORDER-COUNT-…, which reports the account’s order count.

What happens when I exceed the request weight limit?

Binance returns HTTP 429 with a Retry-After header and a -1003 error. Continuing to send requests after that leads to HTTP 418, an automatic IP ban that also carries Retry-After. On USDⓈ-M futures, bans scale in duration for repeat offenders.

Related

• Binance API rate limits and error -1003
• Rate limit models compared
• Rate limits in an MCP trading setup
• What is recvWindow?
• Retrying a failed order is not safe
• Exchange API guides