I’m calling an external API using the HTTP Request node. The API sometimes takes a while to respond, so I enabled the retry option.The problem is that some requests end up creating duplicate records in the external system.
Describe the problem/error/question
From the execution history, it looks like the request gets retried even though the first request may have reached the API.is there a way to prevent this without disabling retries completely
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Hey @Amidu_Louis Welcome in to the community and Yes, you can keep the retries. The duplicates come from how Retry On Fail works: it re-runs the whole node, not just the request that failed. The HTTP Request node sends every item it received, and if one of them errors the node fails and the retry sends all of them again, including the ones that already created their record.
Put the HTTP Request inside a Loop Over Items with Batch Size 1, so each run of the node handles one item and a retry only resends that one. If the API supports an idempotency key (Stripe calls it the Idempotency-Key header), also send one that stays the same across retries, like an ID from your own data, so a request that timed out after reaching the API can’t create a second record either.
Worth checking Options > Timeout on the node too. Once you add that option it defaults to 10 seconds, so a slower response counts as a failure and gets retried.
The one-item loop only helps if several input items are reaching the HTTP Request node and a retry is replaying successful siblings. It does not solve the timeout case in your question: the same request may already have created the record before the response was lost
I would first check whether the destination accepts a stable idempotency key. If not, keep a business-derived operation reference and reconcile the destination before retrying an ambiguous result.a local “seen” flag alone cannot prove the remote write failed
One thing to add to the Loop Over Items + idempotency suggestions: for a non-idempotent POST I would not use the HTTP Request node’s built-in Retry On Fail at all. It cannot tell a timeout (where the request may already have created the record) from a clean failure.
Instead, set that node to On Error > Continue (using error output) and build your own retry: if the status is 429, or it failed to connect before sending, Wait a few seconds and retry once or twice. If it timed out, first do a GET lookup using your own unique reference for that record, and only re-POST if it is not there. Treat a timeout as unknown, not as failed. Raising Options > Timeout in the node helps, but it does not remove that ambiguity.
This can happen when the API processes the request but n8n doesn’t receive the response in time. The retry then sends the same request again.If the API supports idempotency keys, use a unique key for each operation so repeated requests don’t create duplicate records. If it doesn’t, you’ll need to check whether the record already exists before creating it
Retries are useful, but for POST requests that create data, they aren’t always safe by themselves
One addition to Deepankar’s answer: after raising the timeout, open one of the duplicated executions and look at the first attempt’s error. If it’s a timeout/ECONNABORTED rather than a 5xx, the request probably reached the API, and retrying it blindly will always risk a duplicate. In that case turn off Retry On Fail, set On Error to “Continue (using error output)”, and loop back only on errors where the request clearly never landed (429, ECONNREFUSED). Small tip: the title mentions the Code node, so editing it will help others find this.