n8n's guide to 429 errors: read Retry-After, back off with jitter, and never blindly retry a request that creates records

Rate limits rarely fail on a quiet Tuesday. They fail during the big import, the backfill or the campaign send.

What happened

n8n published a guide to handling API rate limits in workflows. The core distinction: a rate limit caps requests in a period and may reject extras with a 429 Too Many Requests error, while throttling may delay or queue them instead. Either way, the provider sets the limit and your workflow decides how to respond.

The guide's recovery advice:

• If the 429 response includes a Retry-After header, use it instead of guessing.
• Otherwise use exponential backoff, for example 1, 2, 4 then 8 seconds, with a maximum delay and a retry limit.
• Add jitter, a small random delay, so workflows that failed together do not retry together.
• Check that a request is safe to repeat. Requests with side effects can perform an action twice.

It also notes that limits are measured differently. Fixed windows reset on a clock, sliding windows look back over a moving period, token buckets allow short bursts and leaky buckets smooth traffic into a steady flow. In n8n, you can pace calls with the HTTP Request node's Items per Batch and Batch Interval, use Loop Over Items with a Wait node, set Retry On Fail with Wait Between Tries, cap concurrency, and send persistent failures to an error workflow with the Error Trigger node.

My take

The line I would underline is the one about side effects. In CRM work, a retried "create contact" or "create deal" call can quietly make duplicates, and nobody notices until the sales team does.

How I set these up for clients:

1. Search before create, or use the CRM's upsert where it exists, so a retry finds the record instead of copying it.
2. Pace first. Batch size and interval set from the provider's documented limit, not from a guess.
3. Retry with backoff and a hard stop, then hand off to an error workflow that logs the item and alerts a person.
4. Run backfills outside business hours so live automations keep their share of the limit.

Pacing is cheap. Cleaning a thousand duplicate contacts is not.

If your flows break whenever volume spikes, start at romielwillautomate.dev.