Rate Limiting
The REST API applies rate limits individually to each app ID. That means that requests sent using your test app ID will have no impact on your live app. However, all requests sent using your live app ID will count towards the same limit, even if the requests come from different devices.
This rate limit ensures that misuse of the REST API has less impact on other customers.
Rate limits only apply to requests sent to the REST API. Requests sent from the pre-built UIs do not count towards the limit and are unaffected by throttling.
By default, the REST API rate limits support 500 burst requests, 100 maximum queue length, and 9 requests per second. So if you send 700 requests in quick succession:
- The first 500 requests are processed and responded to instantly
- The next 100 requests are put in the queue
- Because the queue is now full, the last 100 requests immediately receive HTTP 429 "Too many requests" responses
- Over time, the 100 queued requests will be processed and responded to (at a rate of 9 requests per second)
While the queue is empty, the burst capacity slowly increases back up to 500, at a rate of 9 per second. That means if you wait until the queue has been empty for 5 seconds and send 200 more requests:
- The first 45 of those requests will get instant responses (because you gain 9 burst capacity per second and the queue has been empty for 5 seconds)
- The next 100 will go in the queue (because the queue was empty)
- The remaining 55 will get HTTP 429 responses (because the queue is now full again)
Overall, this means that you can send a sustained rate of 9 requests per second to the REST API. You can temporarily go over 9 requests per second, as long as your average rate is under 9/s.
We can customise all three values on a case-by-case basis:
- The sustained rate limit (default 9 requests/s)
- The max queue length (default 100 requests)
- The max burst (default 500 requests)
Please get in touch to discuss increasing your rate limits.