What Is Webhook Replay? Definition & Meaning

Definition

Webhook replay resends or reprocesses a previously recorded event so a receiver can recover from an earlier delivery or handling problem.

Overview

Contents Hide

Understand the idea
What actually happens
Decisions and failure cases
Related concepts
Further reading

Understand the idea

A provider replay sends the event again over HTTP, while an internal replay may requeue stored evidence without contacting the provider. Replay tools help recover after outages, code fixes, schema updates, or manual investigation.

Replay is intentionally duplicate delivery and can repeat fulfillment, notifications, credits, or refunds if idempotency is weak. Old events may also conflict with newer state. Modified payloads or lost original headers weaken auditability and signature expectations.

Replay should preserve original event identity and content, record a new attempt identity, require authorized scope, and offer dry-run inspection. Consumers must deduplicate and enforce state versions. Operators should verify final business state and retain who replayed what and why.

What actually happens

A webhook replay is a repeated submission of a previously valid webhook payload, sometimes by an attacker who obtained its body and authentication material. Since a legitimate signature may remain valid for the same bytes, checking only the signature is not enough to prevent repeated processing. Replay defense matters most when webhook processing triggers irreversible actions such as granting access, moving money or changing an order balance.

A receiver should follow the provider's documented signature scheme, verify any timestamp within an accepted tolerance and reject requests with invalid signatures. It must also record event IDs or sequence information durably and make business transitions idempotent. Timestamp checks limit how long an intercepted signed message might be replayed, but a replay within that window still needs deduplication. A service should not accept unauthenticated requests simply because the included payment ID can be looked up.

Decisions and failure cases

Retries by a genuine provider are not automatically malicious. Log safe duplicate deliveries without blocking expected recovery after downtime. Some providers omit signed timestamps, in which case replay protection must use supported event identification and verified status lookups rather than an invented universal timestamp rule.

Webhook, Duplicate Webhook, Webhook Recovery.

Example

An attacker captures a valid 'invoice paid' notification and resends it five minutes later. If the receiver verifies the HMAC but increments a customer's credit each time, the attacker gains extra credits without another transfer. A verified event-ID unique constraint and single-use order transition prevent that effect.

Comparison

Replay concerns reuse of authenticated messages. Forgery creates an unauthorized message; out-of-order delivery brings authentic events in an unexpected sequence. All three need different checks.

Key Takeaway