API Rate Limiting is simply controlling how many requests or calls an API consumer can make to your API. You may have experienced something related as a consumer with errors about “too many connections” or something similar when you are visiting a website or using an app.
What is an API consumer?
An API consumer could be a mobile app, a website, or even your doorbell or thermostat! Anything that makes a call to an API to get data is an API consumer. These are made via API Requests.
What is an API request?
An API request (or call) is where one of these consumers, say your thermostat, requests information from “the cloud” (or servers on the internet).
Say your thermostat wants to find out what the current weather conditions are so that it can display those for you.
That would be an API request.
The largest number of API requests, by far, come from mobile apps. A single mobile app might make between 10-20 API requests, just by you opening an app and logging in!
How are API Rate Limits typically set?
API Rate Limits are typically set up to limit the number of requests either by:
- per second
- per minute
- per hour
- per day (or 24-hour periods)
- per month
An API is not limited to picking just one of these. You could have one API Rate Limit per second and a different API Rate Limit per-hour. One or more API Rate Limits can be active at the same time.
API Rate Limiting might even be implemented differently depending on if you are authenticated or not. Authenticated API users (or API consumers that have included their credentials in the API Call) might be allowed more requests than anonymous users.
Do I need to implement API Rate Limiting?
Most likely, yes. But it’s important to understand the reasons why you might need them. If you are going to measure the success (or failure) of rate limits, you have to have a clear and defined purpose.
What are the reasons typically given for needing API Rate Limits?
Here are some reasons you might hear but not every one of these problems is best solved by API Rate Limits!
Protect your APIs from Distributed Denial of Service Attacks or DDoS.
While these attacks are a very real threat and can take down your API (which is a bad thing), API Rate Limiting is probably not the right solution for blocking these attacks.
There are other and more robust solutions for protecting your APIs from DDoS that should be looked at first.
Limit your backend expenses and costs
This can be a very legitimate reason for implementing API Rate Limiting. Let’s go back to the thermostat example. Say there is a line of thermostats that go bonkers and go into some loop where they are calling your weather API over and over.
While this might not take down your API, it could cost you a pretty penny because you are the one that has to pay for all the backend servers and services that make that weather API work! By limiting the calls per consumer, you could protect your resources and money!
Workaround hardware limitations
Getting a lot of API Calls could mean that your backend servers can’t keep up properly. This could lead to bottlenecks and the equivalent of driving on the highway during rush hour traffic.
It could slow everyone down as requests are queued up. Slow API Calls could mean things like really slow web pages and really unhappy users.
What are my options for implementing API Rate Limits?
- There are a few different ways of handling API Rate Limits: Hard Stop: This means an API Consumer will get an Error 429 when they call your API if they are over their limit.
- Soft Stop: In this case, you might have a grace period where calls can continue to be made for a short period after the limit is reached.
- Throttled Stop: You might just want to enforce a slowdown on calls made over the limit. This way users can continue to make calls, but they will just be slower because they are over the limit.
- Billable Stop: Here you might just charge the API consumer for calls made over their limit. Obviously, this would only work for authenticated API users but can be a valid solution.
💡 Bonus tips for API Rate Limits!
If you don’t want your API Users to hate you, there are three things you need to do:
1️⃣ Don’t be greedy
As we talked about earlier, there are several reasons for needing to implement API Rate Limits. Getting too greedy with your limits though can keep users from being able to implement the solutions they need to help them win.
You win when your users win, so don’t drive them to abandon your API for a competitor’s API because you arbitrarily set your limits to low.
2️⃣ Be transparent and informative
Be transparent with users on how you implemented API Rate Limiting and what methods you choose to handle it when users go over their limit.
You really want to make sure that you are upfront with your users if you are going to be charging them for overages.
Clearly, document everything and educate your users, not only about your API Rate Limiting Policy but also about steps they can take to avoid hitting those limits.
3️⃣ Let API consumers know what the status of their API Limits are in every call.
There are a couple of different ways to implement this, but most APIs will add a header to the API response that tells the consumer how many calls they have left for this period and when the counter will reset.
This way API consumers can make informed decisions about when (and how many) API Calls to make.
💡 Learn more about API Strategy and Best Practices [Free Download]