Handle rate limits
Step-by-step guide on how to handle API rate limits with Nango.
External APIs often enforce rate limits to prevent excessive use. When these limits are reached, you’ll start receiving HTTP 429 Too Many Requests
errors, blocking further requests until the limit resets.
To maintain data freshness and avoid disruptions in your integration scripts, it’s crucial to manage your API call volume and handle rate limits effectively. Nango simplifies this process significantly.
Strategy 1: Retry with exponential backoff
The simplest strategy involves retrying failed requests after waiting:
When you configure HTTP requests using Nango’s helper (reference), you can specify the number of retries:
This configuration enables automatic retries on receiving a 429
status code, with the retries spaced out using exponential backoff. This method is efficient because:
- It uses exponential backoff to wait out the rate-limit period.
- Nango syncs can run for up to 24 hours, allowing retries to occur within this window (note that action and webhook scripts have shorter lifespans, see Resource Limits).
- It works for APIs, without requiring any API-specific configurations
Strategy 2: Leverage rate-limit headers
Most of the time, the 1st strategy is sufficient to handle rate limits.
For APIs with stringent limits, Nango provides a more refined and customized approach by automatically parsing API-specific rate-limit headers from responses and scheduling retries only after the rate limit period has reset:
This is set up in the same way as the first strategy:
If rate-limit headers are not already configured for an API you are using, you can request their inclusion by reaching out to the Nango team via the community — typically within 24 hours.
Questions, problems, feedback? Please reach out in the Slack community.
Was this page helpful?