429 errors in n8n: taming OpenAI and Anthropic rate limits

A workflow that triages 200 emails with AI or ingests 300 PDF pages into a vector store fires off dozens of calls to OpenAI or Anthropic within seconds. At low volume, everything sails through. The day a client imports their full email history, or the daily digest runs on a busy Monday morning, the execution lights up with red nodes: 429 Too Many Requests. This isn't a bug in n8n or your prompt — it's a rate limit, and it's fixed with three specific mechanisms, not crossed fingers.

What a 429 actually measures

OpenAI and Anthropic don't just bill per token — they also cap throughput, on several axes at once:

• RPM (requests per minute) — the number of calls per minute, regardless of size;
• TPM (tokens per minute) — the volume of tokens (input + output) processed per minute;
• for Anthropic specifically, ITPM and OTPM split input and output tokens separately.

These caps depend on your account's tier, which climbs automatically with payment history: an OpenAI account just funded with $5 sits around 500 RPM on GPT-4o, while a long-established account can reach several thousand RPM. A pack that worked flawlessly in testing with ten emails can hit a wall the moment it runs in production on real volume — with nothing changed on the n8n side.

Every 429 response carries useful clues: Anthropic returns a retry-after header (seconds to wait) alongside anthropic-ratelimit-requests-remaining and anthropic-ratelimit-tokens-remaining headers indicating which of the two limits was crossed. OpenAI exposes the equivalent (x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens). Ignoring those headers and retrying in a tight loop only makes things worse.

First move: Retry On Fail, tuned correctly

On the OpenAI, Anthropic, or HTTP Request node in question, the Settings tab offers Retry On Fail. Enabled alone, it retries immediately — useless against a rate limit, since the window hasn't had time to free up. The setting that actually matters is Wait Between Tries (ms), pushed well above the delay suggested by retry-after (1,000-3,000 ms is a reasonable generic starting point). Combined with 2-3 max attempts, this single setting already absorbs isolated spikes — a burst of emails, a one-off traffic peak.

This mechanism stays local, though: it protects a single call, not a batch job. For a workflow looping over dozens or hundreds of items — exactly the case for email triage or document ingestion — you need to go one level up.

Loop Over Items (Split in Batches) + Wait: the real fix for batches

The Loop Over Items node, historically named Split in Batches, breaks a set of items into batches processed one at a time instead of all at once in parallel. Paired with a Wait node placed after the AI call and looped back to the Loop's input, it imposes a pace:

1. Loop Over Items — batch size set below your actual RPM (see the calculation below).
2. AI node (LLM chain, Anthropic/OpenAI node, or embeddings) — the call that consumes the quota.
3. Wait — a fixed pause between batches (often 500 ms to 2 s depending on tier).
4. Loop back on the Loop Over Items' "loop" output until items are exhausted; the "done" output takes over once the batch finishes.

Practical sizing: divide your RPM by 60 to get a per-second rate, keep a 20-30% margin, then choose batch size and pause accordingly. At 500 RPM, targeting roughly 5-6 calls per second means a batch of 5 items followed by a one-second pause — more than enough for an email digest across several hundred messages, or a large PDF ingestion job like the one in our Supabase pgvector RAG guide. Both the RAG Assistant Pack and the Inbox AI Pack handle inherently variable volumes; this pacing is the first thing to check if a bulk import triggers 429s where a single-item test passed cleanly.

Honoring retry-after instead of an arbitrary backoff

For cases where the rate limit depends heavily on content (TPM rather than RPM — a very long document consumes a large chunk of the quota in one go), a fixed pace isn't always enough. The robust approach is to read the retry-after header from the error response and wait exactly that long before retrying, instead of guessing a delay. Concretely in n8n:

• An HTTP Request node calling the API directly (rather than the dedicated node) exposes the full error response, headers included, usable in a following Code node.
• On a 429, that Code node reads retry-after, adds a little jitter (a few hundred random ms, so multiple executions don't all wake up at the exact same millisecond), then drives a Wait node with that dynamically computed delay instead of a fixed value.
• Past two or three consecutive failures on the same item, it's better to log it as "needs reprocessing" (a dedicated Supabase table, for instance) than to keep hammering it indefinitely — the same principle behind the audit trail described in our GDPR logging with Supabase article.

A recommended architecture for high-volume AI pipelines

For asynchronous processing (an overnight digest, document ingestion, a follow-up campaign), the combination that holds up over time is: a Supabase queue receiving items to process, a cron trigger waking the workflow on a regular interval, a Loop Over Items paced as described above, and a dedicated Error Workflow (see our guide on error handling in n8n) that catches definitive failures for alerting instead of letting the execution die silently. This architecture decouples the processing pace from the data's arrival pace: whether 5 or 500 emails show up at once, the pipeline advances at its own rate, never exceeding the quota.

Common pitfalls

• Accidentally parallelizing: an upstream Split node followed by "for each item" processing without Loop Over Items fires nearly all calls at once — the #1 cause of 429s in production.
• Confusing RPM and TPM: a batch of short messages respects RPM but can saturate TPM if each one carries a long conversation history; watch both headers, not just one.
• Unbounded retries: without a max-attempts cap, one persistently problematic item (content that reliably triggers an error) can stall an entire execution.
• Forgetting your account's tier: a freshly created OpenAI or Anthropic account starts on the lowest tier; check your actual limits in the console before sizing batches.

Going further

This pacing — Loop Over Items, Wait, header inspection — is already built into the ingestion and triage workflows of the Inbox AI Pack (€79) and the RAG Assistant Pack (€119), sized by default to stay under both providers' entry-level tiers. If you're wiring up your own credentials, our guide to connecting Claude or GPT to n8n covers the initial AI credential setup — the piece that naturally comes before this pacing work once your workflows run in production on real volume.