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: 
await nango.get({ endpoint: '/some-endpoint', retries: 10 });
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
Find detail about HTTP request retries in the reference.

​
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: 
await nango.get({ endpoint: '/some-endpoint', retryHeader: { at: "x-ratelimit-reset" } });
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.