# Binance API rate limit: weights, order counts and bans

URL: https://fincodelabs.com/en/blog/binance-api-rate-limit · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Category: Exchange APIs · Published: 2026-11-05 · Updated: 2026-11-05

Binance API rate limit: Spot 6,000 and USD-M 2,400 request weight a minute (read 4 Nov 2026), per-account order counts, 429 and 418 bans, tested Python tracker.

**Short answer:** The **Binance API rate limit** is a set of counters rather than one number: request weight per IP address per minute, plus unfilled orders per account over shorter and longer intervals. As read from `exchangeInfo` on 4 November 2026, Spot allows 6,000 weight per minute and USD-M futures 2,400. Going over returns HTTP 429, and continuing after that earns an automatic IP ban (HTTP 418) lasting from 2 minutes to 3 days.

Rate limit trouble rarely shows up in a prototype. It shows up when a second program shares the server's IP address or a restart reloads every symbol at once. The numbers here come from Binance's live `exchangeInfo` endpoints and its official limits documentation, last modified 30 October 2026, all read on 4 November 2026; weights were also measured from response headers on the public test environments and, for USD-M futures, on production's public endpoints.

This is a technical guide, not a recommendation to use Binance or any strategy, and automated trading can lose money. Availability depends on your jurisdiction and the platform's terms. In Turkey, Article 99/A of Capital Markets Law No. 6362 treats activity by foreign-based crypto-asset platforms directed at Turkish residents as unauthorized service provision, and the Capital Markets Board (SPK) has stated that appearing on its list of operating providers does not mean a firm is authorized.

## Binance API rate limit: Spot and futures numbers today

The current limits are whatever `exchangeInfo` returns, so a program should read its `rateLimits` array at startup instead of hard-coding numbers from an article, including this one.

**rateLimits returned by exchangeInfo on 4 November 2026**

| Limiter | Spot | Spot Testnet | USD-M futures | USD-M demo |
| --- | --- | --- | --- | --- |
| `REQUEST_WEIGHT` per minute, per IP | 6,000 | 6,000 | 2,400 | 6,000 |
| `ORDERS` per 10 seconds, per account | 100 | 50 | 300 | 300 |
| `ORDERS`, longer interval, per account | 200,000 per day | 160,000 per day | 1,200 per minute | 1,200 per minute |
| `RAW_REQUESTS` per 5 minutes | 300,000 | 300,000 | Not listed | Not listed |

The test environments differ from production in both directions: the Spot Testnet allows half of Spot's 10-second orders, while USD-M demo allows more weight than USD-M production, so a load test there proves little about the live limit. The Spot enum documentation shows the format of `RAW_REQUESTS` without defining it further. The array is public at `GET /api/v3/exchangeInfo` on Spot and `GET /fapi/v1/exchangeInfo` on USD-M. Spot charges 20 weight for the call, so cache the result.

## Binance REST API rate limit: how request weight works

Every REST call adds its endpoint's weight to a counter kept per IP address, and the counter restarts when the next interval begins.

- **Per IP, not per key.** The Spot documentation states that limits are based on IPs, not API keys, so two bots behind one address share one budget.
- **Public calls count.** The Binance public API rate limit is the same counter. In a test on 4 November 2026, alternating `GET /api/v3/time` between `api.binance.com` and the market-data-only host `data-api.binance.vision` reported used weight 1, 2 and 3, so the two hosts shared a counter. The testnet kept its own.
- **Fixed windows.** The WebSocket API documentation explains that a request at 00:01:23.456 counts toward the 00:01:00 minute and the count returns to zero at 00:02:00. REST behaved the same way in testing: when a new minute began between two calls, used weight fell to 2, the cost of the second call.
- **The header tells you.** Every response carries `X-MBX-USED-WEIGHT-1M`. Trust it over a local estimate, because it includes every other program on that address.

## Binance kline API rate limit and other endpoint weights

Weight depends on the endpoint and often on its parameters, and leaving out `symbol` on the 24-hour ticker costs 40 times as much.

