Mark Michon for Bearer

Posted on Mar 2, 2020 • Updated on Mar 10, 2020 • Originally published at blog.bearer.sh

Error 429 Too Many Requests - What to do when you've been rate limited

#api #errors #429

📣 This post originally appeared as Error 429 Too Many Requests - What to do when you've been rate limited on The Bearer Blog.

Your application is running smoothly. Tests have passed. Suddenly you start to see 429 error responses from an API. As the name implies, you have made too many requests and your application has been rate limited. The 429 (Too Many Requests) error is an HTTP status code that often occurs when you've hit a request limitation of an API.

While rate limiting may seem like a bad thing when you encounter it, this restriction is a protective feature of most consumable APIs. Rate limits prevent services from intentional abuse, as well as accidental abuse that may occur when developers are testing applications. If you've ever poured water into a funnel too quickly, you've seen it start to back up and eventually overflow. Rate limiting aims to prevent this by stopping the flow of requests before a problem arises.

So what can you, as a developer consuming APIs, do about it? To start, let's look at what causes the error and how to find the rate limit details for an API.

Rate limit thresholds and how are they triggered

Depending on the type of application you are building, there are a variety of instances where you may run into rate limiting. Bots, and any application that consistently polls an API, are the most likely to run into the error. Applications that directly let users interact with the third-party API are also at higher risk of hitting limits. To learn more about an APIs rate limit threshold, it's best to check the documentation for the API you are using.

Normally, rate limits are defined by requests over a period of time. For example, GitHub's v3 REST API has a limit of 5000 requests per hour per authenticated user for authenticated requests. For unauthenticated requests, the limit is 60 requests per hour. These types of limits can either be API-wide, or unique for an endpoint or resource. The Discord API, for example, has unique limits for each endpoint and account. As a result you should avoid hard-coding limits directly into your application.

Another thing to keep in mind is that these time-based limits might be set based on the time of the first request, or may have a fixed timeframe, such as the start of a day.

While many services will publish their limits like in the GitHub example above, others may include limits as a property on responses, or even as a header that only displays when a limit is hit.

Understanding a 429 error response

You've seen the error code, but there's often more information available when your request fails. REST APIs will often include a message describing the problem along with a set of X-RateLimit-* headers with information about the limits. Some APIs, like GitHub's, will include this on successful requests as well. Each API will have their own specific headers, but a few common rate limit related headers are:

X-RateLimit-Limit: The amount of requests that can be made (across a time-frame).
X-RateLimit-Remaining: The remaining number of requests that can be made (across a time-frame).
X-RateLimit-Reset: A timestamp of when the limit will be reset.

GraphQL APIs will either return an error when a limit is hit, like Yelp's GraphQL API, or may instead offer a means to check the current usage. GitHub's v4 Graph API does this by allowing users to query the rateLimit object.

query {
  rateLimit {
    limit
    cost
    remaining
    resetAt
  }
}

These pre-emptive approaches allows you to perform checks before a limit is hit, rather than only reacting to the error.

How to fix the "Too Many Requests" error

If the API provides you with headers or error objects that include reset information, you can use this to wait the appropriate amount of time before retrying. Take the resetAt - currentTime and use that to wait before making another request. You can even bring this functionality into a circuit breaker, or use a solution like Bearer to retry on certain conditions.

If there is no programatic way of knowing how long to wait before trying, you can use the "back-off" approach where your code performs a series of retries with increasing delays between each retry.

How to truly avoid 429 errors

These are fine approaches, but what if you are providing an API that is hitting rate limits on other APIs? In this case, you'll want to throttle incoming calls to your API in order to prevent rate limits from causing problems. Throttling is a technique that limits code execution. In this case, requests are limited and "dropped" or fulfilled with cached data. This way your app intervenes before the third-party service ever reaches the limit. This approach can also be useful for restricting usage of costly APIs. You can even implement your own rate limiting with more conservative thresholds that will stop your app from ever hitting the limits of the third-party API.

In order to make more informed decisions, it is a good idea to monitor your third-party API usage. Using a tool like Bearer, you can even set rules to notify you when usage reaches a certain point and react to them programmatically.

With all this in mind, your app should be more resilient against the "Too Many Requests" error. Check the Bearer Blog for more articles on building resilient applications and connect with us @BearerSH to tell us how you respond to 429 errors.