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.
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.
🎬 Check out more API videos here! ( BYOP - Bring your own 🍿 )
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!
API Rate limits are typically setup to limit the number of requests either by:
- per second
- per minute
- per hour
- per day (or 24 hour period)
- per month
An API is not limited to picking just one of these. You could have one API Rate limit for 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 users who are anonymous.
Most likely, Yes. But it is 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.
Here are some of the reasons you might hear but not every one of these problems is best solved by API Rate Limits!
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.
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!
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.
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 of time after the limit is reached.
Throttled Stop: You might just want to enforce a slow-down 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.
If you don't want your API Users to hate you, there are three things you need to do:
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.
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 up-front 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.
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 of time and when the counter will reset.
This way API Consumers can make informed decisions about when (and how many) API calls to make.
Brenton House is Vice President of Digital Evangelism at Software AG. As an API and Digital Transformation Evangelist and Strategist, he has connected enterprises with API solutions and microservices, to help drive innovation and overall business growth for many organizations.
In his 25+ years of experience, he has worked across many industries including broadcasting, advertising, retail, financial services, supply chain, transportation, technology, and publishing -- gaining a breadth of knowledge on all things APIs and Integrations. His diverse experience set and unique creative skill sets have enabled him to equip organizations in creating captivating and innovative products that delight users.
⭐ Software AG Blog ▪ https://blog.softwareag.com
⭐ API Knowledge Portal ▪ https://knowledge.softwareag.com
⭐ Software AG Tech Community ▪ https://techcommunity.softwareag.com/
🎬 Software AG YouTube Channel ▪ https://youtube.com/softwareag
🎬 Brenton House's YouTube Channel ▪ https://youtube.com/brentonhouse
🎬 API Shorts YouTube Channel ▪ https://youtube.com/apishorts
👇👇👇 FREE online API Maturity assessment here! 👇👇👇