Every single day developers send their requests to the Bitmovin API. To handle the large number of requests effectively, we have set limits on how many requests can be made. These limits are crucial in ensuring that our API remains reliable and scalable, which is vital for our developer community. We want to provide you, as a developer, with the best possible experience while using the Bitmovin API. To achieve this, we follow standard practice in implementing rate limits, which serve various purposes:
- Rate limits serve several purposes, including protecting the API against potential abuse or misuse. This can occur when someone intentionally floods the API with requests to overload it or cause service disruptions. By imposing rate limits, we can prevent such activity from occurring.
- Another benefit of rate limits is that they promote fair access to the API. If a single user or organization makes too many requests, it can cause the API to slow down or become unresponsive, which negatively impacts other users. To ensure that everyone has an equal opportunity to use the API without experiencing slowdowns, we limit the number of requests that a single user can make.
- Finally, rate limits help us manage the overall load on our infrastructure. If there is a sudden increase in API requests, it could put a strain on our services and cause performance issues. By setting rate limits, we can better manage the aggregate load and maintain a smooth and consistent experience for all users.
Bitmovin Rate Limits
Bitmovin imposes restrictions on the frequency of customer calls to a particular endpoint within a minute. These limitations are calculated separately for GET and POST requests. The specific endpoint limits vary depending on the use-case.
| Endpoint | Path | Rate Limit |
|---|---|---|
| Encoding | v1/encoding/encodings | POST: 600 req/min GET: 60 req/min |
| Encoding Start | v1/encoding/encodings/{encoding_id}/start | POST: 600 req/min GET: 600 req/min |
| Simple Encoding Start | v1/encoding/simple | POST: 600 req/min GET: 600 req/min |
| Encoding Status | v1/encoding/encodings/{encoding_id}/status | GET: 6,000 req/min This allows for 100 encoding jobs to query the status once per second. |
| All resources configured below an encoding job | v1/encoding/encodings/{encoding_id}/ | POST: 20,000 req/min GET: 20,000 req/min |
| Inputs | v1/encoding/inputs | POST: 4,000 req/min GET: 1,000 req/min |
| Outputs | v1/encoding/outputs | POST: 4,000 req/min GET: 1,000 req/min |
| Configurations | v1/encoding/configurations | POST: 4,000 req/min GET: 1,000 req/min |
| Filters | v1/encoding/filters | POST: 4,000 req/min GET: 1,000 req/min |
| Manifests | v1/encoding/manifests | POST: 10,000 req/min GET: 10,000 req/min |
| Statistics | v1/encoding/statistics | GET: 60 req/min |
| Accounts | v1/encoding/account | POST: 600 req/min GET: 600 req/min |
| Reset password | /v1/account/initiate-password-reset | POST: 3 req/min |
| Signup | /v1/account/new/verify-email | POST: 3 req/min |
| Login | /v1/account/login | POST: 10 req/min |
| Infrastructure | v1/encoding/infrastructure | POST: 60 req/min GET: 60 req/min |
| Notifications | v1/notifications | POST: 60 req/min GET: 60 req/min |
Behavior of Rate Limits
Every response from the API will carry information about the applicable rate-limit for the given request as specified in the Rate Limit Draft RFC. This means each request will carry the following information informing the client about the current state of their rate limit quota as well as when a rate limit reset will take place:
| Header | Example | Description |
|---|---|---|
| x-ratelimit-limit | x-ratelimit-limit: 10, 10;w=60 | The maximum number of requests allowed for a given time frame (w=60 would indicate a per minute limit). Multiple limits are comma delimited. |
| x-ratelimit-remaining | x-ratelimit-remaining: 9 | Remaining requests allowed before a rate limit will be enforced |
| x-ratelimit-reset | x-ratelimit-reset: 42 | Seconds until the rate limit window is being reset |
When a rate limit is exceeded the server will respond with a 429 - Too Many Requests HTTP Status Code.
Best Practices
- When the limit has been reached, stop making API calls.
- Spread out queries evenly to avoid traffic spikes.
- Use filters to limit the data response size and avoid calls that request overlapping data.
- Check the x-ratelimit-remaining HTTP header to see how close your application is to its limit.
- When the limit has been reached inspect the x-ratelimit-reset header to see when you can resume making calls.
If you run into any issues with the rate limits please contact our support team and include the following information to help troubleshoot:
- A description of how you are using the Bitmovin API (maybe we can suggest alternative usage patterns)
- Which API endpoints you are using