n8n check · idempotency
n8n Idempotency: Prevent Duplicate Business Actions
Idempotency is the design property that lets a repeated business event produce the intended state instead of another unintended create or append. This check focuses on the static signals visible near create-like writes.
What is this risk?
A workflow is safer to replay when it can recognize the same business event through a stable key, an idempotency key, a unique constraint, an upsert, or an explicit deduplication step.
Create and append operations are not automatically wrong. The review question is whether a duplicate webhook, retry, or manual re-run has a defined outcome for the downstream system.
Typical failure pattern
The same business event is accepted twice
- Webhook or event arrives
- Create or append operation succeeds
- Redelivery, retry, or manual replay repeats the path
- A second contact, row, message, or record is created
Why it matters
- Duplicate records can trigger duplicate notifications, billing actions, fulfillment work, or downstream automations.
- A retry can be correct for transient transport failure and still be unsafe for a non-idempotent external operation.
Auturance signals
WL006Create/append operations may duplicate business data
This is the current scanner signal associated with this check.
What Auturance checks
- Flags create, insert, and append-like writes without an obvious nearby duplicate-prevention signal.
- Recognizes business-key, idempotency-key, unique-key, event-ID, deduplication, and nearby lookup/search signals as static evidence.
- Keeps a nearby lookup as evidence to review, not proof of end-to-end idempotency.
What Auturance cannot determine
- It cannot verify the external system’s uniqueness constraint, business key semantics, or final stored state.
- It cannot observe webhook delivery behavior, manual re-execution, or whether an upstream event is replayed.
- A clean result does not prove that every create or append operation is safe to repeat.
How to reduce the risk
- Choose a stable business key that identifies the event or entity across retries and replays.
- Prefer an upsert, update-or-create, idempotency key, or unique constraint where the target system supports it.
- Test duplicate delivery and partial completion against a production-like downstream system.
Related checks
Related resource
Use the production readiness checklist for the broader production-readiness review.
Related guide
See what your workflow reveals
Upload an authorized n8n export and review the static signals in its actual graph.