> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Inspect webhook deliveries and replay failures

> Use the webhook event explorer to watch every delivery across your endpoints, inspect a single delivery's payload and response, and replay failed deliveries when your endpoint recovers.

# Inspect deliveries and replay failures

Your webhook endpoint's behavior is not always deterministic — a deploy, a bad deploy rollback, a provider timeout. The webhook delivery tooling answers the two questions that matter when something goes wrong: *what did Orbit actually send?* and *how do I get the events my endpoint missed?*

Three surfaces cover the loop. Use them in order: the **Events explorer** watches live traffic, the **delivery inspector** dissects one delivery, and **manual replay** re-sends the failures after your endpoint recovers.

## Explore events across your endpoints

Open **Developer → Webhooks → Events** in the dashboard. This timeline lists every delivery attempt across all of your webhook endpoints, most recent first, regardless of which endpoint the delivery targeted.

Narrow the timeline with the filters along the top:

* **Status** — `success`, `failed`, or `pending` (queued or mid-retry).
* **Endpoint** — pivot to a single endpoint once you know which integration is misbehaving.
* **Search** — substring match on the event type, so `message` isolates the whole messaging family and `delivered` narrows to delivery confirmations.
* **Time range** — bound the window with `from_date` / `to_date` parameters on the underlying API.

The same data is available over the API when you want to script it:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/webhooks/events?status=failed&search=message.failed" \
  -H "X-API-Key: dv_live_sk_..."
```

The response is cursor-paginated; follow `pagination.cursor` in each page's response to walk backward through the window.

### Reliability roll-up

Next to the timeline, the reliability sidebar summarizes every endpoint across the last 24 hours: success rate, p95 latency, the age of the oldest still-pending delivery, and the most recent event. A stuck or degrading endpoint surfaces here before customers notice. Fetch the same roll-up programmatically:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/webhooks/reliability?window_hours=24" \
  -H "X-API-Key: dv_live_sk_..."
```

`window_hours` accepts 1–168 (one hour to one week).

## Inspect a single delivery

Click **Details** on any row to open the delivery inspector for that attempt. The slide-over shows exactly what left Orbit and what your server returned, for that one attempt:

* **Request payload** — the JSON envelope your endpoint received, pretty-printed.
* **Request headers** — including the signature headers, so you can verify a signature reproduction case by hand.
* **Response status, headers, and body** — what your server answered (or the timeout note when it did not).
* **Delivery ID and Event ID** — the correlation identifiers to quote when asking support about a specific failure.
* **Retry history** — every attempt in this event's retry chain, oldest first, each with its own HTTP code and timestamp. Spot the difference between "flapping" and "consistently failing with the same 403."

Every identifier carries a copy button, and a one-click **Copy diagnostics** bundles the whole delivery (ids, timestamps, status, error text) into the clipboard — formatted so you can paste it directly into a support ticket.

## Replay a failed delivery

Once the underlying problem is fixed — the endpoint is back up, the signature secret is re-synced, the firewall allowlist covers our egress IPs — re-drive the failed events with **Replay**.

Replay is scoped tightly so it cannot surprise you:

* **Failed rows only.** A successful delivery has no Replay action — re-sending an event your receiver already processed would double-fire billable downstream effects.
* **This endpoint only.** Replay re-sends to the endpoint the original failed on. It does not fan out to other endpoints subscribed to the same event.
* **Within 7 days.** Deliveries older than the 7-day retention window are not eligible. Past that point, use the time-range replay below to backfill explicitly.

Replay queues immediately. The original attempt's history is preserved as the audit record; the new attempt appears as a fresh delivery row, and its outcome lands back in the Events timeline within seconds. Each replay is recorded in your audit log alongside the operator who triggered it.

The equivalent single-delivery API call:

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/webhooks/wh_abc123/deliveries/dlv_def456/replay" \
  -H "X-API-Key: dv_live_sk_..."
```

The response returns `202 Accepted` with a `replay_event_id` you can poll against the deliveries listing to see the new attempt's outcome.

If the delivery is not eligible, the response tells you why: a non-failed delivery returns `409`, and one past the retention window returns `422` with the timestamp the eligibility lapsed at.

### Replay many at once

Two bulk paths cover larger outages:

* **Dead-letter queue** — **Developer → Webhooks → Dead-letter queue** lists deliveries whose retries are fully exhausted. Filter by event type or failure reason, select the rows for the incident, and use **Replay** (or `POST /webhooks/dlq/bulk-replay` for up to 200 rows in one API request) to put them back into the retry pipeline.
* **Time-range replay** — for a whole outage window on one endpoint, use `POST /webhooks/:id/replay-range` with explicit `from` / `to` bounds. Send `dry_run: true` first to preview the count before confirming; the dashboard's bulk-replay flow runs the same preview under the hood.

Both bulk paths report per-row outcomes, so a row that recovered on its own (or a concurrent operator already handled) shows as skipped rather than silently re-firing.

## What to check when deliveries keep failing

* **Signature failures** — compare the signing secret on the endpoint's page against what your verifier uses; the [signature troubleshooting guide](/webhooks/troubleshooting-signature-failures) walks the common mismatch cases.
* **Timeouts** — respond within 30 seconds; if you need longer to process, ack the delivery and process asynchronously.
* **Proven-dead statuses** — `401`, `403`, `404`, and `410` disable the endpoint immediately. Re-enable it from the dashboard once the auth or path issue is fixed.
* **Egress allowlists** — if your firewall filters inbound, allowlist Orbit's published egress IPs (listed on the endpoint page and via `GET /webhooks/egress-ips`).