5 API rate limit best practices worth following

As your organization builds to an API, you’ll need to ensure that the build carefully abides by the API provider’s rate limit policies.

Violating them can lead the provider to throttle your requests, block you from accessing their endpoints for a defined period of time, and/or charge you more.

To help you avoid these consequences, we’ll break down several best practices for staying within your rate limit for a given window.

Understand your specific rate limits 

Rate limits don’t just vary from application to application; they can also vary based on the endpoints you’re interested in, whether your requests are authenticated or not, the subscription you’re on, etc.

A screenshot from GitHub's documentation that confirms that authenticated requests have a higher rate limit than unauthenticated requests
GitHub, a developer platform, states in their API docs that authenticated requests have a higher rate limit than unauthenticated requests

Given all the variables that can influence a provider’s rate limits, it’s worth taking a close look at their API documentation to understand your specific situation.

Related: Best practices for managing API logs

Use webhooks when they’re available

Polling API endpoints to see if a resource has been modified, added, or removed can lead to countless wasted API calls. This is especially true when the requested resources change infrequently.

Webhooks allow you to avoid making these calls; you’ll simply receive responses from an application in real-time once the event you care about (e.g., new lead gets created in a CRM) is detected.

It’s worth noting that not all applications support webhooks for the endpoints you care about. So, like the previous best practice, you should review the application’s documentation to see whether they cover it.

A screenshot of GitHub's webhooks documentation
GitHub has dedicated ample documentation on its webhooks, allowing its API consumers to not only confirm which endpoints they support but also how you can create and troubleshoot them effectively 

Adopt exponential backoffs to minimize your rate limit errors

Exponential backoffs, which extend the length of time that passes for retrying requests every time a rate limit error occurs, aren’t a foolproof solution. That said, they can help minimize the number of times that you exceed an API provider’s limits in a given window.

Your exponential backoffs can start by doubling the waiting period for every failed attempt. But if that proves insufficient, you can use more aggressive increments for the delay period.

Related: API pagination best practices

Track your API usage through the provider’s dashboard and/or endpoint

You can proactively stay on top of your rate limits in a given window by using the API providers’ dashboards. Among other insights, they can show you how many API requests you’ve made in a given timeframe, along with how many requests you have available.

Similarly, some API providers let you call specific endpoints to get in-depth insights on your rate limit for a certain window. 

For example, you can make the following API call to GitHub’s /rate_limit endpoint—using cURL—to uncover all of the following information for a given window: the number of requests you’ve made to the endpoint, the amount of requests remaining, your total request limit, and when the window expires.


curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer " \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/rate_limit
  

Note: Many API providers share information on the API calls remaining in the current rate limit window, when the window resets, and the total number of requests allowed during a window within their response headers. When that's the case, it won't make sense to call endpoints like the one referenced above.

Cut down on your API requests by batching them

You can make less requests while still performing the same set of actions on resources by grouping, or batching, your requests. 

However, not all API providers support batch requests, so you’ll need to review their API documentation to confirm that they do. In addition, API providers might have specific requirements, whether that's a certain limit in the number of requests you can make in a given batch, a maximum payload size per batch, etc. So you’ll need to research and understand these requirements for each API provider before going on try this approach.

Related: How to poll API endpoints effectively

Integrate with the applications you care about without worrying about their rate limits with Merge

Merge, the leading unified API solution, lets you add hundreds of integrations to your product by integrating with its unified API. 

Merge's unified approach to integration removes the complexities associated with building and maintaining individual customer-facing API integrations. In other words, you don’t need to worry about individual API provider’s rate limits, along with other aspects, like how they approach pagination and authentication.  

You can learn more about Merge and its unified API by scheduling a demo with one of our integration experts.