Your workflow sends a request to create a document. The connection times out before a response arrives. Should it try again? The answer depends on whether the remote service completed the action and how repeated requests are handled.
This article uses a synthetic automation example. It is a design checklist, not a claim about measured incidents or results from a client project.
Treat a timeout as an uncertain outcome
A request can reach a service, complete its work, and lose the response on the way back. Repeating a side-effecting operation may therefore create another document, notification, or order. A timeout tells you that the caller did not receive a timely result; it does not establish the remote transaction’s state.
AWS describes idempotent API contracts as a way to make retries safer. In practice, check whether your provider offers an idempotency key or a request identifier, what operations support it, and how long deduplication is retained. Do not assume that an arbitrary custom header creates this behavior.
Keep one identity for one intended action
Generate a stable identifier for the business operation and retain it across retries. Reusing the same identity for unrelated operations is also wrong. Record enough state to distinguish a new action from a repeat attempt, without placing sensitive data in logs.
If the provider has no idempotent creation API, investigate a status lookup or reconciliation step. A local database can track intent and outcomes, but local deduplication alone cannot prove whether an uncertain external action happened. Some cases need human review rather than automatic replay.
Bound the retry policy
Classify errors. Invalid payloads and expired credentials generally need correction, while some temporary network failures or rate limits may be retryable under the provider’s rules. Use finite attempts, backoff, and any documented retry delay. Make one layer responsible for retrying so multiple layers do not multiply the load unexpectedly.
In n8n, retry and rate-limit handling are implementation tools, not a replacement for business-level duplicate protection. Test the policy against failures at different points in the workflow.
Test the awkward cases
Simulate a response lost after successful creation, a rate-limit response, a permanent validation error, a delayed response, and a manual rerun. Check the final business records, not just the execution status. Document which failures can be replayed and which require reconciliation.
If your automation occasionally creates duplicates, a focused review of action identity, retries, and recovery can be more valuable than adding another integration.