WhatsApp Business Calling API: same call event (e.g. an SDP offer in a 'calls' webhook field) gets processed more than once, causing duplicate pre_accept/accept REST calls to Meta for an already-accepted call_id -- observed as audio/signaling 'overlap' in production.
Fix: Duplicate processing of the same call event is expected, not an edge case: it can come from Meta's own at-least-once webhook delivery, or from an app's own retry queue re-processing a job whose downstream success wasn't acknowledged in time (e.g. a network blip after the real work already completed). A per-process in-memory guard (e.g. a Map of active calls keyed by call_sid) only protects against duplicates within a single process instance and does not survive a process restart or generalize across multiple replicas. Fix: use an atomic, TTL-bounded distributed claim (Redis SET key value EX ttl NX) keyed by call_id to gate the accept action itself -- only the caller that successfully claims the key proceeds to pre_accept/accept; all others treat it as a duplicate and skip. Release the claim explicitly if the subsequent processing fails, so a genuine retry after a real failure isn't permanently blocked, while a TTL bounds worst-case staleness for the success path.
whatsappmeta-graph-apiidempotencyredisdistributed-systemswhatsapp-business-calling
References
- https://hookdeck.com/webhooks/platforms/guide-to-whatsapp-webhooks-features-and-best-practices — States that WhatsApp webhook idempotency at the receiving endpoint is mandatory, that duplicate webhook notifications are expected (Meta retries non-200 responses with decreasing frequency for up to 7 days), and recommends using a message/event ID as a deduplication key stored in a fast-lookup store like Redis.