Rate Limiting | Binance

Request-Weight Budget

Binance meters usage per IP address as a request weight, not a raw call count — different endpoints cost different weights. The node tracks this against Binance:WeightLimitPerMinute (default 6000, matching Binance's documented standard-tier limit for the rolling 1-minute window).

Proactive Throttling

BinanceRateLimitHandler (an HttpClient DelegatingHandler) reads the X-MBX-USED-WEIGHT-1M header Binance returns on every response. Once usage crosses Binance:ProactiveThrottleThreshold (default 0.8, i.e. 80% of the weight budget), it starts inserting a delay before the next request — slowing the node down before Binance's own reactive rate limiting (429) would even trigger.

Setting	Default	Effect
`WeightLimitPerMinute`	6000	The budget the proactive throttle measures usage against.
`ProactiveThrottleThreshold`	0.8	Fraction of the budget at which proactive delay kicks in.

Reactive Handling: 429 and 418

HTTP Status	Meaning	Handler behavior
429 (rate limit exceeded)	You've exceeded a Binance rate limit despite proactive throttling.	Retried automatically, up to 3 times, honoring the `Retry-After` response header.
418 (IP auto-banned)	Binance has temporarily banned your IP for continued rate-limit violations after repeated 429s.	Hard-fails immediately — no retry. Binance's own guidance is that retrying during a ban makes it worse; the handler surfaces a `BinanceIpBannedException` instead.

BinanceIpBannedException carries the ban's Retry-After duration on the exception itself (Binance doesn't put it in the response body). BinanceErrorMapper surfaces it directly in the error message as BINANCE_IP_BANNED, e.g. "... Retry after 120s." — see Error Codes.

Order-specific limits are separate: the request-weight budget above governs overall API traffic. Order placement/cancellation also has its own, tighter per-order-count limits — check them with account.getOrderRateLimit before a burst of order calls.