Prevent Duplicate Side Effects in n8n Webhook Workflows

1. Choose a stable event key

Prefer a provider event ID, order ID, payment ID, form response ID, or a deterministic key built from immutable business fields. Avoid timestamps generated inside the workflow: they change on every execution.

2. Check before the side effect

Store the key in a durable system such as your database, CRM, data table, or other atomic store. Before email, payment, CRM creation, or external API mutation, ask whether the key has already been processed.

3. Make the gate race-safe

A simple “search then create” sequence can still duplicate when two executions run at the same time. Where the destination supports it, prefer a unique constraint, atomic upsert, or provider idempotency-key header.

4. Mark completion at the right point

Do not mark an event completed before the critical side effect succeeds. A safer pattern is received → processing → completed, with enough information to recover an interrupted execution without repeating finished work.

5. Test the failure cases

• Send the same webhook twice.
• Send two copies nearly simultaneously.
• Force the downstream API to return an error after the duplicate check.
• Retry a failed execution after the side effect already succeeded.
• Confirm logs contain the event key but no secrets or unnecessary personal data.