Rate Limits
API Request rate limits and our API throttle
The number of requests that can be made through the API is currently 65 per minute per supplier. We provide the API request rate information in the response headers for each request.
The
HTTP 429 Too Many Requests indicates you have exceeded your allowed requests.Header | Description |
OCTO-RateLimit-Limit | The maximum allowed requests/min. |
OCTO-RateLimit-Remaining | The number of requests that remain before you hit the request limit. |
OCTO-RateLimit-RetryAfter | This represents the number of seconds until another request will be allowed. |
Any of the booking API calls will not accrue against your API usage.
OCTO-RateLimit-Limit: 65
OCTO-RateLimit-Remaining: 0
OCTO-RateLimit-RetryAfter: 10
Programming practices such as continuous polling for inventory or regular inventory scanning are more likely to lead to throttling and will degrade overall performance. Concurrent API calls may lead to a high number of requests per minute, triggering a throttling event.
The following are best practices for avoiding throttling:
- Reduce the degree of parallelism - common when tracking inventory.
- Reduce the frequency of calls - again common with inventory calls.
- Avoid immediate retries - all requests accrue against your usage limits.
We will reply with a
HTTP 429. When you implement error handling use the error code 429 to detect throttling. Response headers will include OCTO-RateLimit-RetryAfter. Backing off requests using RetryAfter is the fastest way to recover from throttling.To use the RetryAfter delay, do the following:
- 1.Wait for the number of seconds specified in the
OCTO-RateLimit-RetryAfterheader. - 2.Retry the request.
- 3.If the request fails again with a
429error code, you are still being throttled. Retry with Exponential backoff, use the recommended Retry-After delay and retry the request until it succeeds.
Last modified 1yr ago