Events panel

The Events panel is the developer tool you'll spend the most time in once webhooks are wired up. It shows every event your account has produced, every delivery attempt to every endpoint, and the request and response of each attempt. Manual Resend lives here too.

Open the panel

Click the webhook icon in the dashboard's bottom-right dock. The Workbench opens on the Events tab. For the drawer mechanics (drag, full-screen, close) and a tour of the other tabs, see Workbench introduction.

The list lands pre-filtered to events from the last 24 hours. Change or clear the filter (next section) to look further back.

Filter the list

The header above the list has four filters and a clear button.

Wildcards in the Event Type filter look like customer.*, charge.*, refund.*. Picking customer.* shows every Customer event regardless of subtype. The popover surfaces wildcards at the top of the list and the exact event types grouped by resource below.

Filters compose. type=charge.* + date=last 24 hours + resourceId=pi_test_xyz + Include related scopes the list to "every charge event in the last day on this Payment Intent or its descendants."

A Clear button appears once any filter is set. The total count on the right (e.g. 42 events) reflects the current filter.

The events list

Events are listed newest first, grouped under date headers. Each row carries:

• The event type (e.g. checkout.session.completed).
• A one-line description derived from the event payload.
• A small badge with a count and a webhook icon when the event has pending deliveries (in flight or retrying). Useful for spotting deliveries that haven't landed yet.
• A timestamp on the right. Hover for the absolute time.

Click a row to drill into the event details. Use Load more at the bottom of the list to page through history.

A red row title means the event was a failure (*.failed / *.error).

Event details

The detail panel shows the same data you'd see on the wire, plus the delivery state for every endpoint subscribed to the event.

The header has the event type as a title and the evt_* ID as a mono-spaced subline.

Below that, a metadata strip with:

Then a Deliveries to webhook endpoints section with three filter tabs (All, Succeeded, Failed) and an accordion of every endpoint that received the event. Failed and retrying deliveries are auto-expanded.

At the bottom, a syntax-highlighted Event data viewer showing the full data.object exactly as it was delivered.

Deliveries and attempts

The Deliveries section groups rows by endpoint URL. A single row covers all deliveries to one URL, including the original delivery and any later Resend clicks against that endpoint. The row collapses the noise so you see one entry per endpoint per event.

Each delivery row carries:

• A status badge (success, retrying, or failed) plus the latest HTTP status code.
• The endpoint URL.
• The number of attempts.
• Either the next-retry time (if retrying) or the timestamp of the latest attempt.
• A Resend button.

Expand the row (or it auto-expands when failed/retrying) to see the individual attempts.

Click an attempt to open the Delivery attempt panel: request headers, request body, response status, response headers, response body, response time. Useful for diffing what your handler actually received against what you expected.

Per-attempt request and response bodies are kept for 90 days. Older attempts still show their summary row (HTTP status, attempt number, timestamp) inside the delivery accordion, but clicking through no longer shows the full request and response payloads. The events themselves and the delivery records around them are not deleted; only the per-attempt detail bodies are pruned.

Replay an event

Click the Resend button on any delivery row. XPay creates a new delivery to the same endpoint URL with the same payload, fresh t timestamp, and a fresh signature. Your handler receives a new POST.

Manual replays are single-shot: if your handler returns non-2xx to a replay, XPay does not retry it. Click Resend again when you're ready for another shot. Replays don't change the original delivery's status; they appear as a new attempt grouped under the same endpoint URL.

For the lifecycle (automatic retries vs manual replays, idempotency on event.id), see Replaying and retries.

A typical debug loop

1. Trigger the action that produces the event (test payment, refund, etc.).
2. Open the Workbench, find the event in the Events list.
3. Open its detail panel and look at the failed delivery: the response body and headers tell you what your handler returned.
4. Fix the handler, redeploy.
5. Click Resend on the failed delivery.
6. Watch the new attempt land successfully.

You don't need to take a fresh test payment to verify the fix. Replays use the original event's stored payload, so any event still in the list can be re-fed into a fixed handler.

Where to next