Handling duplicate webhook messages

Identify the incoming message

Your receiver should tolerate the same webhook message arriving more than once. For messages.upsert, the WhatsApp message ID is data.messages.key.id.

Build a deduplication key using the session, event type, chat identifier and message ID. Do not use the webhook timestamp as the message identity, and do not deduplicate every event type by message ID alone: delivery and read updates for the same message still need processing.

Claim work before processing

1. Validate the webhook and extract its message identity.
2. Atomically create a record with that identity in your database or shared store. A unique database constraint or Redis SET NX can prevent two workers claiming it simultaneously.
3. If the work already completed, acknowledge the duplicate without repeating its side effects.
4. Process the claimed work and record completion. Keep a retry path for failures or expired processing locks.

A separate “check, then save” sequence can race when requests arrive together. Do not mark work permanently complete before it succeeds. Use idempotency keys for downstream actions where available.

Using n8n or Redis

In n8n, use a Redis node or a database step to keep shared deduplication state. Ensure the claim operation is atomic; a simple Get followed by Set is not enough under concurrency.

Choose retention long enough for your retry and recovery needs. In-memory state disappears on restart and is not shared between workers. See the n8n integration guide for the recommended community node setup.