Redeliver a webhook event
Replay a past delivery: the original payload is re-sent, byte for byte, to the
subscription's current URL. The original event ID is preserved so your endpoint can
dedupe, and the replay is recorded as a fresh attempt, so it shows up in
GET /v1/webhooks/logs next to the delivery it replays.
Both webhookId and eventId come from a row of GET /v1/webhooks/logs. Because
the stored payload is replayed as-is, a redelivery reflects the event as it was
emitted, not the current state of the resource.
Only deliveries inside the 30-day log retention window can be replayed; past that
the payload is gone and the request fails with a 422. Replays run the same
resource-group checks as live delivery, against both the key's groups and the
subscription's disabledResourceGroups.
Authorization
bearerAuth API key authentication: send your Zernio API key in the Authorization header, prefixed with Bearer.
In: header
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
{ "success": true, "message": "Webhook re-delivered"}Delete webhook
Permanently delete a webhook configuration.
Send test webhook
Send a test webhook to verify your endpoint is configured correctly. The test payload includes event: "webhook.test" to distinguish it from real events. `webhook.test` belongs to the `webhooks` resource group, so a key with that group disabled is rejected with 403, as is a test fire on a subscription that lists `webhooks` in its own `disabledResourceGroups` (a 403, not a reported delivery failure). Replays of real events (redelivery, dead-letter requeue) run the same checks as live delivery, against both the key's groups and the subscription's.