Webhook replay protection is the set of controls that prevents an attacker, an accidental retry, or an old captured request from causing your system to process the same event more than once. For B2B support, compliance, and public-affairs teams, the practical goal is not merely to verify that a webhook came from a named provider; it is to ensure that the request is authentic, timely, relevant, and safe to process exactly once. A valid signature alone does not provide replay protection. A signature can remain cryptographically valid while an attacker submits the exact same payload minutes, hours, or even days later.
The recommended baseline is HMAC signature verification plus a timestamp freshness window, a short-lived nonce or event identifier check, and an idempotent event-processing operation. Most webhook providers document signature schemes such as HMAC-SHA256, and Stripe specifically advises checking webhook signatures and protecting against replay attacks. The exact implementation varies by provider, so teams should use the provider's official signing format rather than inventing a common header format across vendors. In practice, a five-minute timestamp tolerance and a 24-hour duplicate-event retention window are sensible starting points, but they are policy decisions rather than universal standards.
Also worth reading: How to Implement Webhook Deduplication for SaaS Case Management Systems? · What Are Agent Governance Controls and How Do B2B Teams Implement Them in 2026? · How Do Support and Compliance Teams Implement Agentic Observability in 2026?
What Webhook Replay Protection Actually Prevents
A webhook replay is any reuse of a previously observed signed request. It may be an attacker copying a request from a proxy, log, browser extension, compromised service, or insecure internal system. It may also be an honest operational event: a provider retries because your server timed out, a network appliance duplicates traffic, or a deployment processes the same event queue item twice. Replay protection must distinguish malicious reuse from normal retry behavior, otherwise a legitimate retry can be discarded and a business event can be lost.
The threat is different from an ordinary forged webhook. A forged request usually has an invalid signature and fails immediately. A replayed request has a valid signature because the original sender signed it. If your service accepts all correctly signed messages without checking age or prior use, an attacker can repeatedly trigger actions such as creating duplicate cases, sending duplicate notifications, changing ticket status, or issuing repeated compliance notifications. The impact can be operational rather than financial: duplicate records can corrupt response-time reporting, trigger multiple assignments, and make the public-affairs team believe that several distinct constituent events occurred.
Replay protection should therefore operate at two levels. The first level is cryptographic authenticity: verify the provider's signature against the raw request body and the exact signing input defined by the provider. The second level is semantic freshness: check the event timestamp, enforce a maximum age, and record the provider event ID or a digest of the payload. The first level answers, “Did this provider sign this request?” The second answers, “Should we act on this version of the event now?”
The Recommended Verification and Idempotency Design
The safest practical sequence is to receive the request, preserve the raw body, identify the provider, verify the signature, validate the timestamp, check the event identifier, enqueue the event, and acknowledge it quickly. HMAC-SHA256 is a reasonable default when a provider supports it, but the provider's signing documentation controls details such as whether the timestamp is included in the signed string, whether the payload is canonicalized, and which secret version is used. Never parse and re-serialize JSON before signature verification; insignificant changes in whitespace, key order, escaping, or Unicode representation can cause a legitimate request to fail verification.
A typical server can apply a tolerance of 300 seconds: requests with timestamps more than five minutes old or more than five minutes in the future should be rejected or quarantined. Future-dating matters because a client with clock skew should not be able to mint a request that stays valid indefinitely. A provider may not include a timestamp in its signature, in which case the application can still use a delivery ID, a signed payload timestamp, or a server-side receipt time, depending on the available evidence. If the provider supplies neither a timestamp nor a stable event ID, replay detection becomes weaker and may require storing a payload hash for a limited period.
After cryptographic and freshness checks, make the business operation idempotent. Store a unique key such as provider + account_id + event_id, enforce a database uniqueness constraint, and treat a second insert as an already-processed event rather than an error. If processing involves several steps, use an event record with states such as received, processing, completed, and failed, and design retries to resume safely. Acknowledging the webhook before all downstream work finishes can reduce provider timeout retries, but it increases the need for a durable queue and a dead-letter path. The queue, not the request thread, should own long-running processing.
Timestamp Windows, Nonces, and Event IDs Compared
Teams often use one of three replay defenses: timestamp validation, nonce tracking, or event-ID deduplication. They solve related problems, so the most reliable design normally combines them. A timestamp limits how old a request can be, while a nonce or event ID prevents repeated processing inside the permitted window.
| Feature | Timestamp freshness window | Nonce or one-time token | Provider event ID deduplication |
|---|---|---|---|
| What it detects | Requests outside an acceptable time range | Reuse of the same one-time request marker | Repeated delivery of the same business event |
| Typical retention | 300 seconds to 15 minutes | Until token expires, often 5–60 minutes | 24 hours to 90 days, sometimes longer |
| Main strength | Simple and effective against delayed replays | Strong when the provider supports a signed nonce | Best match for provider retries and queue redelivery |
| Main weakness | Does not stop duplicates within the window | Requires provider support and correct storage | Needs a unique key and durable database state |
| Recommended use | Every supported signed webhook | Use when contractually available | Use for all events with a stable provider ID |
| Common mistake | Checking server receipt time only | Failing to atomically consume the nonce | Keeping the key in process memory only |
Common Failure Modes and Mistakes
The most damaging mistake is accepting a valid signature without checking freshness or uniqueness. Another common error is verifying the signature against a parsed object instead of the original bytes. This can create false failures, particularly for JSON providers that specify a raw-body HMAC. Teams also sometimes log the entire secret, the full signature, or sensitive webhook payloads, turning an observability system into a replay target. Secrets belong in a secrets manager or protected environment variable, and logs should redact authorization material and regulated personal data.
Clock synchronization is an operational prerequisite. If application nodes differ by several minutes, a strict five-minute window can reject valid traffic or make incident diagnosis difficult. Monitor time synchronization across receiving servers, and use NTP or the platform's managed time service. The receiver should also distinguish a stale request from an invalid signature in monitoring, but it should not reveal detailed verification logic to an unauthenticated caller. Returning a generic 401 or 400 response limits attacker feedback; a private event record can retain the reason for authorized operators.
Another mistake is assuming that HTTP delivery is exactly once. HTTP itself does not provide exactly-once processing. A provider may retry after a timeout even when your application completed the work but the response was lost. Conversely, a queue can deliver a message more than once after a worker crash. Idempotency must therefore be designed independently of network delivery. Do not solve duplicates by returning an error to every repeated request, because the provider may keep retrying and create unnecessary traffic. Return success for a recognized duplicate only after confirming that the event is already recorded, completed, or safely scheduled.
Finally, replay protection does not replace authorization or SSRF controls. A webhook endpoint should accept traffic only from expected provider networks where feasible, enforce body-size limits, validate content types, and avoid fetching attacker-supplied URLs during event processing. Request-bin alternatives and webhook debugging tools are useful for development, but they can expose sensitive payloads if deployed without access controls. For production systems, use separate test and production secrets, rotate credentials, and record secret versions so a rotation does not create an outage.
When B2B Teams Should Act and What It Costs
Replay protection should be implemented before connecting a production webhook to a case-management, support, compliance, or public-affairs workflow that changes state. The risk is not limited to large financial systems. A duplicate event can create duplicate cases, incorrectly mark a case resolved, send repeated constituent alerts, or generate misleading SLA and volume reports. Teams handling regulated information should also document the control because audit evidence may need to show that inbound events were authenticated and processed consistently.
A minimum implementation can be inexpensive: a serverless function, a small API service, a managed queue, and a relational table with a unique event key may cost only a few dollars per month at low volume. Costs become more meaningful at high event rates because every request needs cryptographic verification, database work, logs, monitoring, and storage. Infrastructure pricing is less important than the cost of duplicate investigations and bad reporting, which can exceed the engineering cost of preventing duplicates. Vendors such as CoinGecko and crypto webhook providers may offer real-time notifications, but the receiving organization remains responsible for verification and deduplication.
There is usually no separate “replay protection” fee when a webhook feature is included in an API platform. The bill may instead include API calls, queue messages, log ingestion, database operations, or premium security controls. A managed webhook gateway can reduce implementation effort by centralizing signatures, retries, endpoint policies, and observability, but it introduces another service to secure and another vendor dependency. For B2B issue-ops teams, a gateway is often practical when several products send events into one case house. A custom receiver is reasonable when the workflow has unusual compliance requirements, strict data residency needs, or a need to keep raw payload processing under direct control.
The practical deadline is before production launch, not after the first incident. Teams that already receive webhooks should add replay controls as soon as possible: first inventory providers and event types, then measure duplicate deliveries, then implement timestamp and event-ID checks, and finally test provider retry behavior. A reasonable 30-day remediation period is enough for a low-volume service, while systems with active compliance or customer-notification effects should be prioritized immediately. The control should be part of the provider onboarding contract and incident runbook rather than an undocumented server detail.
A Practical Rollout and Validation Plan
Start with one high-value event, such as ticket creation or case-status change, and trace it from provider to downstream action. Capture the request's arrival time, provider event ID, signature result, timestamp result, deduplication result, processing state, and final acknowledgment. Use synthetic requests to test a valid signature, a modified payload, a stale timestamp, a future timestamp, a duplicate event ID, a rotated secret, and a payload that exceeds the size limit. The test should prove both that legitimate events succeed and that duplicates do not create a second business effect.
The rollout should include a shadow mode where suspicious events are logged but not acted upon for a short period. This helps estimate how often a sender's clock or retry behavior violates the chosen window. After reviewing the results, tighten the policy gradually. Keep metrics for accepted events, rejected signatures, stale events, duplicate deliveries, queue retries, processing failures, and provider retry responses. Alert on sudden changes in rejection rates; a jump can indicate a secret rotation error, clock drift, an attack, or a provider migration.
For a case-house SaaS product, document which provider events are idempotent and which are not. A webhook that says “case status changed” should be applied as a state transition with a version or event sequence check when possible. A webhook that triggers an email should use an outbox record keyed by the event, so a retry cannot send two messages. A webhook that starts a long investigation should record a job ID and reuse the existing job. These details matter more than selecting a fashionable gateway or adding a vendor-specific “replay” checkbox.
The final test is operational: revoke the old secret, rotate to the new secret, drain a worker, restart a receiver, interrupt a network connection, and confirm that no duplicate case or alert is created. Record the recovery time and the number of events replayed. A design that passes normal functional tests but fails during a worker restart is incomplete. Webhook replay protection is mature when it behaves correctly under retries, delayed queues, secret rotation, partial failure, and deliberate hostile reuse—not only when a clean test request arrives once.
Provider Documentation and Technical References
The provider's documentation should be the authority for signature construction and retry behavior. Stripe, for example, publishes webhook signature guidance and recommends protecting webhook endpoints from replay attacks. GitGuardian has also discussed exposed Stripe webhook secrets, illustrating why repository scanning and secret rotation matter. Research and comparison material from 2026 includes webhook debugging tools, replay-enabled request inspection, and Node.js HMAC-SHA256 examples, but tutorials are implementation references rather than substitutes for the provider's contract.
For organizations evaluating a hosted solution, ask whether it preserves raw bodies, supports timestamp validation, stores event IDs durably, handles duplicate acknowledgments, separates test and production credentials, and exports audit records. Confirm whether the service's “exactly once” statement refers to transport, queue delivery, or business processing; these are different claims. If it cannot explain its retention period, clock-skew policy, and failure behavior, treat the marketing language cautiously.
The defensible policy is straightforward: verify the provider's signature, reject requests outside a documented freshness window, atomically record a stable event identifier, and make downstream operations idempotent. Store enough evidence to investigate a rejection without storing unnecessary sensitive data, and revisit the policy as provider retries and business workflows change. That approach costs modestly, works across most B2B systems, and reduces the chance that a repeated delivery becomes a repeated operational incident.
Sources: https://docs.stripe.com/webhooks, https://docs.stripe.com/webhooks#verify-official-libraries, https://github.com/GitGuardian