Rate Limits

Rate limits are restrictions that our API imposes on the number of times a user or client can access our services within a specified period of time.

Why rate limits are important ?

Rate limits are a common practice for APIs, and they're put in place for a few different reasons:

• To prevent abuse or misuse of our API. For example, a malicious user could try to flood our API with requests and cause disruptions of service.
• To assure a fair access to everyone that use our API. If an user makes an excessive number of requests, it could slow down the API for evryone else. By limiting the number of requests a user can make, we can ensure that everyone can access our API without experiencing slowdowns.

How do they work ?

They are measured in requests per second (RPS). If you exceed the limit, you will receive a 429 HTTP status code. So be careful to not hammer the API with too many very quick requests.

The rate limit is team based, it means that all of the requests made by a team will be counted towards the same limit. So be careful, if one member of the team is making too many requests other members will be affected too.

How to mitigate rate limits error ?

Use webhooks! This is a best practice to avoid doing too many unecessary requests. Chunkify API can send you notification for all the crucial steps of your transcoding job. You do not need to poll the API for status updates.

If for your use case you cannot avoid too many requests, you can use exponential backoff to avoid hitting the rate limit.

Retrying with exponential backoff

One easy way to avoid rate limit errors is to automatically retry requests with a random exponential backoff. Retrying with exponential backoff means performing a short sleep when a rate limit error is hit, then retrying the unsuccessful request. If the request is still unsuccessful, the sleep length is increased and the process is repeated. This continues until the request is successful or until a maximum number of retries is reached. This approach has many benefits:

• Automatic retries means you can recover from rate limit errors without crashes or missing data
• Exponential backoff means that your first retries can be tried quickly, while still benefiting from longer delays if your first few retries fail
• Adding random jitter to the delay helps retries from all hitting at the same time.