Why rate limit API requests?Rate limiting is important for a few reasons. First, one of the golden rules of multi-tenant architecture is that one user's behavior shouldn't affect someone else. If you're using Dropbox to store files, and someone else uploads a few petabytes of data, you shouldn't get an error saying Dropbox doesn't have any space left for you. Or if your neighbor floods his cable internet with BitTorrent traffic, your own service shouldn't be degraded because of this. Without rate limiting, one user of an API can adversely affect another user. One customer could flood a service with unnecessary API requests - intentionally, abusively, or accidentally - and that could mean that other users experience slowdowns or capacity issues. Now the service itself should be able to handle any reasonable capacity, of course. But no matter how scalable or performant a service is, there are always limits. Whether those limits are 100 requests/second or 1,000,000 requests/second, the limit is there. Rate limiting ensures that everyone has access to resources. That leads to the second reason that rate limiting is important for APIs: it's easy to make mistakes when integrating with an API. Because APIs are called programmatically, it isn't particularly difficult to accidentally send more requests than you intend. If you forget the exit condition in a loop, or forget to wait for a few seconds (or minutes) between poll requests, your simple API integration can turn into a simple Denial of Service attack. What's more, when an API is billed on a per-use basis, rate limits are actually a safeguard. If you're exceeding a reasonable rate limit, there is a good chance that you're doing something wrong. And if you're doing something wrong with a per-use API, it's possible that you're accidentally racking up a giant bill.
How it works at ZencoderZencoder now limits how many times you can call a particular method inside a give timeframe. Limits are tracked on a per-method (resource) basis, with the exception of progress requests, which are tracked per-file. If you exceed your quota, Zencoder will return a 403 error with a body of "403 Forbidden (Rate Limit Exceeded)". We'll also send back an additional header, "Retry-After", which contains the number of seconds until your quota is reset. Additionally, each HTTP response contains a header called "X-Zencoder-Rate-Remaining". This header lists the number of calls you can make to a given resource within the current time frame. The limits are as follows.
- Job creation requests (POST): 1,000 per minute
- File progress requests (GET): 60 per minute per file
- All other GET requests: 60 per minute total