Reporting API endpoints use two types of rate limiting:
- request count-based rate limiting
- cost-based rate limiting
Request count based rate limiting
Request count based rate limiting restricts the serving of API responses based on the number of requests made in a time interval.
By default, individual reporting API endpoints are subject to a rate limit of 120 requests per minute, applied per account for a given endpoint. If multiple API clients within the same account are calling the API, the rate limit is applied globally to all the API clients at a given time. When the limit is reached, the API responds with an HTTP 429 error, and you can't make new requests for one minute. You need to consider the limit when you call successive operations as part of a loop.
Cost-based rate limiting
Cost-based rate limiting of an API is a mechanism for controlling and managing the use of an API based on the associated costs or resources consumed by each API request. Rather than limiting the number of requests per unit of time, cost-based rate limiting focuses on the resources consumed or the "cost" of each request. The cost value is determined based on factors such as the complexity of the operation, the amount of data processed, and the computing resources used.
The API endpoints implement a leaky bucket algorithm that keeps track of the limit consumed by an account and API endpoint. The client receives a rate limiting response when all tokens allocated for the client are exhausted/used up in a time interval The akamai-ratelimit-next response header stores the date value indicating when the bucket will be refilled. Upon receiving this response, the client should pause sending requests until the specified time. If multiple requests encounter rate limits, introducing an additional jitter beyond the bucket refill time can help the client reduce the load on the system and get a successful response.