Skip to content

Webhook Deliveries

The Webhook Deliveries page in the self-service portal shows a short-lived, inspectable record of every webhook delivery for your ATS — both the outgoing webhooks CarvOS sends to your endpoint and the incoming webhooks your ATS sends to CarvOS. Use it to diagnose delivery problems without reproducing them.

You only ever see your own ATS's records; one ATS can never see another's.

Webhook Deliveries page in the self-service portal: a left sidebar with Webhook Deliveries selected, a banner explaining what the page lists, Window, Direction and Outcome filters with Filter and Refresh buttons, a counts row giving the stored records in the selected window split by outcome with its UTC bounds, and a full-width table of outbound and inbound records with UTC times, event, destination, status, success, failure and error outcomes, duration and causation

The Webhook Deliveries page, scoped to your ATS.

Opening the page

Sign in to the Self-Service Portal and choose Webhook Deliveries from the sidebar. Records are listed newest first.

Filtering

Three filters narrow the list:

  • Window — the last hour, 6 hours, 24 hours, or the full retention window (the default; the option states how many days that is). Every view covers a time window; there is no unbounded one.
  • Direction — outbound (CarvOS → your endpoint) or inbound (your ATS → CarvOS).
  • Outcome — success, failure, or error.

Leave Direction or Outcome on All to remove it. Filters carry across pagination, so paging never widens the window you selected.

Counts

Above the table is the number of stored records in the selected window — the total, and the split across success, failure and error. The counts cover the whole window, not the page you are looking at, so a page of rows out of a much larger window says so. They ignore the Outcome filter, so narrowing the list to failures still shows how many succeeded.

Timestamps

Every timestamp on the page is UTC and is labelled as such, in both the table and the detail dialog — so a delivery time can be quoted in a support request without converting it first.

What the page does and does not show

The page is an audit log of individual deliveries, not a traffic chart. It holds one row per verified incoming webhook and per outgoing send. It does not show your REST API calls, or incoming webhooks that failed signature verification — those are rejected before a record is written. Records are deleted after 7 days, and the page never reaches further back than that.

Reloading it and seeing few rows means few records in the selected window; it is not a measurement of your traffic.

Inspecting a delivery

Select View on any row to open the detail dialog. It shows the request payload, the response body and status (for outgoing HTTP deliveries), the allowlisted request/response headers, timing, and the correlation id you can copy into a support request.

Delivery record detail dialog over the dimmed Webhook Deliveries page, for an outgoing delivery your endpoint rejected with status 503: direction, mode, outcome, status code, duration, destination, UTC-labelled created and expiry timestamps, the correlation id, the HMAC signature, and the start of the captured request payload

The per-record detail dialog.

Best-effort audit

Delivery records are a best-effort audit log. Records may be missing during bursts or platform incidents; the webhook delivery itself is unaffected. Do not treat the delivery log as a billing-grade or compliance-grade ledger — the count above the table is a floor, not a total.