Can I deduplicate only inside n8n memory?
Not for durable guarantees. Process memory can disappear on restart or scale-out. Important idempotency state belongs in a durable store or in a destination that enforces uniqueness.
D2 Automation Knowledge
Webhook Idempotency: Prevent Duplicate Events from Creating Duplicate Side Effects
How to design stable event keys, durable processed state and retry-safe webhook workflows in n8n and API integrations.
Written by: D2 Automation SystemsReviewed by: D2 Systems EngineeringPublished: 2026-08-21Updated: 2026-08-21
Direct answer
The practical answer
Assume a webhook can be delivered more than once. Idempotency means processing the same logical event repeatedly produces the same final state without repeating irreversible side effects such as creating two CRM records, charging twice or sending duplicate notifications. The practical pattern is: derive a stable event/business key, persist claim or processed state, make downstream writes conditional, and treat retries as normal execution rather than exceptional execution.
Engineering model
Idempotent processing = stable event key + durable claim/processed state + conditional side effects + replay-safe transitions
01 / Design rule
Transport delivery is not business uniqueness
A webhook request ID may identify one delivery attempt, while the business event has its own identity such as order ID plus status transition. Choose the key that represents the side effect you need to protect.
02 / Design rule
Persist before expensive processing
For important events, record the raw event or a durable claim before calling slower downstream systems. This decouples webhook acknowledgement from business processing and gives operators evidence for replay and investigation.
03 / Design rule
Protect the side effect, not only the workflow
A workflow execution can be unique while a downstream API call is still repeated after a timeout. Use upsert keys, unique constraints or idempotency keys where the destination supports them, and persist state around ambiguous failures.
04 / Design rule
Replay should be an intentional capability
A good recovery path lets an operator replay a failed event without bypassing the same idempotency controls. Replay tooling that skips dedupe is a second failure mode disguised as an operational convenience.
Implementation checklist
Questions to resolve before calling the workflow production-ready.
- Define logical event identity
- Store event/claim durably
- Add unique constraints or upsert keys
- Handle ambiguous timeout outcomes
- Test duplicate delivery and replay
FAQ
What if the provider has no event ID?
Build a deterministic business key from fields that define the protected transition, and document collision/ordering assumptions. Avoid hashing the entire raw payload when non-business fields change between retries.
Evidence standard
Architecture knowledge, implementation evidence and production outcomes are different claims.
D2 publishes these boundaries explicitly. The methodology page explains what evidence is required before a system is described as implemented, validated or production-backed.
Read D2 evidence methodologyRelated system evidence
See the engineering decisions applied in D2 case studies.
Apply the framework