A retry is a business decision.

Stripe's current API v1 reference says that POST requests accept idempotency keys. For a given key, Stripe saves the status code and response body after endpoint execution begins. Later requests with the same key return that stored result, including a 500 response. The provider also compares repeated parameters with the original request and rejects a mismatch. That contract is valuable because a network failure no longer forces the caller to guess whether a second create call will create a second object.

The boundaries matter. Stripe documents that keys may be pruned after they are at least 24 hours old; reuse after pruning can create a new request. A validation failure or concurrent conflict that occurs before endpoint execution begins does not save an idempotent result. The key is caller-generated and should not contain sensitive information. A workflow therefore needs to know which operation the key represents, how long retries remain valid, and whether its parameters are identical.

The stored response is not necessarily the final business outcome. A create request can return an object that later moves through other states. A payment flow may continue asynchronously. An email API can accept a message before final delivery. The workflow should store both the request receipt and the business state it expects to observe. Idempotency protects the mutation boundary; reconciliation proves whether the intended process reached its terminal condition.

n8n's executions documentation says an operator can retry a failed execution with data from the earlier run. The operator may choose the currently saved workflow or the original workflow definition. That is a useful recovery feature: a corrected workflow can process the same input, or the earlier definition can be replayed for consistency. It also makes operation identity essential. Two n8n executions may represent one business event.

An n8n execution ID identifies an orchestration attempt. It does not automatically identify the source event, payment operation, message, order, or customer update. If a workflow creates a new random key on every attempt, a manual retry will look like new intent to the downstream provider. The correct key should enter with the source event or be derived from a documented business operation and remain stable across every execution retry.

Workflow version choice adds another dimension. Retrying with the current definition can change validation, transformation, or target selection. Retrying with the original definition can preserve a bug that caused the failure. The recovery record should state which version ran, which input was reused, which operation key was sent, and whether the downstream action began. An operator should not have to infer those facts from a visual canvas after an incident.

The safest design separates preparation from consequence. A retried workflow can re-parse input, re-run deterministic validation, and rebuild a proposal. Before the external action, it claims the stable operation key or calls an API with a documented idempotency contract. After the action, it stores the provider receipt and the expected terminal state. If the action phase is uncertain, the workflow stops for lookup or review instead of beginning a fresh mutation.

{
  "operation_key": "order_813:issue_refund",
  "source_event": "evt_1042",
  "parameter_hash": "sha256:...",
  "workflow_version": "refund-v7",
  "status": "processing"
}

{
  "operation_key": "order_813:issue_refund",
  "provider_request_id": "req_...",
  "provider_object_id": "re_...",
  "business_state": "refund_pending",
  "status": "accepted"
}

The operation key names the business intent, not merely the payload. The parameter hash detects accidental changes without storing sensitive content in the key. The source event connects the action to its cause. Workflow version explains which transformation and policy ran. Provider identifiers support lookup and support cases. Business state distinguishes request acceptance from the terminal outcome the process actually cares about.

Design the receipt before the happy path. Ask which fields would let an operator decide, one hour later, whether another action is safe. If the answer depends on searching logs across three systems and guessing which request belongs to which event, the retry contract is incomplete. A good receipt makes the safe next action mechanical: return the stored result, wait, look up, retry within contract, or escalate.

1. 01

   Repeat after success

   Send the same operation key again and prove one business action.

2. 02

   Repeat during processing

   Race two attempts and prove the claim boundary is atomic.

3. 03

   Change parameters

   Reuse the key with different intent and require an explicit rejection.

4. 04

   Lose the response

   Let the provider act, hide the response, and prove safe lookup or replay.

5. 05

   Replay a new workflow version

   Document whether changed logic may prepare again but cannot act twice.

Count the downstream effect, not just requests or green executions. A test passes when one source intent creates at most one approved action and every repeated attempt converges on a known receipt. Add a negative control with a distinct operation key to prove the design does not suppress legitimate repeated business actions. Test the key retention boundary and the provider's parameter-mismatch behavior, because those are part of the contract the workflow depends on.

Disclosure: this is independent, self-directed source analysis by One Workflow Fixed. It is not endorsed by Stripe, AWS, or n8n, does not describe client work, and does not replace the documentation for the exact API versions and services in a real implementation.