Conquering API Rate Limiting

REST APIs provide a powerful way for developers to integrate their apps with other web services. To ensure consistent access to API resources, many services have rate limits in place for developers. Make sure your app adheres to the rate limits and best practices outlined here to allow the best experience for your users.

Understanding rate limits

Most services provide documentation to understand their rate limiting policies. Let’s take a closer look at an example by examining Clover rate limiting policies. You can find the most up-to-date information on Clover’s Developer Guidelines.

Clover currently has four different rate limits. For reference, these are the current limits as of March 2018.

Per token:

• 16 requests/sec
• No more than 5 requests concurrently

Per app (across all tokens):

• 50 requests/sec
• No more than 10 requests concurrently

These same limits apply to all production and sandbox environments. However, other services may have different limits for different environments.

Handling 429 response codes by exponentially backing off

If your app’s number of requests has exceeded the rate limits, you may receive a 429 Too Many Request response code. Under certain circumstances rate limits may be reduced, system-wide or for particular tokens. We advise to design your app with the necessary fallbacks to gracefully handle receiving an unexpected 429 response.

After receiving a 429 response, your app should pause for a second from sending additional requests . If you continue to receive 429 responses, your app should then exponentially increase the time between request attempts until you receive a successful response.

Note: If your app is making API requests from multiple threads, you will need to make sure all threads are backing off their requests when receiving 429 responses.

If you ignore 429 responses and continue sending requests, you risk getting your service severely interrupted.

Here’s a Python code sample demonstrating exponential back off:

Best practices to avoid 429 responses

At Clover, we recommend the following practices to reduce interruptions and provide the best experience for Clover merchants. However these principles can be applied to almost any API.

• Avoid constant polling by using Webhooks to trigger updates.
• Cache your own data when you need to store specialized values or rapidly review very large data sets.
• Query with modifiedTime filters to avoid re-polling unmodified data.
• Requests to multiple merchants should be staggered as much as possible to avoid bursts of high traffic volume.
• If you need to backfill data, it is best to do so during non-peak business hours. Also, consider using our Export API, which is currently in beta.