Exactly-Once Webhook Processing: The Pattern Every Developer Gets Wrong

Every major webhook provider — Stripe, Shopify, GitHub, Twilio — delivers webhooks with at-least-once semantics. That means duplicates aren't a bug; they're a guarantee. Your system will receive the same event two, three, or more times. If you process each delivery independently, you'll charge customers twice, send duplicate emails, or create duplicate records. Most developers know they need idempotency. The problem is that the most common idempotency pattern has a race condition that fails under real production load. This post covers the wrong way, the right way, and the battle-tested patterns for exactly-once webhook processing. Why Webhook Duplicates Are Inevitable Duplicates happen for multiple reasons, and you can't prevent any of them: Provider retries: Your server returned 200 but the response was lost in transit (network blip, load balancer timeout). The provider sees no response and retries. At-least-once queues: If the provider uses a message queue internally (most do), the q