**Request weights from Spot and USD-M documentation read 4 November 2026; items marked measured come from the response header on USD-M production that day, with the same result on the demo host**

| Endpoint | Spot | USD-M futures |
| --- | --- | --- |
| Klines | 2, whatever the `limit` | 1 for `limit` 1 to 99; 2 for 100 to 499; 5 for 500 to 1,000; 10 above 1,000 |
| Order book (`depth`) | 5 up to 100 levels; 25 to 500; 50 to 1,000; 250 to 5,000 | 2 for 5 to 50 levels; 5 for 100; 10 for 500; 20 for 1,000 |
| 24-hour ticker, one symbol | 2 | 1 (measured) |
| 24-hour ticker, no symbol | 80 | 40 (measured) |
| `exchangeInfo` | 20 | 1 |

Check the tables against the header. On USD-M production and demo on 4 November 2026, klines with `limit=100` cost 1 and `limit=500` cost 2, one band lower than the table reads at those exact values, while `limit=101` cost 2 and `limit=501` cost 5. Spot's weights measured on the testnet matched its documentation.

> **Hypothetical example.** A dashboard polls the all-symbol 24-hour ticker every 2 seconds, 30 calls a minute. On Spot that uses 30 x 80 = 2,400 weight, 40% of the budget; on USD-M it uses 30 x 40 = 1,200, 50% of the budget. A backfill of 1,000-candle requests could afford at most 3,000 calls a minute on Spot (6,000 / 2) and 480 on USD-M (2,400 / 5), before anything else on that IP is counted.

## Binance API rate limit for futures

USD-M futures uses the same weight and ban model as Spot, with a smaller budget, its own order limits and more ways for a busy server to answer.

The USD-M general information page, last modified 30 October 2026, says limits are per IP, order limits are per account, and bans scale from 2 minutes to 3 days. It lists four HTTP 503 messages: an unknown error, where the request may have succeeded and must be verified before any retry; Service Unavailable, a failure to retry with exponential backoff, at most 3 to 5 attempts; an internal error, also a failure that you can resend; and `-1008` throttling, where you reduce concurrency and from which close-position, reduce-only and cancel orders are exempt. That page does not mention `Retry-After`, so futures code should handle its absence. Availability of derivatives varies by jurisdiction, and this section only describes the documentation.

## Binance order rate limit: the unfilled order count

The `ORDERS` limiter counts new orders that stay unfilled, per account and across all of that account's API keys, on top of request weight.

- **Windows.** With a limit of 100 per 10 seconds, Binance's rules page describes 100 new orders between 12:34:00 and 12:34:10, then 100 more in the next window. The daily interval resets at 00:00 UTC.
- **Fills give capacity back.** Orders that are partially or fully filled do not count against the limit.
- **Headers.** A successful order response carries `X-MBX-ORDER-COUNT-10S` and `X-MBX-ORDER-COUNT-1D`; rejected orders may not. `GET /api/v3/rateLimit/order` returns the counts but costs 40 weight, so prefer the headers.
- **Going over.** You receive HTTP 429 with `Retry-After` and error `-1015`, whichever key or program sends the order.

