N8n API timed out retry, avoid duplicate writes

n8n api timed out retry: if your HTTP call timed out after a write, first decide whether the remote API write is idempotent. If it is, retry with an idempotency key. If it is not, do not retry blindly, instead use locks, dedupe records, or a compensating workflow to fix duplicates later.

Why this happens

When n8n shows a timeout or network error on an HTTP Request node the execution may have reached the remote service but not received a response in time. n8n can then retry according to node or workflow settings, and that retry may trigger the same write again. The result is duplicate rows, duplicate emails, or repeated API side effects. Community reports show this exact behaviour, including a case where retries re-sent 49 emails after a timeout. See the thread about retries that re-sent emails for real examples.

n8n api timed out retry: quick decision tree

Use this short decision tree before you hit retry or enable automatic retries. It saves time and prevents unsafe retries.

1. Is the remote operation idempotent by API design? If yes, you can usually retry safely with an idempotency key.
2. If no, can you make it idempotent by adding a unique dedupe key or database unique constraint? If yes, add that before retrying.
3. If you cannot make it idempotent, do not retry automatically. Instead acknowledge the trigger and queue a background check or manual review, or use a compensating write to undo duplicates.

Step by step fix you can apply now

1. Stop automatic blind retries. Check the node settings on the failing node and disable aggressive retry policies. In n8n, the node option visible on failures is called Retry On Fail. If you depend on retries, keep them minimal.
2. Add an idempotency key where supported. Generate a key in a Code node and send it in a header like Idempotency-Key or in the payload. Many APIs honour that header.
3. Protect writes with a dedupe store. Use a database table with a unique constraint or a Redis key. Before doing the remote write, insert the dedupe key and abort if it already exists.
4. Use webhook acknowledgement when appropriate. In n8n Webhook nodes set Response Mode to On Received to reply 200 immediately, then process the write asynchronously to reduce timeouts.
5. For non-idempotent APIs, write a compensating workflow that detects duplicates and reverses or flags the extra write. Record the original request details for later reconciliation.

n8n patterns and ready to paste node examples

Below are patterns you can copy into your n8n workflow. Replace field names and table names with your own.

1. Generate an idempotency key in a Code node

Use a Code node named Make Idempotency Key. This example combines a customer id with a timestamp or a request uuid.

const uuid = require('uuid').v4 ? require('uuid').v4() : Date.now().toString();
items[0].json.idempotency_key = `${items[0].json.customerId || 'anon'}-${uuid}`;
return items;

Then send that key in your HTTP Request node headers using the expression field, for example:

Idempotency-Key: {{$json["idempotency_key"]}}

2. Use a Postgres dedupe table before the API write

Create a small table with a unique primary key to prevent duplicates.

CREATE TABLE processed_requests (
  idempotency_key text PRIMARY KEY,
  processed_at timestamptz DEFAULT now()
);

-- In n8n use the Postgres node with parameterized values
-- Attempt to insert, only proceed if insert succeeded
INSERT INTO processed_requests (idempotency_key) VALUES ($1) ON CONFLICT DO NOTHING;

Check the affected rows returned by the Postgres node. If zero, skip the write, because it was already processed.

3. Webhook acknowledgement to avoid timeouts

If your workflow starts from an incoming webhook, open the Webhook node and set Response Mode to On Received. This sends the HTTP 200 quickly and prevents client timeouts. Then continue processing in the workflow or push a job to a queue for slower steps.

4. Compensating write example

If a duplicate gets created, design a small compensating workflow that can find duplicates by matching on dedupe keys or timestamps, then call the remote API to reverse the change, or mark the duplicate in your database for manual review.

Tool specific notes: n8n, Make.com and Zapier

n8n specific tips: the HTTP Request node is where you add headers like Idempotency-Key. Use the Code node to create keys. If a node shows Retry On Fail toggled, verify the retry count and backoff under Workflow Settings if you use built in retry behaviour. For webhook triggers use Response Mode set to On Received.

Make.com scenarios and Zapier Zaps also need idempotency patterns. Make.com calls steps modules and can add custom headers. Zapier supports unique keys too, but if a step times out, most safe practice is the same: make the downstream operation idempotent or record a dedupe key in your own store.

How to stop this happening again

• Add idempotency keys to every write. Prefer the API documented header if available, otherwise add a body field the remote system can use.
• Use database unique constraints or a Redis lock to enforce single processing. A constraint is reliable and cheap.
• Reply quickly to webhooks. Move slow operations into background jobs. This reduces the number of timed out executions.
• Monitor for duplicate emails or writes with a simple daily job that queries recent records and reports anomalies. The n8n forum shows how painful duplicate emails can be when retries run wild.

When to get help

If you cannot change the API server to accept idempotency keys, or if the system already has many duplicated writes, ask for help. Post a minimal reproducible example on the n8n community, including the HTTP Request node setup, your Code node script, and the failure logs. The thread asking how to decide whether to retry is a good starting point for discussion and will help experienced builders see your case fast.

For more on recovering from retry problems and restarting only failed nodes, see our guide on retrying from the failed node.

Following these patterns will let you adopt a safe n8n retry strategy, reduce n8n error handling pain, and eliminate most n8n duplicate emails and duplicate writes in production.

Learn to build automations like this with Automate Naija.

References: community reports where retries caused duplicate emails and where timeouts left users unsure whether to retry, see the n8n forum threads Retry re-sent 49 emails and The API timed out after a write.

Frequently asked questions

What exactly is an idempotency key and how do I use it in n8n?

An idempotency key is a unique identifier for a request so the server can tell repeated calls are the same operation. In n8n, create a key with a Code node and send it with the HTTP Request node as a header like Idempotency-Key. If the server supports the header, it will ignore duplicate requests with the same key.

If my API does not support idempotency headers, what should I do?

Use a dedupe store you control. Insert a record with the idempotency key into a Postgres table with a unique constraint before making the remote call. If the insert fails because the key exists, skip the call. This prevents retries from creating duplicates even if the API lacks native support.

How do I stop n8n from retrying automatically after a timeout?

Edit the failing node and check the node or workflow retry settings, often shown as Retry On Fail. Reduce the retry count and increase backoff, or disable automatic retries for non-idempotent operations. Instead use manual or controlled retry logic with dedupe checks.

What is a compensating write and when should I use it?

A compensating write reverses or corrects an unintended action, for example deleting a duplicated order or sending a cancellation email. Use compensating workflows when you cannot avoid duplicates at write time, so you can repair state later without manual spreadsheets.

Build it with us. The community is free and the build track teaches this kind of automation week by week: see pricing or join the community.