Replay a webhook when your receiver missed a recorded event or failed to process its delivery. A replay sends the event again. It does not repeat the registration, renewal, DNS change or payment described in the event.
| Method | Resource | Scope | Idempotency-Key |
|---|---|---|---|
GET |
/v2/webhooks/{endpointId}/deliveries |
webhooks:read |
Not required by this route |
POST |
/v2/webhooks/deliveries/{deliveryId}/replay |
webhooks:write |
Required |
01 Diagnose the original failure
- List the owned endpoint's deliveries and find the event by time, resource and request reference.
- Compare the delivery evidence with your receiver logs. Distinguish connection or TLS failures, HTTP rejection, signature rejection and application-processing errors.
- Check that the configured destination is the intended HTTPS endpoint and that the receiver can persist an event before acknowledging it.
- Fix the specific problem. If credentials or signing secrets were rotated, make sure the receiver follows the current verification workflow.
- Read the current domain, order or operation resource when the event's state matters to a decision. An old event may describe a state that has since changed.
02 Replay and reconcile
POST the owned deliveryId to the replay endpoint with webhooks:write and an idempotency key. Retain the replay request reference, inspect the new delivery outcome and confirm your application processed the event exactly once.
Deduplicate by the stable event identifier supplied in the payload, while retaining separate delivery attempts for diagnosis. Your receiver should acknowledge an already processed event without registering a second renewal, sending duplicate fulfilment or charging again.
If processing failed after part of your local work completed, reconcile those local effects before replaying. For example, an event that already created a support task should update or recognise that task rather than create another.
Common questions
Should I replay every delivery after an outage?
Identify the affected window and processing gaps first. Some attempts may have reached your application even if acknowledgement failed. Use a bounded recovery list and event deduplication.
Does a successful HTTP response prove the business workflow finished?
Only if your receiver's contract makes that guarantee. Many receivers acknowledge after durable receipt and perform the actual work later. Monitor both stages.
Can I fix an incorrect domain action by replaying its event?
No. Read the current operation and use its supported corrective workflow. A webhook is a notification of recorded work, not an instruction to run that work again.