n8n published a guide to building reliable workflows with API idempotency, and it is the clearest short treatment of the problem I have read from a workflow vendor. The setup is the one every automation platform eventually collides with: a retry is the whole point of a workflow engine, and “without an API idempotency in place, a blind automatic retry would cause double entries.” The guide separates the methods that are idempotent by definition — GET, HEAD, OPTIONS, PUT, DELETE — from POST and PATCH, which are not, and then walks the five ways to make the latter safe: an Idempotency-Key header, natural idempotency in the operation’s design, a deduplication log, conditional writes with locking, and webhook deduplication on the event or delivery ID. The caveat is one most treatments omit: “idempotency keys can also cause problems if the same key gets reused for unrelated operations.”
The advice is concrete and correctly ordered. Check whether the endpoints you are calling support idempotency keys before you enable retries. Keep the same key when retrying the same operation and mint a new one for a new operation. Cap the retry count so a persistent error cannot eat your execution budget. Verify a webhook’s delivery ID before processing it. And the framing that makes it practical is that n8n already hands you the primitives — execution.id as a stable identifier, the Data table node as somewhere to keep a dedup log, the Error Trigger node to catch what failed, Set, If and Wait to sequence the recovery.
The catalog reads 15 API pages for n8n, and the guide’s own primitives are most of them. The Execution API is where execution.id comes from — the identifier the post recommends you carry as your deduplication key. The DataTable API is the dedup log it tells you to build. The Audit API is how you reconstruct which retry actually landed, and the Credential API holds what every retried call re-authenticates with.
n8n scores 62.9, strong on the Kin Score — among the higher scores in the catalog — with developer ergonomics at 85.7 and access clarity at 76.3, against contract governance at 4.5. Agent Readiness is 38.6, agent-ready, on a genuinely deep lit row: error_semantics, reversibility_documented, dry_run_mode, mcp_server, agent_skills. Then apply the guide’s own first instruction to the guide’s own author. idempotency is unlit. A reader who takes n8n’s advice — check whether this endpoint supports idempotency keys before you turn on retries — and points it at the n8n API finds the answer is not in the contract. event_surface_described is unlit too, on the platform whose webhook deduplication advice depends on knowing what events arrive. Neither is a product failure. Both are a declaration the company has already written in prose and not yet put where a machine reads it.