External APIs often enforce rate limits to prevent excessive use. When these limits are reached, youβll start receiving HTTPDocumentation Index
Fetch the complete documentation index at: https://nango.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
429 Too Many Requests errors, blocking further requests until the limit resets.
To maintain data freshness and avoid disruptions in your integration functions, 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: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 sync functions can run for up to 24 hours, allowing retries to occur within this window (note that action functions and webhook functions 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 first 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:Related guides
- Sync efficiency - avoid unnecessary provider requests.
- Action functions - design retries for idempotent actions.
- Resource limits - understand runtime constraints.
- Functions SDK reference - configure request retries.