Handle HTTP 429 Rate Limits in n8n: Retry-After Logic

Stop HTTP 429 failures in n8n—auto-wait and retry using the server’s “Retry-After” header

This credential-free n8n workflow demonstrates a reliable strategy to handle HTTP 429 rate limits by reading Retry-After, waiting the required time, and retrying the request until success (or a max-attempt limit). Perfect for n8n users and automation engineers who want predictable rate-limit behavior.

What this workflow does

• Runs from a manual trigger to execute a self-contained retry loop demo.
• Builds a demo job payload containing retry settings such as maxAttempts, backoff controls (e.g., base/max seconds), and a safeToRetry flag, while preserving request context across attempts.
• Simulates an API behavior: the first attempt returns HTTP 429 with a `Retry-After` header; the second attempt returns HTTP 200.
• Applies a retry policy that interprets Retry-After as either seconds or an HTTP date, then falls back to bounded exponential backoff with jitter when needed.
• Decides whether to retry, stop, review, or defer—based on the attempt count and retry rules.
• When retrying, calculates the provider interval, uses a Wait node to pause, increments the attempt counter, and reruns the simulated request.
• Validates the expected outcome: two attempts, a minimum two-second gap, and the original job ID—then outputs a PASS result.

Use cases

• Rate-limited calls to third-party REST APIs that return HTTP 429 with Retry-After.
• SaaS operators needing safer automation that respects provider throttling policies.
• n8n workflow builders adapting the demo to a real HTTP Request step while keeping the same request context across retries.

Technical details

• Nodes/logic used: if, code, wait, sticky note, and manual trigger.
• Retry controls you can adjust in the initial payload: maxAttempts, baseSeconds, maxInlineSeconds, and safeToRetry.

Tip: To use this pattern in production, replace the simulated response step with an HTTP Request that returns status codes and headers (including Retry-After), while preserving the original request context across retries.