The Webhook Arrived Twice: Deduplicating Webhook Deliveries in n8n

说明与用途

Webhook 提供商可能会多次交付同一事件，导致下游操作重复。快速响应、使用唯一事件键的原子插入、签名验证以及下游操作的幂等性可防止重复。

问题

Webhook providers may deliver the same event multiple times, causing duplicate downstream actions such as duplicate emails or records.

结果

Implementing fast acknowledgment, atomic deduplication on provider event ID, signature verification, and downstream idempotency prevents duplicate processing and ensures reliable webhook handling.

工作流

• 1. Receive webhook request in n8n.
• 2. Verify provider signature on raw body; if invalid, log and return 200.
• 3. Extract provider event ID (or build natural key).
• 4. Attempt atomic insert into deduplication table with unique constraint; if insert fails, return 200 and exit.
• 5. Record event metadata and return 200 to acknowledge receipt.
• 6. Trigger a second workflow or later stage to perform heavy processing (LLM calls, writes, email).
• 7. Ensure downstream actions are idempotent (upserts, deterministic message IDs).

证据

A workflow I ran for months listened for a provider webhook: a payment event, a form submission, a status change. One day a customer got two confirmation emails, and a downstream record was created twice.

来源

The first mistake is doing slow work inside the webhook handler. The provider waits for your response; if your workflow takes thirty seconds to call an LLM, write to three systems, and send an email, the provider's timeout fires first and it redelivers — creating the very duplicate you were trying to avoid.

来源

Rule 2: dedup on the provider's event id, never on arrival time

来源

Rule 3: verify the signature before you trust the payload

来源

Rule 4: make the downstream work safe to run twice anyway

来源

The checklist I actually use ... Webhook handler validates, records, and returns 200 fast; slow work runs in a second stage.

来源