Skip to main content

​
Nango API rate limits

The Nango API enforces rate limits on a per-account basis to ensure fair usage across all clients. Limits are applied within a rolling 60-second window. The default limit is 200 requests per minute. Your limit may be higher depending on your plan.

​
Rate limit tiers

Limits scale with your plan. Each tier is a multiple of the base limit (200 req/min):
TierMultiplierRequests per minute
S0.5×100
M (default)1×200
L5×1,000
XL10×2,000
2XL25×5,000
3XL50×10,000
4XL75×15,000
Script-initiated requests (from Nango syncs and actions) are tracked in a separate rate limit bucket from your direct API calls.

​
Rate limit headers

Every API response includes headers that tell you your current rate limit status:
HeaderDescription
X-RateLimit-LimitMaximum number of requests allowed in the current window
X-RateLimit-RemainingNumber of requests remaining before the limit is reached
X-RateLimit-ResetUnix timestamp (seconds) when the current window resets and your quota is replenished

​
When you exceed the limit

If you exceed your rate limit, the API responds with 429 Too Many Requests: 
{
  "error": {
    "code": "too_many_request"
  }
}
The response also includes a Retry-After header indicating how many seconds to wait before retrying: 
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1711900860
Retry-After: 14

​
Handling rate limits

Implement exponential backoff when you receive a 429 response. Use the Retry-After header value as the minimum wait time before retrying. 
async function requestWithRetry(fn: () => Promise<Response>, maxRetries = 3): Promise<Response> {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fn();

    if (response.status !== 429) {
      return response;
    }

    const retryAfter = parseInt(response.headers.get('Retry-After') ?? '1', 10);
    const backoff = retryAfter * 1000 * Math.pow(2, attempt);
    await new Promise((resolve) => setTimeout(resolve, backoff));
  }

  throw new Error('Max retries exceeded');
}

​
Best practices

1

Check headers proactively

Read X-RateLimit-Remaining on every response. If it drops close to zero, slow down your request rate before you hit the limit.
2

Cache responses where possible

Avoid fetching the same data repeatedly. Cache connection tokens, integration configs, and sync records on your side to reduce redundant API calls.
3

Batch operations

When managing multiple connections or triggering multiple syncs, use bulk endpoints where available rather than making one request per item.
4

Use webhooks instead of polling

Rather than repeatedly calling the API to check sync status or connection state, subscribe to Nango webhooks to receive real-time notifications.

​
External API rate limits

When Nango makes requests to third-party APIs on your behalf (via the proxy, syncs, or actions), those external APIs have their own rate limits independent of Nango’s. Nango handles external rate limits automatically:
  • Retries on 429: When an external API returns 429 Too Many Requests, Nango retries the request automatically using the backoff strategy specified by the provider.
  • Retry-After respect: Nango honors the Retry-After header returned by external APIs before retrying.
  • Configurable retries: When using the proxy directly, you can configure the number of retries via the Retries header or the retries option in the Node SDK.
// Configure retries for proxy requests
const response = await nango.get({
  providerConfigKey: 'github',
  connectionId: 'user-123',
  endpoint: '/repos',
  retries: 3,            // Retry up to 3 times on failure
  retryOn: [429, 503]    // Retry on these specific status codes
});
If an external API has strict rate limits, use Nango syncs to fetch data on a scheduled basis rather than making on-demand proxy calls. This distributes load over time and avoids bursting against third-party limits.

Build docs developers (and LLMs) love

Get started for freeTalk to us