You build your first integration, you've tested it and you're feeling great. You then onboard your first customer, and the alerts start coming in. Your customer is calling you. They're angry. You dig into your alerts and see... 429 Error: Rate Limit Exceeded.

What does this mean? Looks like you hit your first rate limit.

In this article, we explain what API rate limits are and why they exist. Unfortunately, the types of rate limits you might run into can vary wildly depending on the API, and we share the most common types of rate limiting that you might run into.

If you're interested in learning more about how to build a robust rate limit tracker -- we have a detailed article on this here.

{{blog-cta-100+}}

What is rate limiting?

3rd party APIs will sometimes implement a rate limit to prevent their users (or malicious actors) from flooding their servers with too many requests. In the worst case, these efforts are called DDoS (Distributed Denial of Service) attacks and can lead to outages of that third-party’s platform, leading to downtime for all of their customers.  

Related: API rate limiting best practices

Why you should care about being rate limited

Not handling rate limits properly can lead to the following issues:

1. Account Suspension: Accounts that continually violate rate limits can be marked by 3rd parties as "bad actors" attempting DDoS attacks. 
2. Write Blocking: If an integration reaches its rate limit, the third party will likely stop processing requests. This is especially pressing for WRITE/UPDATE/DELETE operations, which often need to happen with a fast turnaround.
3. Degrading Integration Performance: At Merge, we’re aware that we may not be the only client using an API instance for data management. We never want to negatively impact other services that our end-users and partners have built.

If you are dependent on a fresh data from an API, it's especially important that you build around the API provider's rate limits. Especially at Merge where our customers and their customers are directly impacted by our integrations -- any one of these outcomes is unacceptable.

To prevent being rate limited, it’s generally best to practice to stay under a set threshold below the 3rd party's rate limit, as opposed to running right up to that limit. 

4 ways you will be rate limited

At Merge, we have seen hundreds of APIs, and have observed four major ways APIs implement rate-limiting. These are:

1. Request Frequency Rate Limits: these are limits based on the number of requests in a defined time range. Generally, limits are configured to be a number of requests per second (for example, 10/s), but others can be hourly, daily, or even weekly.
2. Fetched Model Count Rate Limits: these are limits based on the amount of data fetched in a defined time range. These limits will often be configured as "entities" or "models" returned in response to payloads from the 3rd party. Similar to frequency, they can have varying degrees of time ranges and cutoff points.
3. Concurrent Sessions Rate Limits: these are limits based on the number of active client/server sessions established with the 3rd party service. These rate limits are typically not set over a time range, but rather are the current count at any time.
4. Unsuccessful Request Limits: these are limits that will start restricting access if too many unsuccessful requests are made in a row. Generally used to thwart brute force (DDoS) attacks and unbounded exponential backoff. These limits typically have a daily time frame and should have a very low threshold.

As you design your rate limit solution, you’ll want to be aware of how every platform understands its rate-limiting, and make sure to cater your rate limit management for that platform. 

How to build around rate limits

At Merge, we interact with a lot of APIs. This means we’re required to avoid being rate limited in countless ways, at all hours, every day. Because we’re constantly making calls to these APIs, we’ve had to dynamically figure out how to configure our internal backend to handle these rate limits appropriately.

You can oftentimes find rate limit details in API documentation, but unfortunately, there are quite a few API providers that do not publicly share this information.

If you're interested in learning more about how to build a robust rate limit tracker -- we have a detailed article on this here.

Let Merge maintain your rate limits for you

When you launch a new integration, you have to adjust your code base continuously to handle the rate limits. With Merge, the leading unified API solution, the rate limits are normalized and our team addresses the potential maintenance issues outlined above (and much more) to keep your clients’ data reliably syncing and keep your engineers doing what they do best: building.

The platform also provides a variety of unified APIs for key software categories, from CRM to File Storage to HRIS, to ensure you can build all the integrations your customers want and need, quickly.

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