n8n HTTP 429: wait for Retry-After instead of guessing

Description and use

In n8n, handle HTTP 429 by inspecting the Retry-After header, throttling requests, waiting the specified time, and capping retries to prevent duplicates.

Problem

An n8n workflow that calls an API will hit HTTP 429 sooner or later, and the common fix of adding a fixed Wait node is unreliable.

Outcome

The custom loop correctly honors Retry-After, reduces burst, caps attempts, and avoids duplicate writes, achieving a PASS after a simulated 429 with a real wait of at least two seconds.

Workflow

• Enable Include Response Headers and Status in the HTTP Request node
• Read status, body, and Retry-After header
• Reduce batch size and set a batch interval matching the provider quota
• If Retry-After present, wait that many seconds (add jitter on top, never subtract)
• If missing or invalid, use bounded backoff (2,4,8s capped at 60s)
• Keep job ID and count attempts; stop or defer if wait exceeds 300s
• Retry writes only when an idempotency key or duplicate check is available

Evidence

Inspect the 429 response, slow the request rate, and honor a valid Retry-After header before retrying.

Source

A 429 can mean a per-second burst, a daily cap or a token limit, and the right fix differs.

Source

If the header is missing or invalid, fall back to a bounded backoff (the lab uses 2, 4 and 8 seconds, capped at 60).

Source

Keep the job ID through the whole loop, count total attempts (four attempts means four in total, including the first), and stop or defer when the wait is too long.

Source