Crypto exchange API rate limits: what error 429 means and how to stay under it

HTTP 429 means you have sent too many requests in a given time, and the server is asking you to slow down. It is not an outage. Each exchange counts requests differently: Binance uses a weight for each endpoint and bans IP addresses that keep going after a 429, Bybit blocks an IP that passes 600 requests in five seconds, and OKX sets limits per endpoint and returns error code 50011. Staying under the limit means reading the response headers, backing off properly and using WebSockets where you can.

What a 429 actually means

HTTP 429 Too Many Requests is a standard status code, defined for exactly this situation. The MDN reference describes it as the client having sent too many requests in a given amount of time, and notes that a Retry-After header may tell you how long to wait. A rate limit may apply to a whole server or to one resource, and it is often based on your IP address, although it can also be tied to an application or user.

It is a useful message rather than a failure. It tells you the service is working, that you have been recognised, and what to do next. When we measure availability on this site, we keep a separate category for rate limiting, so that we do not report an exchange as down merely because a request was throttled.

How Binance counts: request weight and IP bans

Binance's futures API documentation describes a weight system. Each route has a weight, and heavier endpoints, or ones that handle multiple symbols, cost more. Your limit is on total weight per interval, rather than a simple count of requests. The current limits appear in the rateLimits array of /fapi/v1/exchangeInfo.

Key points from the documentation:

• Every response includes X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter), showing the current used weight for your IP.
• A 429 is returned when either rate limit is exceeded.
• Repeatedly exceeding limits, or failing to back off after 429s, results in an automated IP ban with status 418.
• Bans scale in duration for repeat offenders, from 2 minutes to 3 days.
• The IP limits are based on the IP address and not on the API key, so several programs on one machine share a single budget.
• Order rate limits are tracked separately, and order responses include their own count headers.

How Bybit counts: per IP and per user

Bybit's v5 documentation describes two layers. At the IP layer, you are allowed 600 requests within a five-second window per IP by default, for traffic to its main API hostnames. If you exceed it, you get the error "403, access too frequent", and the documentation says you should stop all HTTP sessions and wait for at least 10 minutes, after which the ban is lifted automatically. Note that this is a 403, not a 429, which catches people out.

At the API layer, limits apply to each user over a rolling window, and exceeding them returns retCode 10006 with "Too many visits!" in the JSON. The response headers report your position:

• X-Bapi-Limit-Status shows your remaining requests for the current endpoint.
• X-Bapi-Limit shows your current limit for that endpoint.
• X-Bapi-Limit-Reset-Timestamp shows when your limit resets, if you have exceeded it.

Bybit also advises not to run an application at the very edge of these limits, because unusual network activity could cause an unexpected violation. WebSocket connections have their own limits.

How OKX counts: per endpoint and per instrument

OKX's API documentation says that a rejected request returns error code 50011, and that the limit is different for each endpoint and is listed with each endpoint's details. Public unauthenticated REST limits are based on IP address, and WebSocket login and subscription limits are based on the connection. For trading APIs, placing, amending and cancelling orders have independent limits, generally defined per instrument and shared between REST and WebSocket.

The lesson across these three is that you should not assume one exchange's rule on another. The status code, the unit that is counted and the penalty can all differ, and all of them change over time, so go back to the current documentation.

Why you hit limits without meaning to

Most rate limit problems do not come from a single busy loop. They come from less obvious causes.

• Shared IP addresses. Multiple bots, a cloud NAT gateway or a shared VPN all count against one address. Your neighbours can consume your budget.
• Heavy endpoints. Fetching all tickers or deep order books can cost many times what a single-symbol request does. Ten of those may equal hundreds of simple calls.
• Retry storms. A brief failure causes every worker to retry at once. That burst pushes you into a 429, which triggers more retries.
• Restart loops. A program that reloads its state at startup, and that crashes and restarts repeatedly, can use its whole budget just starting up.
• Polling for what a stream can provide. Asking for the price every second on 50 symbols is 3,000 requests a minute, and a WebSocket can deliver the same data with far less cost.

