To ensure consistent availability and performance for everyone we apply some limits to how APIs are used. These limits are designed to detect when client applications are making extraordinary demands on server resources.
The limits should not affect normal usage, only client applications that perform extraordinary API requests should be affected. The limits provide a level of protection from unexpected surges in request volumes that threaten the availability and performance characteristics of the platform.
When a client application makes extraordinarily demanding requests, the API returns an HTTP error indicating that too many requests have been made : 429 Too Many Requests error.
How API Limits are enforced
The API limits are evaluated per customer account and per resource. API limits are evaluated within a 1 minute and a 1 hour sliding window. If any of the limits are exceeded, an API Limit error will be returned on subsequent requests to protect the API.
Only accounts which are making extraordinary demands will be limited. Others will not be impacted.
Only ressource on which are making extraordinary demands will be limited for an account. Others will not be impacted.
By default, API limits are :
- 300 requests per minute
- 18000 requests per hour
These values can be modified for a particular customer and a particular resource, but cannot be completely deleted. Please contact the technical team to ask a modification of this limits.
For job creation requests, if you frequently reach limits, please try to group your sendings first.
Retry operations
When an API limit error occurs, it will provide a value indicating the duration (Retry-After with number of seconds) before any new requests from the user can be processed.
It is the responsibility of client applications to manage API limit errors. How to handle this error depends on the nature of the client application:
- If the client application is an interactive application with GUI, you should display a message that the server is busy while you re-try the request the user made. Don’t allow users to submit more requests until the previous request you sent has completed.
- If the client application is not interactive, the usual practice is to simply wait for the Retry-After duration before sending the request again. This is usually done by suspending the execution of the current thread using Thread.Sleep or equivalent methods.