specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Binance
providerId: binance
created: '2026-05-04'
# Provenance stamped 2026-08-11: this artifact was written by the API Evangelist
# bulk sweep dated 2026-05-04, not harvested from the provider. See roadmap#35.
method: generated
modified: '2026-05-05'
reconciled: true
tags:
  - Cryptocurrency
  - Exchange
  - Trading
  - Market Data
  - Rate Limiting
description: 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.
sources:
  - https://developers.binance.com/docs/binance-spot-api-docs/rest-api/limits
  - https://www.binance.com/en/binance-api
headers:
  usedWeight: X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter)
  orderCount: X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter)
  retryAfter: Retry-After
responseCodes:
  throttled: 429
  ipBanned: 418
  serviceUnavailable: 503
limits:
  - name: REQUEST_WEIGHT (REST, per IP)
    scope: IP
    metric: varies
    limit: see /api/v3/exchangeInfo rateLimits[]
    notes: 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.
  - name: RAW_REQUESTS (REST, per IP)
    scope: IP
    metric: requests_per_minute
    limit: see /api/v3/exchangeInfo rateLimits[]
    notes: Hard cap on raw request count regardless of endpoint weight; enforced on the source IP.
  - name: ORDERS (per account)
    scope: account
    metric: varies
    limit: see /api/v3/exchangeInfo rateLimits[]
    notes: 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.
  - name: WebSocket connections
    scope: IP
    metric: concurrent_requests
    limit: see WebSocket Streams documentation
    notes: Connection ceilings and per-connection subscription caps documented in WebSocket Streams
      reference; ping/pong required to keep streams alive.
policies:
  - name: Weight model
    description: 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.
  - name: Backoff on 429
    description: 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.
  - name: IP ban escalation (HTTP 418)
    description: 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.
  - name: VIP weight upgrades
    description: Higher VIP accounts receive elevated weight ceilings on a per-account basis; consult
      VIP program documentation for the multipliers in force.
  - name: Order rate independence
    description: Order placement limits are tracked per account, not per IP. Successful fills replenish
      headroom faster than canceled orders.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com