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
import Zernio from '@zernio/node';const zernio = new Zernio({ apiKey: process.env.ZERNIO_API_KEY });const { data } = await zernio.webhooks.redeliverWebhookEvent({ body: { webhookId: 'webhook_abc123', eventId: 'event_abc123', },});console.log(data);{ "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. Pass `event` to receive a sample payload of that event instead, so you can exercise the handler for an event that only fires on a real outage or lifecycle change (e.g. `account.ads.sync_failed`). The sample has the exact shape documented for the event under Webhook Events and is delivered like a real one (same `X-Zernio-Event`, `X-Zernio-Event-Id` and `X-Zernio-Signature` headers), with a top-level `test: true` and placeholder ids, never your data. The webhook does not have to be subscribed to the event, but a webhook that lists the event's resource group in its `disabledResourceGroups` answers 403, as does an API key with that group disabled. The delivery shows up in the webhook logs with `test: true`. `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.