n8n API Retry Repair: Five Cases + 32-Case Follow-up

A synthetic n8n repair demonstration, not client work.

The problem A GET lookup receives a temporary HTTP 429 rate-limit response. The baseline workflow stops after one request.

The bounded change In the HTTP Request node, enable Retry On Fail, set Max Tries to 3 and Wait Between Tries to 1100 ms. The fixture advertises a one-second Retry-After value. The 3000 ms timeout and output schema remain unchanged.

What the tests showed Five cases ran through the actual n8n 1.121.3 engine against a local HTTP fixture: • Baseline transient 429: failed after one request. • Repaired transient 429: succeeded after two requests. • Healthy endpoint: succeeded after one request. • Persistent 429: stopped after three requests without inventing a success result. • HTTP 401: still retried three times and failed, exposing a limitation rather than fixing authentication.

The important limit This is a fixed delay, not dynamic Retry-After handling or exponential backoff. It does not fix exhausted quotas. The demo uses a synthetic GET without side effects; applying retries to payments, emails or record creation requires duplicate controls and separately agreed tests. No production reliability or latest-version compatibility is claimed.

Inspect the evidence The public repository contains before-and-after exports, the runnable harness, observed request timestamps, test results and rollback notes: https://github.com/shivanshjain456/n8n-api-retry-demo

A real repair starts by reproducing one agreed failure with sanitized inputs and safe test access. My bounded n8n repair service is listed on this profile.

Follow-up: response-aware v2 (local engine evidence, 5 November 2026)

I extended this AI-assisted, self-built demonstration to address the original 401 limitation. This is a separate synthetic experiment, not client or production work.

The final suite passed 32 of 32 cases through the actual n8n 1.121.3 CLI on Node.js v24.22.1, using a local HTTP fixture. The original five-case results above remain unchanged.

The retry policy Only HTTP 429, 500, 502, 503 and 504 are retried, with a maximum of three total attempts and a configured 1.1-second wait. HTTP 401 and 403 now stop after one request. Other non-2xx statuses outside the retry list also fail immediately. Redirects are not followed. The response contract: A successful response must contain one JSON object. The workflow returns that parsed JavaScript object without retry metadata; exact equality was checked for the synthetic fixture. This is not lossless JSON round-tripping: JSON.parse can lose precision for large integers and decimals, and keeps the last duplicate key. Empty bodies, malformed JSON, arrays, null and primitive values fail explicitly. Connection resets and timeouts also fail explicitly; this version does not retry transport failures.

What the expanded tests verified • Recovery and exhaustion for all five retryable statuses. • A mixed 429 → 503 → success sequence, and 503 → 401 stopping at the 401. • Immediate 400, 401, 403, 404, 408, 418 and 501 failures; an unfollowed 302. • Healthy 200/201 responses, strict JSON-object validation, connection reset and timeout handling. • Exact parsed-object output, request counts, branch decisions and failure metadata across 50 observed GET requests.

A useful regression surfaced during development: Text response mode could parse JSON before the workflow parsed it again, allowing quoted object text to pass. File response mode plus n8n's built-in binary-buffer helper keeps parsing to one step. The final suite includes that regression case.

Limits and evidence status This is one item and GET only, with fixed waits. It does not implement dynamic Retry-After, exponential backoff, jitter, transport retries, concurrency control or mutation idempotency. Fresh installation, newer n8n versions, the browser editor, live providers and production traffic were not verified.

The GitHub link above contains the original five-case version, not v2. A separate v2 evidence bundle contains the workflow, runnable harness, raw CLI logs, request traces, dependency lockfile and integrity manifest. Its ZIP SHA-256 is 02e020ea136e788321c975c950a3d984ae77c2f12dc5b857b59dc5b0e9d0e3e1.

This multi-node v2 design needs a separate scope review before adaptation to a real workflow; it should not be assumed to fit the agreed repair scope.