A failed step in an automation leaves you with a choice: try again, or stop and tell someone. Get it wrong in either direction and you pay for it—duplicate orders, silent data corruption, or an inbox full of false alarms. The decision isn’t really about how often something fails; it’s about whether the step is safe to repeat.

The core question: can the step run twice without damage?

AWS’s builder guidance on idempotent APIs puts it plainly: retrying a service call as a fix for a transient fault rests on a simplifying assumption—that the operation can be retried without side effects. That assumption is only valid when the API you’re calling is idempotent. An idempotent operation is one where retransmitting the same request produces no additional side effects beyond the first execution.

In practice this means: if the step calls an endpoint that charges a card, creates a record, or sends a message, and that endpoint doesn’t implement an idempotency contract, a retry can execute the action twice. The workflow had one error; now it has one error and a duplicate charge.

The rule: retry only when the target operation is idempotent. Stop and surface the error for everything else.

What idempotency actually requires on the server side

It isn’t enough for a vendor to say their API is idempotent. The guarantee needs to be backed by real mechanics. AWS says its preferred approach stores the parameters of the original request alongside a client-supplied request identifier, then checks incoming requests against that record. If a retry arrives with the same identifier but different parameters, the server returns a validation error—because the same identifier with different parameters likely means the client is making a different request, not repeating the original one. (source)

The server-side storage and the original operation also need to happen atomically—either both commit or neither does. Without that ACID guarantee, a crash between recording the token and completing the action can leave the server thinking it finished something it didn’t. (source)

What this means for you when evaluating a third-party API: look for explicit documentation of an idempotency key parameter and some description of how the server handles duplicate requests. A claim of idempotency without those mechanics is less concrete than an explicitly documented contract.

Validation errors are stop conditions, not retry candidates

The AWS guidance draws a sharp line here. A well-designed idempotent API delivers a specific promise: any error that is not a validation error can be overcome by retrying. (source) In AWS’s example, a validation error can mean the request doesn’t match the original idempotent request. Retrying an invalid request will fail the same way every time and do so while consuming rate-limit quota and execution time.

Map this to your error handling: network timeouts, 503s, and similar transient failures on an idempotent step → eligible for retry. A 400 with a parameter mismatch or missing required field → stop immediately and route to an error alert.

Routing errors in n8n

n8n doesn’t expose a built-in per-step retry policy from the documentation available here, so the retry-or-stop decision is one you implement in your workflow logic. What n8n does provide is a structured error-routing system.

For each workflow you can designate an error workflow in Workflow Settings. That secondary workflow runs automatically when the primary execution fails. (source) This is where your alert goes—a Slack message, a ticket, an email—along with whatever execution context you need to investigate.

If the failing step is a trigger node rather than a later step, the payload delivered to the error workflow differs: it carries less execution context and more trigger context, so your alert logic may need to handle both shapes. (source)

You can also insert a Stop and Error node at any point in a workflow to force a failure under conditions you define—for example, when a response body contains a validation error code that would otherwise look like a 200. (source) Pairing that node with the error workflow gives you deliberate, inspectable failure rather than silent bad data moving downstream.

A practical decision sequence

Before you wire up any external call in a workflow, ask these questions:

  1. Does this API document an idempotency key mechanism? If no, treat every failure as a stop condition. Do not retry.
  2. Is the error a validation error? If yes, stop regardless of idempotency. Fix the request, don’t repeat it.
  3. Is the error transient (timeout, 5xx, network blip) on an idempotent endpoint? Retry is reasonable.
  4. Has the idempotency token expired? AWS says that for EC2 instances, token validity can be scoped to the lifetime of the resource plus a buffer; after that window, a late-arriving retry may no longer be valid. (source) If you’re retrying well outside that window, stop and alert.

The code you’d otherwise write to handle every fault scenario for every service call—what AWS calls undifferentiated boilerplate—shrinks considerably when the upstream APIs hold up their end of the idempotency contract. (source) Where they don’t, your workflow’s job is to fail cleanly and loudly, not to guess.