n8n Retry On Fail: retry paid API calls without paying twice

n8n's Retry On Fail setting reruns a node after a failed execution until it succeeds or reaches Max Tries, waiting Wait Between Tries (ms) between attempts. On an HTTP Request node that starts paid work, it's safe only when every try sends the same Idempotency-Key and the same body, so a rerun gets the original job back instead of a second charge. Errors a rerun can't fix, such as a bad request or an empty balance, just burn the tries.

n8n facts come from its node settings, HTTP Request node, HTTP Request common issues, rate limits and expressions pages. The paid API is Sume's, from Create a run, Video Generation, Errors and rate limits and Authentication. All were read on 2026-09-29. Sume has no n8n node; this is the HTTP Request node calling its API.

How do I turn on Retry On Fail in n8n?

Open the node, select Settings, and turn on Retry On Fail. Then check the settings around it, because they decide what counts as a failure and what happens after the last try.

Can Retry On Fail create duplicate paid jobs?

Yes, when the first try reached the API but n8n never saw the answer, for example after a timeout. The server may already be running the job, and the retry asks for another. The fix is on the request: send an Idempotency-Key header built with an expression from the item's own data, such as {{$json.row_id}}-video-v1. Sume's docs say to derive it from the thing being made, not from the moment of asking, so never use the current time or a random UUID per run.

On Sume's /v1/videos, a replay with the same key and body returns the original job, and in current code the same key with a different body is refused with 409 idempotency_conflict. So an expression that pulls in a changing value, such as a timestamp in the prompt, breaks the replay. Idempotency keys for AI video APIs lists every replay answer.

Which errors should n8n not retry?

n8n's docs describe Retry On Fail with only two settings, Max Tries and Wait Between Tries, so every failed attempt is retried the same way. Keep Max Tries small, or set On Error to Continue (using error output) and send failures to your own branch. Sume's errors say which reruns can help:

• Worth retrying: a network error or timeout (same key and body), and 429 rate_limited after retry-after.
• Not worth retrying: 400 invalid_request and 409 idempotency_conflict (fix the request), 401 unauthorized (check the key; sending both Authorization and x-api-key is also a 401), and 402 insufficient_credits (add funds).
• Not with the same key: in current code, a same-key resend after 429 queue_full or 503 provider_capacity_exceeded returns that stored refusal again. queue_full means no new paid job fits until an existing one finishes or is canceled, so wait for that, then send a new key.

What should happen when every try fails?

With On Error set to Stop Workflow, the execution fails and, if you've set one, your error workflow runs. n8n error workflow for a failed API job covers the other half: a job that was accepted and later ends failed never fails the HTTP node at all. Idempotency keys for AI video APIs covers key design beyond n8n.