API Webhook Delivery Idempotency and Replay

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Webhook replay is only safe when receivers make event handling idempotent and preserve delivery evidence.

## Core Explanation

APIs often deliver the same webhook more than once or let operators replay failed deliveries. That is operationally useful, but it can double-charge, double-provision, or double-notify if the receiver treats each callback as unique work.

Agents implementing webhook consumers should store provider event IDs, make side effects idempotent, and document how replay is triggered. A replay recommendation should name the provider, event ID, endpoint, and deduplication policy.

## Source-Mapped Facts

- GitHub documentation describes redelivering failed webhook deliveries. ([source](https://docs.github.com/en/webhooks/using-webhooks/handling-failed-webhook-deliveries))
- Stripe documentation describes processing webhook events that were not successfully delivered. ([source](https://docs.stripe.com/webhooks/process-undelivered-events))
- Stripe webhook documentation recommends logging processed event IDs to handle duplicate events. ([source](https://docs.stripe.com/webhooks#handle-duplicate-events))

## Further Reading

- [GitHub Handling Failed Webhook Deliveries](https://docs.github.com/en/webhooks/using-webhooks/handling-failed-webhook-deliveries)
- [Stripe Process Undelivered Webhook Events](https://docs.stripe.com/webhooks/process-undelivered-events)
- [Stripe Webhook Duplicate Events](https://docs.stripe.com/webhooks#handle-duplicate-events)