🚦 What Are API Rate Limits?
API rate limits are restrictions imposed by cryptocurrency exchanges on the number of API requests you can make within a specific time period — typically per minute or per second. These limits exist to protect the exchange's infrastructure from being overwhelmed by excessive API traffic and to ensure fair usage among all users.
Rate limits are a critical consideration when building any application that interacts with exchange APIs. If you exceed the limits, your requests will be rejected with an HTTP 429 (Too Many Requests) error, and in some cases, your API key or IP address may be temporarily banned.
- Infrastructure protection: Prevent servers from being overwhelmed.
- Fair usage: Ensure all users have equal access to API resources.
- Prevent abuse: Discourage malicious or excessive API usage.
- Service stability: Maintain consistent performance for all users.
⚙️ How Rate Limits Work
Rate limits work by tracking your API usage over a rolling time window. When you exceed the allowed number of requests, the exchange rejects your request and returns an HTTP 429 error.
Types of Rate Limits
A straightforward limit on the number of requests per time window (e.g., 1200 requests per minute). Each request counts as 1 towards your limit.
Different endpoints have different "weights" based on their complexity. A simple price ticker might cost 1 weight, while a complex order placement might cost 5 weight. Your total weight usage is limited per time window.
WebSocket connections typically have limits on the number of streams you can subscribe to per connection (e.g., 1024 streams on Binance) and message frequency limits.
Some exchanges apply rate limits per API key, while others apply them per IP address. Understanding which is used is important for scaling your application.
Rate Limit Headers
Most exchanges include rate limit information in their response headers, allowing you to monitor your usage programmatically.
| Header | Description | Example |
|---|---|---|
| X-RateLimit-Limit | Total allowed requests/weight per window | 1200 |
| X-RateLimit-Remaining | Requests/weight remaining in the current window | 850 |
| X-RateLimit-Reset | Time (in milliseconds) until the window resets | 30000 (30 seconds) |
| X-RateLimit-Used | Requests/weight used in the current window | 350 |
Always monitor the X-RateLimit-Remaining and X-RateLimit-Reset headers in your API responses. This allows you to dynamically throttle your requests and avoid hitting the limit. Don't just wait for HTTP 429 errors — be proactive.
🏦 Rate Limits by Exchange
Different exchanges have different rate limit policies. Here's a comparison of the most popular exchanges.
| Exchange | Rate Limit Type | Limit | Notes |
|---|---|---|---|
| Binance | Weight-based | 1200 weight/min | Simple endpoints cost 1-5 weight; complex orders cost more |
| OKX | Count-based | 50 requests/sec | Per API key; WebSocket has separate limits |
| Bybit | Weight-based | 50 requests/sec (weight) | Different weights per endpoint; WebSocket separate |
| KuCoin | Count-based | 100 requests/sec | Per API key; WebSocket has separate limits |
| Coinbase | Count-based | 10 requests/sec | Low limit; use WebSocket for real-time data |
| Kraken | Count-based | 20 requests/sec | Per IP; higher limits for some endpoints |
Rate limits are subject to change. Always refer to the official API documentation of each exchange for the most up-to-date information. Some exchanges also offer higher rate limits for VIP users or institutional accounts.
⚠️ Handling HTTP 429 (Too Many Requests)
When you exceed rate limits, the exchange returns an HTTP 429 error. Here's how to handle it gracefully.
Best Practices
- Implement exponential backoff: When you receive a 429 error, wait and retry with increasing delays (e.g., 1s, 2s, 4s, 8s).
- Check the Retry-After header: Some exchanges include a
Retry-Afterheader indicating how long to wait before retrying. - Monitor rate limit headers proactively: Don't wait for 429 errors. Monitor
X-RateLimit-Remainingand throttle your requests before you hit the limit. - Log rate limit violations: Track when and why you hit rate limits to identify areas for optimization.
- Have a fallback strategy: If you're consistently hitting limits, consider using WebSocket for real-time data instead of polling REST.
If you receive a 429 error, implement a retry with exponential backoff: wait 1 second, retry; if it fails again, wait 2 seconds; then 4 seconds; then 8 seconds. This prevents overwhelming the server and gives you the best chance of a successful retry.
📈 Strategies to Avoid Rate Limits
Use these strategies to stay within rate limits while maintaining high performance.
Store data like trading pairs, exchange info, and historical prices locally. Only fetch new data when it changes, reducing the number of API calls.
Instead of polling REST endpoints for price updates, use WebSocket streaming. This dramatically reduces request count while providing better real-time data.
Many exchanges support batch requests — multiple operations in a single API call. This reduces the number of requests you need to make.
Use a token bucket or leaky bucket algorithm to control your request rate. Throttle your own requests to stay within limits.
If allowed, distribute your requests across multiple API keys to increase your total request capacity (e.g., for high-frequency trading).
Regularly review your API usage patterns. Identify endpoints with high request counts and look for ways to optimize or cache them.
Instead of polling /api/v3/ticker/price every second (60 requests/min), use a WebSocket connection to receive real-time price updates. This reduces your REST API usage from 60/min to near zero for that data point.
❌ Common Rate Limit Mistakes
Avoid these common pitfalls that lead to rate limit violations.
- Polling too frequently: Many developers poll for price updates every 100ms, quickly hitting rate limits. Use WebSocket for real-time data.
- Ignoring rate limit headers: Not monitoring
X-RateLimit-Remainingleads to unexpected 429 errors. - Not implementing retry logic: When you get a 429 error, failing to retry can result in missed trades or data gaps.
- Using the same API key for all services: If you have multiple applications, use separate API keys to isolate rate limit usage.
- Not understanding weight-based limits: On exchanges with weight-based limits, placing complex orders multiple times can consume your weight quickly.
- Not using keep-alive connections: For REST APIs, using HTTP keep-alive reduces connection overhead and can improve performance.
For REST APIs, use HTTP/2 and keep-alive connections to reduce connection overhead. This won't change your rate limit, but it will make your requests more efficient and reduce latency.