How to back off properly

When you get a limit response, the correct behaviour is simple and worth implementing just once, in one place.

• Stop sending to that exchange for the required time. If there is a Retry-After header or a reset timestamp, follow it. Otherwise wait, starting at a second or so.
• Use exponential backoff with jitter. Double the wait after each consecutive failure, up to a cap, and add randomness so that several workers do not all retry at the same moment.
• Share the limiter between workers. One token bucket per IP and per exchange, shared across all processes on that address, is far more effective than each worker guessing on its own.
• Track usage continuously. Read the used-weight headers on each response and slow down as you approach the limit, rather than waiting to be told.
• Treat 418 and IP bans as a stop signal. Stop and alert a human. Continuing lengthens the ban.

How to use fewer requests

The cheapest request is the one you do not send.

• Use WebSockets for market data and account updates. One stream replaces constant polling, and updates arrive sooner too.
• Cache slow-changing data. Contract specifications and fee schedules change rarely. Fetch them occasionally rather than on every run.
• Use batch endpoints with care. They can save many requests, but check their weight, since they cost more per call.
• Request only the depth you need. A deep order book request costs more, and many tasks need only the first few levels.
• Avoid polling order status in a loop. A user-data stream tells you when an order fills.

If you only need funding rates or reliability figures, you might not need to poll the exchanges at all. We publish our data as free JSON files, updated on a schedule, though they should not be used for trading decisions that need live data.

A 429 during an emergency

The worst time to find a limit is when you are trying to cancel orders in a falling market. Your loop has been hammering the API, you have used up your budget, and now your cancel is rejected. Plan for this: keep order-related traffic within a budget that is reserved, and separate from market-data polling. Keep public data on a stream so it uses no REST budget. Binance's documentation notes that when a server node is under system-level protection and throttling requests, close-position, reduce-only and cancel orders are exempt, which suggests that using those order types for risk reduction is a sensible habit. Our guide to what to do during an outage covers related preparation.

Is it a limit or an outage?

The two can look similar in a dashboard, since both produce failures. Separate them by code.

• 429, 418, or an exchange-specific limit code: your own traffic is the likely cause.
• 403: could be a web firewall, a region block, or Bybit's IP limit. See our guide to 403 and 451.
• 5xx or a timeout: probably on the exchange's side or along the route. Check whether it is down.

Log the code, the endpoint, and the response headers for every failure. Without them you end up guessing.

Common questions about rate limits

Does using several API keys avoid the limit?

Not for limits based on IP, such as Binance's IP weight. Multiple keys from the same address share the same budget. Order rate limits may be tracked per account, so check how each type of limit is counted. Spreading traffic across many addresses specifically to dodge a limit may breach an exchange's terms, and it is not something we recommend.

How long does a rate limit ban last?

That depends on the exchange. Binance's documentation states that its bans scale from 2 minutes up to 3 days for repeat offenders. Bybit says that you should wait at least 10 minutes after a "403, access too frequent". Keep sending requests during a ban and you risk extending it.

Can I ask for higher limits?

Some exchanges offer higher limits to market makers, to VIP tiers or on application. See their documentation. It is usually a better first step to reduce unnecessary traffic, since that also makes your system more robust.

Staying under the limit

1. Read the rate limit rules for the exact API you use.
2. Log used-weight headers and slow down before you reach the limit.
3. Share one limiter across all workers on an IP.
4. On a limit response, back off with jitter and honour Retry-After.
5. Stop and alert on 418 or a ban.
6. Move market data to WebSockets.
7. Reserve budget for cancels.

Related reading: Why an exchange API returns 403 or 451 · How to fix Binance error -1021 · How to check if an exchange is down

Sources

Binance · Limits · Bybit · Rate limit rules · OKX · API documentation · MDN · 429 · About Tickmark