Skip to content

Webhooks

Endpoints, every delivery attempt, and how to replay one.

The Webhooks view has three tabs: the events your account produced, the deliveries made from them, and the endpoints they were sent to. Events have their own page; this one is about the other two.

Webhook deliveries

last hour
MethodEndpointStatusDurationAttempt
POST/webhooks/wajub50010021 ms1 of 5
POST/webhooks/wajub500240 ms2 of 5
POST/webhooks/wajub200142 ms3 of 5

Deliveries

One row per attempt, not per event. A delivery retried three times is three rows sharing one delivery id.

ColumnNote
Statussuccess, retrying or failed
Response codeWhat your endpoint answered, empty on a network error
DurationHow long your endpoint took. A row at 10,000 ms is a timeout
Attempt1 to 5
EndpointWhich URL, when you have several

Filters: search over the event, status, endpoint, and a date range in whole days. Fifty per page.

The detail panel carries the payload that was sent and the body your endpoint returned, which is how you find out that your 500 came with a stack trace you can read from here.

Replaying

Two ways, both counted against your plan's monthly max_webhooks allowance.

ActionScope
RetryOne delivery
Bulk retryUp to 100 failed deliveries at once, within a window, optionally for one endpoint

Bulk retry only picks up deliveries whose status is failed, inside the window you choose, which defaults to the last 24 hours. Each delivery in the batch consumes one unit of the allowance, and the batch stops when the allowance runs out.

Endpoints

Creating one takes a URL and a list of event types.

FieldRule
URLA valid URL, up to 2,048 characters, and not a private or internal address
EventsAt least one, each from the list Konsole offers
DescriptionFree text, worth using when you have several

Konsole checks the event names, the API does not

The picker only offers valid types and refuses anything else. POST /webhooks accepts any non-empty array, so a typo made through the API is stored and silently never matches. See the event catalogue.

Private and internal addresses are refused on purpose: an endpoint pointing at localhost or at a private range would turn Wajub's delivery worker into a probe of the internal network. For local development, use wajub listen.

The secret

Each endpoint has its own signing secret, shown once at creation. Afterwards, Reveal secret shows it again, behind a re-confirmation of your password, and the action is recorded.

Rotating is done from the API with POST /webhooks/{id}/rotate-secret. Deploy the new secret before rotating, or the deliveries between the rotation and your deploy will fail signature verification.

Promoting a sandbox endpoint to live

A sandbox endpoint can be copied to live in one action. It carries over the URL and the event list, and it gets a new secret, because a sandbox secret has been on developer laptops.

The connectivity test is not a real event

Send test posts a fixed payload to the endpoint, signed with its real secret. It proves the URL is reachable and that your signature check passes. It does not prove your handler works, because the payload is shaped differently from a real delivery.

What Send test actually posts
{
"id": "evt_test_kZ3qP8mWvL2xR7tB5nY4hC6d",
"type": "webhook.test",
"created": "2026-01-15T10:30:00+00:00",
"data": {
"id": "test_123",
"message": "This is a test webhook from Wajub."
},
"livemode": false
}

Four differences from a real delivery, and each one has bitten someone.

Real deliverySend test
The type is in eventThe type is in type
Carries api_version, pending_webhooks, requestCarries none of them
Sends X-Wajub-Delivery-IdDoes not
Recorded with status successRecorded with status delivered

What did you think of this content?