by Eugene Tolmachov (SherpaDesk IT Developer)
There comes a moment in every IT entrepreneur's life when their app or website starts to gain traction, and they begin to see significant increases in traffic and API requests.
While some consider this to be a "Good Problem To Have," the reality is that API request spikes present a big challenge to your IT team. Handle it the wrong way, and your site or app could stop serving your customers the way it should.
The last thing IT entrepreneurs and small business owners want is to reach success by driving a lot of new traffic to their app or website, only to disappoint these hard-earned customers due to the inability to handle a large number of API requests. What can be done to prevent this? Enter rate-limiting your API.
For the last three months, we experienced an exponential increase in the number of requests coming into our SherpaDesk API.
As API developers, we need to make sure that our APIs are running as efficiently as possible by enabling rate-limiting (in a smart way).
Otherwise, everyone on our database could suffer from slow performance. See Twitter's post on rate limiting for a more technical explanation on rate limiting.
But improving performance isn’t the only reason to limit API requests. Rate-limiting is an essential component of internet security because something like a DoS attack can tank your servers with unlimited API requests.
Rate-limiting can also help make your API scalable. So that if your website or app blows up in popularity and there's a spike in API requests traffic it will help prevent increases in lag time.
In this article, we’ll explain what limits we've imposed on SherpaDesk's API and how to build effective strategies around rate limiting.
Let’s start by explaining how rate-limiting works in our API.
LIMITS | REQUEST RATE | |||
---|---|---|---|---|
Single item request | No limits | 600 requests per hour per API token 10 concurrent requests per API token |
||
Group of items (paged) requests | 250 items per request | 600 requests per hour per API token 10 concurrent requests per API token |
||
CSV format requests | No limits | 60 requests per hour per API token 1 concurrent requests per API token |
1- If you have a situation where your app usage is expected to spike beyond its default limit, please file a support ticket with SherpaDesk for help.
2- HTTP Status Code 429 will be returned when a server outage occurs. Please wait 60 seconds before re-trying the request.
3- Any request taking longer than 230 seconds to execute will time out.
4- If you need to handle more than 250 items, please fetch the items in chunks, as described in this wiki-how: Limits & Pages.
5- If a user sends too many requests, our API rate-limiting will throttle the client’s connections instead of disconnecting them immediately. We use a WAIT operation logic to limit our API requests.
We recommend the following practices for the best experience and to reduce interruptions.
You can also use the following response headers to confirm the account's current rate limit.
This header indicates your current server load:
X-Highdtu-Mode: 5
If our server is under heavy load, it will return a 5. If it's experiencing an above-average load, it will return a 2. When receiving a normal load, this header is empty or nonexistent.
This header indicates the number of milliseconds remaining for the next request.
X-Wait: 3000
We calculate this delay with this formula:
If single item: X-Highdtu-Mode *1 = 1 - 5 Seconds
if group of items: X-Highdtu-Mode * 5 = 5 – 25 seconds
After each request, you can check to see if you've bumped into the rate limit. If you get a response code of 429, or "Too Many Requests," it means that you've hit the rate limit.
It's best practice to include code in your script that catches 429 responses. If your script ignores the "Too Many Requests" error and keeps trying to make requests, you might start getting null items.
Make sure you make only the requests that you need. Here are some areas to explore for reducing the number of API requests:
1- Optimize your code to eliminate any unnecessary API calls.
2- Cache frequently used data.
You can also save relatively static information in a database or serialize it in a file.
3- If you need to backfill data, it is best to do so during non-peak business hours. Also, consider using our CSV exports, which are currently in beta.
We’re always working hard to make it easier for you to run your business, and we're always focused on improving SherpaDesk’s usability. Let us know what other features you would like to see on SherpaDesk to help you succeed.
Eugene & the SherpaDesk Team