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.
Rate Limit Headers
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.
Example
1
OCTO-RateLimit-Limit:65
2
OCTO-RateLimit-Remaining:0
3
OCTO-RateLimit-RetryAfter:10
Copied!
Avoiding API Throttling
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.
I'm being throttled, now what?
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-RetryAfter header.
2.
Retry the request.
3.
If the request fails again with a 429 error code, you are still being throttled. Retry with Exponential backoff, use the recommended Retry-After delay and retry the request until it succeeds.