A signature answers who sent these bytes and whether they changed. It does not say this is the first delivery of the business event or that the resulting action is still appropriate. Providers retry webhooks after failures, and an operator may resend an event. In Stripe's webhook documentation, a retry gets a fresh signature and timestamp. That delivery can pass a strict signature and recency check even when the same event was already processed. Stripe also documents tracking event IDs to handle duplicate deliveries.

Imagine an entitlement event starts an agent run. The agent grants access, but the webhook handler times out before returning success. The provider retries. Both signed requests are valid. If the handler starts a fresh run keyed to delivery attempt instead of event identity, the grant action may run again. Sometimes a duplicate grant is harmless. A repeated welcome email, credit or role escalation may not be. Bind a durable inbox record to provider, account and event ID, and atomically claim it before launching downstream work. Give the actual mutation a stable idempotency or operation key as well, since a workflow can retry independently of the webhook.

There is a second issue called replay. An attacker who captured an exact signed request might retransmit it. Check the provider's signed timestamp within a documented tolerance using a sane clock. Do not set a zero tolerance without checking its actual meaning. Stripe's docs warn that zero disables their recency check. Freshness blocks an old captured request, but it does not replace event deduplication because a legitimate retry is freshly signed. Conversely, event deduplication does not prove authenticity. Both controls have jobs.

For the test, deliver the same event twice with distinct valid delivery signatures, race two handlers, then crash after the business mutation but before the HTTP acknowledgment. Verify a single durable effect and an auditable record for both deliveries. The webhook JSON is valid. Why does signature verification fail after a refactor? is about verifying the raw webhook bytes after a JSON refactor. This page starts with successful signature verification and asks what prevents repeated authorized work.