API Limits
The ZEST API's run against the same servers and databases and other resources as the website itself uses. For this reason, hitting the API too hard has the potential to slow down the site. We don't want this!
It is important when using the API to realise that ZEST will prioritise the performance of the website over the completion of API requests, and cannot provide a guarantee that there will not be interuptions to the API. You should build any API application to be robust against disconnections and failed requests.
What are the rate limits?
Dynamic rate limiting is used for API requests. ZEST attempts to ensure that API requests can still complete but without overloading the site's servers. This takes into account not just the load generated by the API requests themselves but also other load the site might be under - for instance if the site is experiencing a spike in traffic due to a large marketing campaign, API requests may be queued or delayed.
This algorithm is more complex than a simple rate limit, and it changes from time to time, however broadly speaking this is how it works: - for short periods of time (<10s) API requests can "burst" - ie you can perform a larger number of requests. - when API requests come in at a rate of more than 1 per second averaged over 10 seconds, requests will be queued. This means they will still complete but they will happen only one at a time. - If the API requests come in at a rate faster than 4 per second over a 10 second period, they may be blocked for a short time.
Note that in certain situations - for instance if your API integration is causing major issues for the live site, it might be blocked. Lower limits than those discussed here might also be applied.
How to handle rate limit responses
If your requests are queued, in general they will just be slowed down and still complete within a few seconds, so typically nothing needs to be done about this.
If your requests are blocked, you will receive a 429 "Too Many Requests" response code. You can retry that same request, however you should implement a delay (ideally with exponential backoff).
Strategies to avoid rate limits
Obviously slowing down your requests is advantageous. Generally speaking the most likely way you will hit rate limits is if you have multiple processes or threads attempting to sync at once. Having some sort of locking may be a solution.
The other thing you should try to do is to batch multiple updates. In the ZEST Data API it is possible to send many updates in a single XML request, and usually we would recomend that approach.