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 that often occurs when you've hit a request limitation of an API. HTTP status code 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. - To start, let's look at what causes the error and how to find the rate limit details for an API. So what can you - as a developer consuming APIs do about it? 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, 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. , for example, has unique limits for each endpoint and account. As a result you should avoid hard-coding limits directly into your application. GitHub's v3 REST API The Discord API 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 , or may instead offer a means to check the current usage. does this by allowing users to query the rateLimit object. Yelp's GraphQL API GitHub's v4 Graph API <code class=" language-graphql" style="box-sizing: inherit; margin: 0 px; padding: 0 px; border: 0 px; font-style: inherit; font-variant: inherit; font-weight: 400 !important ; font-stretch: inherit; line-height: inherit; font-family: Consolas, Monaco, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, monospace; font-size: inherit; vertical-align: baseline; background: transparent; border-radius: 3 px; color: rgb(248, 248 , 242 ); text-shadow: rgba(0, 0 , 0 , 0.3 ) 0 px 1 px; text-align: left; white-space: pre; word-spacing: normal; word-break: normal; overflow-wrap: normal; tab-size: 4 ; hyphens: none;">query { rateLimit { limit cost remaining resetAt } } </code> 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 , or use a solution like to retry on certain conditions. circuit breaker Bearer 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 (the company I work for), you can even set rules to notify you when usage reaches a certain point and . Bearer react to them programmatically With all this in mind, your app should be more resilient against the "Too Many Requests" error.

Flow

What Developers Mean When They Talk About API

The HTTP Status Codes You Need to Know

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Error 429 Too Many Requests: What to Do When You've Been Rate Limited?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How To Improve Your Backend By Adding Retries to Your API Calls

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

How To Improve Your Backend By Adding Retries to Your API Calls

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps