Webhook replay
Webhook replay means sending a webhook notification again. Deliberate recovery and replay attacks require different checks.
Webhook replay means sending a previously sent webhook notification again. This can be a deliberate attempt to recover processing that failed during an outage. The term also covers attacks in which someone intercepts a valid message and sends it again.
Limit recovery to the intended work
In a fictional portal, an outage leaves it unclear whether an order notification was processed in the ERP. Before sending it again, the responsible team checks the processing status. It determines which notification may be replayed and how duplicate order creation will be prevented. Sending all stored notifications again without checking would also affect completed operations.
Assess authenticity and repetition separately
Stripe uses signed timestamps against replay attacks and describes duplicate event handling separately. A valid signature alone does not prove that a notification remains unprocessed. Agree both how incoming messages are verified and how already processed operations are handled.
Sources
Related terms
- Event IDAn event ID identifies an event within an agreed scope. A repeat delivery needs to be distinguished from a new event.
- Idempotency keyAn idempotency key identifies retries of the same intended request. Scope, retention and API rules determine its effect.
- Transactional inboxA transactional inbox uses durable message records to protect local processing against duplicate deliveries.
- Message acknowledgementA message acknowledgement tells the broker that a delivery has been received or processed according to the agreed rule.
- Retry jitterRetry jitter varies waiting times randomly to spread retries and reduce simultaneous requests from many clients.
- Test tenantA logically bounded customer context of a multitenant application, configured for testing.
Articles on this topic
APIs & Integration with ASES
ERP, CRM and shop cleanly connected