Rate limits
The request limits on the API and how your client should back off when it reaches them.
1 min read
The limits count requests per client IP address, so workers that share one outgoing address share them.
The limits
| Limit, per client IP address | Value |
|---|---|
| Requests per second | 200, with short bursts above it |
| Requests per minute | 2,000 |
| Open connections at once | 400 |
Above a limit, the API answers 429 Too Many Requests.
Back off on 429 and 5xx
- On a
429or a temporary5xx, wait before you retry. - Double the wait each time, with jitter: about 1, 2, 4, then 8 seconds.
- Cap concurrent workers, so one spike doesn't turn into a retry storm.
- Retry reads automatically, but fetch a booking again before retrying its cancellation.
- Alert an operator when throttling lasts.
A 500 whose message describes your request, such as a missing external_id, fails again on every retry. Fix the request instead: see Booking API errors.
Design patterns that reduce throttling
| Use case | Better pattern |
|---|---|
| Every API call | Reuse the access token until it expires, instead of requesting one per call |
| Show upcoming bookings in a portal | Cache booking results for a short session and refresh on demand |
| Keep a CRM updated | Use webhooks instead of polling |
| Backfill historical data | Run scheduled batches outside your peak hours, and page through results |
| Cancel a booking | Fetch once, then cancel only after the participant confirms |