> For the complete documentation index, see [llms.txt](https://docs.zaui.com/webhooks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zaui.com/webhooks/event-data-payloads/webhook-replay.md). # Webhook Replay Description of the Webhook Replay feature ## Webhook Replay The Webhook Replay feature allows operators to re-deliver any previously sent webhook event directly from the webhook detail screen. This enables recovery from failed deliveries or re-processing of historical events without requiring support intervention. Replay sends the **exact original payload** to the configured endpoint with two additional fields that identify the delivery as a replay. *** ## Overview Webhook Replay allows operators to: * re-send failed webhook deliveries * re-send successful deliveries if reprocessing is required * replay historical events within the retention window * verify endpoint behaviour after fixes * recover from temporary endpoint outages Replay does not modify the original delivery. Each replay creates a new event history entry. *** ## Event History Enhancements The Event History panel includes the following updates: ### HTTP Status Badge Each row displays a colored badge showing the HTTP response: * Green — successful delivery (2xx) * Red — failed delivery (non-2xx) * Red (0) — connection error This makes failed deliveries immediately visible. *** ### Replay Button Each event row includes a **Replay** button. Clicking Replay: * re-sends the original payload * sends to the same endpoint URL * creates a new event history entry * does not modify the original row Replay is available for both successful and failed deliveries. *** ### Replay Row Indicator Replay deliveries are marked with a **Replay** indicator in the Source column. This distinguishes replayed events from original deliveries. *** ## Retention Window The Event History panel displays the last **30 days** of webhook deliveries. This window defines the available replay period. *** ## How Replay Works When replaying a webhook: * the original payload is re-sent unchanged * two additional fields are appended to the payload * the original `eventNotificationUniqueId` is preserved * signature header is regenerated * endpoint URL remains unchanged *** ## Replay Payload Fields Replay deliveries include two additional fields at the root of the payload: | Field | Type | Description | | -------------------- | ------- | ----------------------------------- | | `_isReplayPayload` | boolean | Always `true` for replayed payloads | | `replayOfEventLogId` | integer | ID of the event log being replayed | Example: ``` { "_isReplayPayload": true, "replayOfEventLogId": 18342} ``` These fields are **only present on replayed deliveries**. *** ## Idempotency Behavior Replay preserves the original: ``` eventNotificationUniqueId ``` This allows consumer systems to safely de-duplicate replayed events. Recommended approach: * store processed `eventNotificationUniqueId` * ignore duplicates * treat replay as safe re-delivery Replay assumes webhook consumers are idempotent. *** ## Signature Handling Replay deliveries: * regenerate `Zaui-Signature` * use same signing algorithm * use same secret phrase * remain verifiable without changes No updates are required for signature validation. *** ## Event History After Replay When replaying an event: * a new event history row is created * the original row is unchanged * replay row is marked as Replay * rows are linked internally * replay chain is flat All replays reference the original event.
*** ## Replay Cooldown To prevent accidental duplicates: * each row has a 30 second cooldown * replaying same row within cooldown is blocked * different rows can be replayed immediately * cooldown is independent per row Example error: ``` Please wait Xs before replaying this event again ``` *** ## Slack Notifications Replay deliveries do **not** trigger Slack notifications. Only: * original deliveries * test payload sends trigger Slack alerts. *** ## Replaying a Webhook To replay a webhook delivery: 1. Navigate to Notifications → Webhooks 2. Open the webhook 3. Scroll to Event History 4. Locate the delivery row 5. Click Replay 6. A new replay row appears Notes: * original row remains unchanged * replay creates new row * payload is identical except replay fields * cooldown applies per row *** ## Developer Integration Notes Replay payloads include: | Field | Type | Present On | Description | | --------------------------- | ------- | ----------- | ------------------------- | | `_isReplayPayload` | boolean | replay only | Indicates replay delivery | | `replayOfEventLogId` | integer | replay only | ID of replayed event | | `eventNotificationUniqueId` | string | all | preserved for idempotency | | `Zaui-Signature` | header | all | regenerated signature | Consumers should: * treat replay as duplicate safe * deduplicate using eventNotificationUniqueId * optionally branch logic on `_isReplayPayload` *** ## Best Practices Webhook consumers should: * implement idempotency * ignore duplicate event IDs * safely handle replay deliveries * not rely on delivery order * allow re-processing of events Replay is designed to be safe for all consumers. *** ## Does this modify existing payloads? No. Replay: * does not change original payload structure * does not change field values * only appends replay fields * preserves eventNotificationUniqueId