Rate Limit (API)

API rate limiting is a traffic control mechanism that cryptocurrency exchanges implement to protect their infrastructure from overload, prevent market manipulation through excessive order submission, and ensure fair access to market data across all users. Every exchange exposes rate limits as part of its API documentation, specifying the maximum number of requests allowed per time window (typically per second, per minute, or per IP address) for each endpoint category. Rate limits are not uniform across all API endpoints. Exchanges typically partition limits by request type. Market data endpoints — order book snapshots, candle history, trade feed — carry generous limits because they serve a large number of users. Order management endpoints — place order, cancel order, query open orders — carry stricter limits because they interact directly with the exchange matching engine and create computational cost. Account endpoints — balance queries, trade history, withdrawal requests — typically fall between these extremes. A well-designed trading system tracks consumption separately for each endpoint category rather than applying a single global rate limit counter. When a rate limit is exceeded, exchanges return an HTTP 429 (Too Many Requests) status code, often accompanied by a Retry-After header specifying how long to wait before the next request. Some exchanges implement a temporary ban (minutes to hours) for repeated or severe violations; others implement IP-level bans for extreme abuse. The specific consequences vary by exchange. In a live trading system, a 429 error during order placement can leave a position unmanaged — orders cannot be placed, modified, or cancelled until the ban expires. This makes rate limit management a reliability concern, not merely a technical courtesy. Robust rate limit management in production trading systems typically involves several layers. Request queuing ensures that burst activity from simultaneous strategy signals is serialised through a rate-aware queue rather than fired simultaneously. Exponential backoff on error response automatically scales retry intervals when limits are hit. Per-endpoint counters track consumption across each limit category independently. WebSocket subscriptions replace REST polling where possible — a single WebSocket connection for order book updates consumes no rate limit budget while providing lower latency than repeated REST calls. Exchange-provided rate limit headers in each response allow dynamic adjustment of request pacing in real time. Weight-based rate limit systems, used by Binance and several other large exchanges, assign a numeric weight to each API endpoint based on its computational cost rather than counting raw request numbers. Placing an order might cost 1 weight unit while a full order book snapshot costs 10. The total weight consumed per minute is tracked against a limit. A system that alternates between heavy data requests and order placement can exhaust its weight budget quickly even with infrequent requests. Understanding weight assignment is critical for strategy developers relying on high-frequency data queries alongside active order management.