Placing and canceling orders with no intention of trading is more than a rate limit problem: it can amount to market abuse, which is prohibited whether done by hand or by a bot. Order entry itself is covered in the [Binance API Python guide](https://fincodelabs.com/en/blog/binance-api-python-trading-bot).

## HTTP 429, 418 and 403: what to do when you are limited

Stop sending from that IP for as long as the server says, because every extra request after a 429 moves you closer to a longer ban.

**Limit responses, per the Spot REST documentation and Binance's API FAQ**

| Response | Meaning | What to do |
| --- | --- | --- |
| HTTP 429 | A request rate limit was broken (`-1003` or `-1015`) | Pause for `Retry-After` seconds across all workers |
| HTTP 418 | IP auto-banned for continuing after 429s; 2 minutes to 3 days | Stop everything until `Retry-After` has passed |
| HTTP 403 | A Web Application Firewall rule was violated: a rate limit violation or a security block | Do not retry in a loop; the FAQ, updated 13 January 2025, says such a ban usually lasts about 5 minutes, may run longer if a request looks malicious, and cannot be lifted early |

The interfaces report the wait differently. On REST, `Retry-After` is a number of seconds. On the WebSocket API, `retryAfter` is a timestamp in milliseconds. Design to stay below the limit rather than trying to get around it, since the exchange's terms govern how its API may be used. HTTP 5XX is a different case, because the order status is unknown; see [Binance API error codes](https://fincodelabs.com/en/blog/binance-api-error-codes).

## A tested Binance API weight tracker in Python

A small client can read the limit from `exchangeInfo`, follow the header, pause at a chosen share of the budget and treat 429 and 418 as a stop for the whole IP.

This runs without keys against public Spot Testnet endpoints (Python 3.11, `requests`). The real calls ran on 4 November 2026; the 429 branch uses a synthetic response, because provoking real limits to test a sample would be poor practice.

```python
import time
import requests

BASE = "https://testnet.binance.vision"      # public endpoints, no key

class RateLimited(Exception):
    pass

class WeightClient:
    """Pause at a share of the weight limit; stop on HTTP 429 and 418."""
    def __init__(self, base=BASE, share=0.8, http=None):
        self.base, self.http = base, http or requests.Session()
        self.resume_at, self.used, self.ceiling = 0.0, 0, float("inf")
        info = self.get("/api/v3/exchangeInfo", symbol="BTCUSDT")
        limit = next(r["limit"] for r in info["rateLimits"]
                     if r["rateLimitType"] == "REQUEST_WEIGHT")
        self.ceiling = int(limit * share)    # leave a reserve for other programs

    def get(self, path, **params):
        wait = self.resume_at - time.time()
        if wait > 0:                         # the whole IP is backing off
            raise RateLimited(f"wait {wait:.0f} s")
        r = self.http.get(self.base + path, params=params, timeout=10)
        self.used = int(r.headers.get("X-MBX-USED-WEIGHT-1M", self.used))
        if r.status_code in (418, 429):
            seconds = int(r.headers.get("Retry-After", 60))
            self.resume_at = time.time() + seconds
            raise RateLimited(f"HTTP {r.status_code}: wait {seconds} s")
        r.raise_for_status()
        if self.used >= self.ceiling:        # resume when the next minute starts
            self.resume_at = time.time() + 60 - time.time() % 60
        return r.json()

client = WeightClient()
client.get("/api/v3/klines", symbol="BTCUSDT", interval="1m", limit=1000)
print("ceiling", client.ceiling, "used after klines", client.used)
client.get("/api/v3/ticker/24hr")            # no symbol: expensive
print("used after all-symbol ticker", client.used)

class Fake429:                               # synthetic response, no network
    status_code, headers = 429, {"Retry-After": "7"}

client.http = type("FakeHttp", (), {"get": lambda self, *a, **k: Fake429()})()
for attempt in range(2):
    try:
        client.get("/api/v3/time")
    except RateLimited as err:
        print("attempt", attempt, err)
```

Output:

```
ceiling 4800 used after klines 22
used after all-symbol ticker 102
attempt 0 HTTP 429: wait 7 s
attempt 1 wait 7 s
```

The 80% share is an illustrative setting, not a figure from Binance. One such client should sit in front of all REST traffic for that IP, and if several processes share the address, keep `resume_at` somewhere they can all read. General retry design is in [crypto exchange API integration](https://fincodelabs.com/en/blog/crypto-exchange-api-integration).

## Binance WebSocket API rate limit and how to use less weight

WebSocket API requests draw on the same per-IP weight as REST, while market data streams have their own limits and are the documented way to avoid polling.

In a testnet run on 4 November 2026, a REST call reported used weight 1, opening a WebSocket API connection and sending `time` took it to 4 (2 to connect, as documented, plus 1), and the next REST call reported 5. Opening a market stream and reading five events added no weight. Streams have different limits, covered in the [Binance WebSocket guide](https://fincodelabs.com/en/blog/binance-websocket-api). To spend less:

- Replace polling with streams for anything live, as Binance's own `-1003` message advises.
- Pass `symbol` to the 24-hour ticker and open-order endpoints; omitting it costs 80 on Spot.
- Stagger restarts and backfills, so a redeploy does not spend a minute's budget in seconds.
- Log used weight as a metric and alert well before the ceiling.

If you would rather commission this layer, the [exchange API integration](https://fincodelabs.com/en/services/exchange-api-integration) page describes such work in general terms; which platforms a project may use depends on the customer's jurisdiction and the platform's terms.

## Frequently asked questions

### What is the Binance API request limit per minute?

As read from exchangeInfo on 4 November 2026, Spot allows 6,000 request weight per minute per IP and USD-M futures 2,400. A call costs its endpoint's weight, not 1, so the number of calls varies.

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

Request weight is per IP address, so several keys on one server share it. Order counts are per account and shared by all of that account's keys.

### Do public endpoints count toward the limit?

Yes. They need no key, but they still use the weight of your IP address.

### How long does a Binance API ban last?

HTTP 418 bans scale from 2 minutes to 3 days for repeat offenders, and the Retry-After header gives the seconds remaining.

### How do I see how much weight I have used?

Read the X-MBX-USED-WEIGHT-1M response header on REST or the rateLimits field in WebSocket API responses. Both include all activity from your IP in the current interval.

## Sources

- [Binance Spot API documentation: REST API (limits, HTTP return codes, endpoint weights)](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md)
- [Binance Developer Docs: General REST API information, including limits (last modified 30 October 2026)](https://developers.binance.com/en/docs/products/spot/rest-api#limits)
- [Binance Spot API documentation: WebSocket API (rate limits, retryAfter, connection weight)](https://github.com/binance/binance-spot-api-docs/blob/master/web-socket-api.md)
- [Binance Spot API documentation: Spot Unfilled Order Count Rules](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/order_count_decrement.md)
- [Binance Spot API documentation: Market Data Only URLs](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/market_data_only.md)
- [Binance Spot API documentation: Enum definitions (rate limiters)](https://github.com/binance/binance-spot-api-docs/blob/master/enums.md)
- [Binance Spot API documentation: Error codes](https://github.com/binance/binance-spot-api-docs/blob/master/errors.md)
- [Binance: Frequently Asked Questions on API (WAF bans, updated 13 January 2025)](https://www.binance.com/en/support/faq/detail/360004492232)
- [Binance Spot exchangeInfo, live rateLimits via the market data host](https://data-api.binance.vision/api/v3/exchangeInfo?symbol=BTCUSDT)
- [Binance Spot Testnet exchangeInfo, live rateLimits](https://testnet.binance.vision/api/v3/exchangeInfo?symbol=BTCUSDT)
- [Binance USD-M Futures: General info (limits, HTTP 503 variants, last modified 30 October 2026)](https://developers.binance.com/en/docs/products/derivatives-trading-usds-futures/general-info)
- [Binance USD-M Futures: Market data REST API (kline, order book and exchangeInfo weights)](https://developers.binance.com/en/docs/catalog/core-trading-derivatives-trading-usd-s-m-futures/api/rest-api/market-data)
- [Binance USD-M Futures exchangeInfo, live rateLimits](https://fapi.binance.com/fapi/v1/exchangeInfo)
- [Capital Markets Law No. 6362, Article 99/A (Turkish, consolidated text)](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6362.pdf)
- [SPK: Announcement on crypto-asset service providers, 5 August 2024 (Turkish)](https://spk.gov.tr/duyurular/basin-duyurulari/2024/kripto-varlik-hizmet-saglayicilara-iliskin-duyuru_05082024)

> This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the [editorial policy](https://fincodelabs.com/en/editorial-policy).

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/blog/binance-api-rate-limit

Cite as: Fincode, "Binance API rate limit: weights, order counts and bans", updated November 5, 2026, https://fincodelabs.com/en/blog/binance-api-rate-limit