Binance · Rate Limits

Binance Rate Limits

Binance applies a weight-based rate limit model rather than a flat per-second cap. Each REST endpoint carries a weight; the sum of weights consumed in a rolling window must stay below the per-IP and per-account ceilings exposed by /api/v3/exchangeInfo. Limits are enforced primarily on the source IP for REST traffic and on the account/key for order submission. Exceeding limits returns HTTP 429; repeat violations escalate to HTTP 418 IP bans (2 minutes up to 3 days). Limits are higher for VIP accounts but the documented ceilings are the floor that all clients should plan against.

Binance Rate Limits is the machine-readable rate-limit profile for Binance on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring varies, requests_per_minute, and concurrent_requests.

The profile also includes 5 backoff/retry policies defined and response codes documented for throttled, ipBanned, and serviceUnavailable.

Tagged areas include Cryptocurrency, Exchange, Trading, Market Data, and Rate Limiting.

4 Limits Throttle: 429
CryptocurrencyExchangeTradingMarket DataRate Limiting

Limits

REQUEST_WEIGHT (REST, per IP) IP
varies
see /api/v3/exchangeInfo rateLimits[]
Weight ceiling published per endpoint; sum of weights consumed in the rolling window cannot exceed the published ceiling. Track current usage via X-MBX-USED-WEIGHT response headers.
RAW_REQUESTS (REST, per IP) IP
requests_per_minute
see /api/v3/exchangeInfo rateLimits[]
Hard cap on raw request count regardless of endpoint weight; enforced on the source IP.
ORDERS (per account) account
varies
see /api/v3/exchangeInfo rateLimits[]
Per-account order placement ceilings (typically per-10-second and per-day windows). Inspect via GET /api/v3/rateLimit/order. Tracked separately from REST weight.
WebSocket connections IP
concurrent_requests
see WebSocket Streams documentation
Connection ceilings and per-connection subscription caps documented in WebSocket Streams reference; ping/pong required to keep streams alive.

Policies

Weight model
Each REST endpoint declares a weight; clients must aggregate consumed weight against the per-IP ceiling published in /api/v3/exchangeInfo rather than counting requests.
Backoff on 429
A 429 response includes a Retry-After header in seconds; clients must back off until that interval elapses. Continuing to send requests during the back-off window is interpreted as abuse and triggers an IP ban.
IP ban escalation (HTTP 418)
Repeatedly violating rate limits and/or failing to back off after receiving 429s results in an automated IP ban. Ban duration scales from 2 minutes up to 3 days for repeat offenders; the Retry-After header indicates expiry.
VIP weight upgrades
Higher VIP accounts receive elevated weight ceilings on a per-account basis; consult VIP program documentation for the multipliers in force.
Order rate independence
Order placement limits are tracked per account, not per IP. Successful fills replenish headroom faster than canceled orders.

Sources