Duplicate Webhook

Overview

A Duplicate Webhook is a webhook event delivered more than once to the same endpoint or consumer. It differs from two different events that describe the same object; both transport-level event IDs and business-object identifiers may be needed to detect semantic duplicates.

The main risks include duplicate order fulfillment, repeated payout or refund actions, duplicated ledger records, and noisy customer communications. At-least-once delivery systems may intentionally retry when acknowledgement is missing or uncertain, so duplicate delivery is an expected integration condition.

In production, teams should define ownership and apply event ID storage, object-and-event-type checks, atomic deduplication, immutable event logs, safe acknowledgements, and bounded retention. Replay of Duplicate Webhook should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.

Useful measures include duplicate delivery rate, deduplication hit rate, side-effect suppression rate, and duplicate investigation count. Duplicate Webhook is closely connected to Duplicate Callback, Webhook Deduplication, and Webhook Event Log. A receiver should treat transport acknowledgement and successful downstream processing as separate states for Duplicate Webhook.

Monitoring for Duplicate Webhook should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events. For Duplicate Webhook, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.

The Duplicate Webhook path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state. Recovery for Duplicate Webhook should combine replay controls with an authoritative status check rather than trusting delivery history alone. A Duplicate Webhook handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.