Webhook Deliveries

Webhook Deliveries is an operator-scoped audit surface for actual outbox events and retained per-endpoint delivery records. It starts on All time, using event occurrence time, so historical events without delivery records remain reviewable.

Dashboard path

Operator Dashboard → Integrations → Webhook Deliveries

Required scope: webhooks:read

Replay scope: webhooks:write

Viewing Polyflight deliveries additionally requires polyflight:read.

What operators can do

• select opinion, polyflight, or explicitly labelled all; the dashboard starts on mixed products when authorized, while the API default remains Opinion
• filter by disposition, exact event type, UTC date range and date basis, record kind, endpoint ID, and HTTP response class
• use the dedicated Market ID and User ID searches, combined with exact event, delivery, order, trade, purchase-request, and ticket identifiers using AND
• use Today, Last 7 days, This month, or All time; blank date limits mean no bound
• inspect current endpoint URL/status where retained, real event identity, monetary summaries, reconstructed callback data, attempts, retry time, delivered time, and response samples
• distinguish confirmed no_endpoint, endpoint_disabled, and not_subscribed skips from history_unavailable; missing historical records do not prove no callback was sent
• review event-only rows without fabricated delivery IDs, HTTP responses, or lifetime attempt counts; manually backfill dead-letter events, terminal skips and historical gaps to currently active, subscribed endpoints
• use filtered record totals and 25/50/100-row pagination; one event with multiple retained deliveries has multiple records
• export all applied matching records across pages as CSV, up to 5,000 rows; larger exports are rejected, never silently truncated
• share or navigate back/forward through the applied filter URL; unapplied draft changes do not alter the table, totals, or export
• resend an eligible retained delivery to its original active endpoint, or a historical event to current subscribers, after reviewing duplicate-event risk
• tick the leftmost checkboxes individually or select all eligible records on the current page; Bulk Resend appears when at least two records are selected (maximum 100)

UTC event time and delivery-created time are separate. Delivery-created filtering excludes event-only records. A historical-gap disposition's recording time is the backfill/observation time, not the original event time. CSV contains reconstructed customer and financial data, not raw signed requests or receiver response samples; handle it as sensitive.

Market and user identity

The table shows Market ID and User ID directly, without opening a row:

• Market ID is the Opinion market's numeric ID, including redemption events, not a Polyflight flight ID. Polyflight rows display Not applicable; Opinion rows whose market cannot be established display Not recorded.
• User ID is your operator system's external user ID (external_user_id), never the internal Polynion user or operator-user record ID. It preserves strings such as 0 and leading-zero IDs. Unknown values display Not recorded.

Both searches are exact, not partial. User ID matching is case-sensitive and preserves the entered string, including surrounding whitespace. Market ID and User ID searches cover Opinion orders and redemptions; User ID also covers supported Polyflight ticket, purchase-request, and payment-obligation records. A Market ID filter excludes Polyflight rows, even when viewing all products.

Identities come from operator-scoped durable records; missing or unavailable identity is unknown, not guessed from another ID or reconstructed callback data. The API returns null for unknown values (and for Polyflight Market ID). CSV exports the same identities as market_id and external_user_id, with nulls represented by empty cells, using the same applied filters as the table.

Identifier checklist

• Event ID search means the public string event.event_id; use it for receiver deduplication and support correlation.
• Delivery ID is the positive numeric retained HTTP delivery record ID; an event-only row has none.
• A queued historical target uses numeric outbox event.id, not the public Event ID. The dashboard selects this automatically; when using the API, copy the right field.
• Order ID and Trade ID are different Opinion identifiers; Purchase request ID and Ticket ID are different Polyflight UUIDs. Combine only identifiers that belong to the same record.

replayable=false describes retained replay eligibility, not every Resend action. Eligible terminal event-only rows can still be backfilled; pending/failed event-only processing cannot.

Replay behavior

Resend queues the original callback identity for asynchronous delivery through the normal signed webhook HTTP path, with the same payload construction as initial delivery. These are real callbacks that your system can receive and record, not simulations. It does not create a new business event, change the original event time, or mutate a wallet. For historical event-only records, including Dead letter, it creates real deliveries for all currently active endpoints subscribed to that event type. Configure an eligible endpoint before confirming.

If a previously accepted delivery with any 2xx is resent, dedupe by its original event_id before applying any downstream effect. A pending Polyflight payout/refund is an obligation, not a confirmed wallet credit. Its fee is included in the stake debit; a full refund/compensation is not another fee.

Polyflight replay can redeliver an event envelope, but it never authorizes or repeats its wallet mutation. A receiver still deduplicates by event_id.

Selections are limited to the current page and clear when navigating between pages or applying filters. The confirmation lists the selected records and warns about known delivery or unavailable history. A batch is checked atomically: if any selected record is missing, belongs to another operator, is dispatching, or has no eligible endpoint, none are queued. Inspect the error, refresh, and adjust the selection.

Retained deliveries target the same endpoint record using its current URL, signing secret and policy, not an archived destination. Check Callback Settings → Setup History before resending after a change. Already-pending deliveries cannot be queued again. Resend keeps lifetime attempts and previous HTTP evidence; it grants an explicitly requested attempt, not a fresh automatic retry budget.

Response samples show only the latest bounded diagnostic text, not a complete attempt-by-attempt response archive or guaranteed credential redaction. Keep your receiver responses free of secrets. Reconstructed envelopes and monetary summaries are not the original signed request bytes.

Creating or enabling an endpoint does not automatically send skipped events or historical gaps; explicit Resend is required. A successful queue response is not confirmation of receipt. Refresh later to inspect retained attempts and receiver responses. Dispatch/retry sends pending or due failed deliveries, not already successful sibling deliveries; delivery order is not guaranteed.

Source API

The page reads GET /api/operator/webhooks/deliveries, exports through GET /api/operator/webhooks/deliveries/export, and queues single or bulk resends through:

POST /api/operator/webhooks/deliveries/resend

The request identifies retained records by delivery_id or historical records by the numeric outbox event.id. The API scopes both the endpoint owner and outbox event owner to the authenticated operator before showing or resending a callback.