API Rate Limits

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.

EndpointPathRate Limit
Encodingv1/encoding/encodingsPOST: 600 req/min
GET: 60 req/min
Encoding Startv1/encoding/encodings/{encoding_id}/startPOST: 600 req/min
GET: 600 req/min
Simple Encoding Startv1/encoding/simplePOST: 600 req/min
GET: 600 req/min
Encoding Statusv1/encoding/encodings/{encoding_id}/statusGET: 6,000 req/min
This allows for 100 encoding jobs to query the status once per second.
All resources configured below an encoding jobv1/encoding/encodings/{encoding_id}/POST: 20,000 req/min
GET: 20,000 req/min
Inputsv1/encoding/inputsPOST: 4,000 req/min
GET: 1,000 req/min
Outputsv1/encoding/outputsPOST: 4,000 req/min
GET: 1,000 req/min
Configurationsv1/encoding/configurationsPOST: 4,000 req/min
GET: 1,000 req/min
Filtersv1/encoding/filtersPOST: 4,000 req/min
GET: 1,000 req/min
Manifestsv1/encoding/manifestsPOST: 10,000 req/min
GET: 10,000 req/min
Statisticsv1/encoding/statisticsGET: 60 req/min
Accountsv1/encoding/accountPOST: 600 req/min
GET: 600 req/min
Reset password/v1/account/initiate-password-resetPOST: 3 req/min
Signup/v1/account/new/verify-emailPOST: 3 req/min
Login/v1/account/loginPOST: 10 req/min
Infrastructurev1/encoding/infrastructurePOST: 60 req/min
GET: 60 req/min
Notificationsv1/notificationsPOST: 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:

x-ratelimit-limitx-ratelimit-limit: 10, 10;w=60The 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-remainingx-ratelimit-remaining: 9Remaining requests allowed before a rate limit will be enforced
x-ratelimit-resetx-ratelimit-reset: 42Seconds 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