Events
What the platform recorded, and which endpoints it reached.
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 other 56 |
| 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
transaction.* rows are checkout timeline telemetry used inside the platform. 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
Replay lives one view across, in Webhooks, because what
you replay is a delivery to a specific endpoint. The monthly allowance shown here and there is the
same counter, max_webhooks on your plan.
A replay goes to every subscribed endpoint
It is not targeted at the one that failed. On an account with two endpoints, the healthy one receives the event a second time, which is one more reason for your handler to key on the event id.
Export
The current filter set exports as CSV or JSON, and counts against your plan's monthly
max_exports 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.