All calls to OpenAPI are subject to rate limiting. Limits are put in place to protect our system against excessive load and to make OpenAPI available to as wide an audience as possible.
Per default the following limits are in place:
- Max number of requests per application across all users and sessions: 10.000.000/day.
- Max number of requests per session per service group: 120/minute.
- Max number of orders per session: 1/second.
- A single request including an entry order and two related orders counts as one request.
- A single request to create a standalone order, immediately followed by a request to add a related order will count as 2 requests and will be rejected.
The above limits are in effect whether you place the requests individually or as part of a batch request. I.e. a batch request including 10 requests, will count as 11 requests.
Rate Limit Headers
You will receive rate limit information in the response headers of all calls to endpoints which are rate limited.
Currently you will receive these for every call. To limit bandwidth usage we are considering only returning these headers, when a limit is close to being reached. The following information is returned:
- X-RateLimit-<dimension>-Limit: The total number of requests allowed (per dimension).
- X-RateLimit-<dimension>-Remaining: The total number of requests remaining (per dimension).
- X-RateLimit-<dimension>-Reset.Number of seconds until the quota is reset.
Below is an example of response headers, including rate limit information. Not all headers are returned for all endpoints.
If any of the above limits are exceeded, the request will be rejected with an HttpStatus code 429 - Too Many Requests. In the example below, the caller has tried to place two orders in rapid succession.
Preventing duplicate order operations
In order to avoid accidental duplication of order operations due to message re-transmission, OpenAPI rejects such identical operations within a rolling 15 second window. In this case the request will be rejected with an HttpStatus code 409 - Conflict.
This restriction applies to POST (create new orders) and PATCH (modify existing orders) requests to the /trade/v1/orders and /trade/v2/orders endpoint, with identical urls and request bodies.
If an application deliberately wishes to perform two identical order operations on the same account within a 15 second time frame, it must include an 'x-request-id' header, and the value of the 'x-request-id' must be different for each of the requests.