n8n API Handoff Lab

THE HANDOFF RISK

A retry can repeat writes that already succeeded.

A local routing test does not show what happens when an API fails after a workflow has begun processing a batch. The lab forces that boundary: one request returns HTTP 503, n8n retries the complete HTTP node, and every repeated write must remain safe.

CONTROL PATH

Make replay behavior part of the contract.

1. 01
   Seed

   Create three deterministic example.test records with two stable idempotency keys.

2. 02
   Write

   Send them through one native n8n HTTP Request node to an exact 127.0.0.1 endpoint.

3. 03
   Fail

   Return one synthetic HTTP 503 and allow a bounded three-attempt retry policy.

4. 04
   Replay

   Return the existing contact for an identical key and reject conflicting reuse with HTTP 409.

5. 05
   Verify

   Fail closed unless transport status, attempts, request count, stored state, host boundary, and zero client actions all match.

VERIFICATION EVIDENCE

What was actually executed.

• Native n8n 2.26.8 runThe exact inactive four-node workflow was imported and executed in a fresh temporary n8n user folder on Node.js 24.14.0.
• One real HTTP Request nodeThe workflow contains one POST endpoint bound exactly to 127.0.0.1:45931, a dynamic idempotency header, JSON body, full response capture, and bounded retry.
• Whole-node retry observedThe synthetic 503 caused n8n to replay the complete HTTP node. The mock recorded six loopback requests across three logical items.
• Replay-safe resultThe mock retained two contacts. Final n8n output contained one created result, two replayed results, and ten passing invariants.
• Mutation and conflict guardsA changed verifier outcome fails closed, while a reused idempotency key with different content returns HTTP 409.
• Zero outside accessNo credential, Internet request, client system, real email, webhook, analytics, upload, or external message was used.