Events
What the platform recorded, and which endpoints it reached.
Events are the first tab of the Webhooks view in Konsole. An event is the platform's own record that something happened: a payment succeeded, a transfer failed, a customer was deleted. Webhook deliveries are built from events, which makes this view the place to answer the question that comes before "why did my endpoint not fire?", namely "was the event created at all?".
Eventstrx_CSUGajfv9xh0XQ5wu2lx
payment.created12:31:48.001
25,000 XAF, channel cm.mtn
route.evaluatedmomo-cm-mtn-first12:31:48.044
Rule "MoMo CM, MTN first" matched
provider.attempt.failedMTN MoMo12:31:48.901
MTN MoMo returned a 503 error
route.fallbackwaterfall12:31:49.220
Automatic waterfall fallback to next provider
provider.attempt.succeededOrange Money12:31:50.130
Payment accepted
payment.succeeded12:31:50.140
trx_CSUGajfv9xh0XQ5wu2lx, 1 940 ms over 2 attempts
What a row shows
| Column | Note |
|---|---|
| Event id | evt_ in live, evt_test_ in sandbox |
| Type | payment.succeeded and the rest of the catalogue |
| Object | The resource it is about, with its id |
| Deliveries | Up to five recent attempts, each with endpoint, status code and duration |
| Pending | How many endpoints still owe an answer |
| API version | The version the payload was built for |
The delivery column is what makes this view better than the raw event list from the API: you see the event and its fate on the same row.
Filters
| Filter | What it matches |
|---|---|
| Search | The event id, the type, the object id or the request id |
| Type | One exact type, chosen from the types your account has actually produced |
| Category | Everything under a prefix, for example every payment. type |
| Date start, date end | Whole calendar days |
| Delivery status | delivered means nothing pending, pending means at least one endpoint has not answered |
Fifty per page, newest first. The type selector is built from your own history, so it only offers types you have really produced, which is a faster way to notice a missing one than reading the catalogue.
Internal events are filtered out
Wajub records some events for its own use. They are excluded from this view and never delivered to endpoints.
Two types that appear here and nowhere else
payment.checkout_page_opened and payment.redirected_to_callback are recorded as events and are
visible in this list, but they are never dispatched to an endpoint. They let you reconstruct a
checkout after the fact: when the payer opened the page, and whether they came back to your return
URL.
If a payment never succeeded and there is no payment.checkout_page_opened, the payer never
reached the page, which usually means the link or the redirect is broken rather than the payment.
Replaying
Each delivery on the event page has its own Resend button, and the Deliveries tab of Webhooks offers the same. What you replay is one delivery, so the event goes again to that endpoint only: on an account with two endpoints, the healthy one does not receive it a second time. The monthly allowance shown here and there is the same counter, Webhook replays per month on your plan.
The replay counts as a new attempt
It keeps the same X-Wajub-Delivery-Id and the same event id, so a handler that deduplicates on
either answers 200 without redoing the work if it already recorded the event. Replaying is for
deliveries your endpoint did not accept.
Export
The current filter set exports as CSV or JSON, and counts against your plan's Exports per month allowance.
A useful one: filter to delivery_status: pending over the last seven days and export. That list
is exactly the set of events your integration has not finished processing.