Tips > AI & LLM Integration

Handle LLM Rate Limits with Retry and Exponential Backoff

LLM APIs enforce rate limits and return HTTP 429 (Too Many Requests) when you exceed them.

TipIntermediate2 min read

LLM APIs enforce rate limits and return HTTP 429 (Too Many Requests) when you exceed them. In batch workflows that process hundreds of items, hitting rate limits is not a possibility -- it is a certainty. Configure retry behavior proactively rather than discovering failures in production.

Real-world example: A workflow processes 500 customer feedback items through GPT-4o for sentiment analysis. Without retry logic, the workflow fails at item 87 when the rate limit kicks in.

n8n node-level retry settings (available on any node via Settings tab):

Setting Value
Retry On Fail Enabled
Max Retries 5
Wait Between Retries (ms) 1000

Warning: n8n uses fixed-interval retries

n8n's built-in retry mechanism uses a fixed wait interval between attempts -- it does not have a built-in exponential backoff option. For true exponential backoff, use a Code node wrapper as shown below.

For exponential backoff, use a Code node with manual retry logic:

const items = $input.all();
const results = [];

for (const item of items) {
  let attempts = 0;
  let success = false;

  while (attempts < 5 && !success) {
    try {
      // Your API call would go here via $helpers or HTTP request
      results.push({ json: { ...item.json, status: 'processed' } });
      success = true;
    } catch (error) {
      attempts++;
      if (error.message.includes('429') && attempts < 5) {
        // Exponential backoff with jitter
        const delay = Math.pow(2, attempts) * 1000 + Math.random() * 1000;
        await new Promise(resolve => setTimeout(resolve, delay));
      } else {
        results.push({ json: { ...item.json, status: 'failed', error: error.message } });
        success = true; // exit loop, log failure
      }
    }
  }
}

return results;
```text
> **Tip: Batch Size Control**
>
> If you are processing items in a loop, add a **Wait** node with a 200-500ms delay between iterations. This "self-throttles" the workflow to stay under rate limits. Cheaper than retries.

Proactive rate limit handling is the difference between a workflow that runs reliably at scale and one that fails unpredictably.

**Related:** [Use Manual Trigger During Development Instead of Webhook or Schedule](../api-cost-optimization/01-use-manual-trigger-during-development-instead-of-webhook-or-schedule.md) | [Flatten Deeply Nested API Responses](../code-node-mastery/01-flatten-deeply-nested-api-responses.md)

Want this running in your stack?

I build production n8n and Cloudflare automation for teams — the same engineering behind HarperFlow. Fixed-price, escrow-protected, US-based.