See each API rate limit page for details:
- Public Endpoints: 10 requests per second, up to 15 requests per second in bursts
- Private Endpoints: 15 requests per second, up to 30 requests per second in bursts
/fillsendpoint: 10 requests per second, and up to 20 requests per second in bursts
- 50 requests per rolling second per session
- 100 messages per second in bursts
- 8 requests every second per IP and up to 20 requests for bursts
- Messages sent by the client: 100 every second per IP
Rate-limiting for both the Exchange REST API and the FIX API use a lazy-fill token bucket implementation.
A TokenBucket stores a maximum amount of tokens, which is the burst size, and fills at a given rate called the refresh rate. The bucket starts full, and as requests are received, a token is removed for each request. Tokens are continuously added to the bucket at the refresh rate until full.
When a user sends a request, the TokenBucket calculates whether or not to rate limit the user as follows:
- Fill the user's TokenBucket to a token size based on the following formula:
token_amount = min(burst, previous_token_amount + (current_time - previous_request_time) * refresh_rate)
- Remove 1 token if possible, otherwise rate limit the request.
- Repeat Steps 1 and 2 for each subsequent request.
Let's say you have a TokenBucket with burst = 3 and refresh_rate = 1. The table below represents the state of your token bucket after a series of requests:
|Initial State||0.0||3.0||New TokenBucket is initialized to max capacity (burst)|
|Request 1||0.5||2.0||Fill TokenBucket, then remove a token, because we are at max capacity, and subtract 1 token from 3|
|Request 2||0.8||1.3||Fill TokenBucket to 2.3 (|
|Request 3||0.9||0.4||Fill TokenBucket to 1.4 (|
|Request 4||1.0||0.5||Fill TokenBucket to 0.5 (|
|Request 5||1.4||0.9||Fill TokenBucket to 0.9 (|
|Request 6||1.8||0.3||Fill TokenBucket to 1.3 (|
|Request 7||5.0||2.0||Fill TokenBucket to 3.0 (|
Updated 8 days ago