Delivery log

The Delivery Log page gives you one search across every message deliverable — SMS, WhatsApp, email, and voice — instead of opening each channel workspace and searching there. Open it from Messages → Tools → Delivery log. Use it when you need to answer questions the per-channel workspaces cannot:

“Did this recipient get the WhatsApp after the SMS failed?” — a mixed-channel history in one result list.
“Find this provider-side message ID from a carrier or Meta dashboard paste.” — a match against the provider reference, not a free-text scan.
“What is the current status of this message ID?” — a direct lookup by the msg_… identifier returned by the send API.

This guide walks the whole loop: shape the search, narrow it with filters, read each status in the result, and hand the exact view to a teammate as a link.

Searching

The search box accepts three identifier shapes, and the page detects which one you pasted:

Message ID — the msg_… identifier the send API returns (for example msg_a1b2c3d4e5f6a7b8). A paste that matches the msg_ prefix plus 8–32 hexadecimal characters is flagged as a correlated lookup: the scope is a single identifier rather than a free-text scan. A correlation strip above the results reads “Correlated by message ID / provider reference:” followed by one channel chip per matching row, so you can see at a glance which channels the identifier spans.
Provider reference — the external message ID a carrier or Meta dashboard shows for the delivery (for WhatsApp, the wamid.… value Meta returns). Paste it verbatim and the page matches it against the provider-reference field instead of scanning free text.
Free text — anything that does not match an identifier shape is matched against the recipient, the sender, and the searchable body content. Phone numbers work best pasted in E.164 form (+14155552671).

The correlation strip matters when an identifier returns more than one row: a broadcast that retried, or a recipient reachable on two channels, shows one row per channel with its own chip.

Filters

Three dropdowns narrow the result set:

Channel — SMS, WhatsApp, voice, email.
Status — every lifecycle state, listed under “Working a result” below.
Direction — outbound or inbound.

Leaving a filter on all means no filter is sent — the page drops the parameter from the request entirely rather than sending a literal all value. The same applies to the URL: the page reads its initial filters from the query string, but a default such as status=all is ignored, not applied. When you build a share link by hand, only non-default values travel.

Working a result

Each row carries its channel chip, recipient or sender, current status, and timestamp. Selecting a row opens the standard message detail page — the same drill-down every channel workspace uses — where the status timeline shows each lifecycle step with its timestamp and, on a terminal failure, the carrier or provider rejection reason. The status vocabulary means one thing per state; read a row like this:

Status	What it means	What to do next
`queued`	Accepted and waiting for dispatch.	Nothing — the queue drains in order. If a row sits here long, check the send window or rate limits on your account.
`scheduled`	Waiting for a future send time you set.	Cancel it from the message detail page if the timing is wrong; it stays put until the scheduled time or a cancel.
`sending`	Being dispatched to the provider right now.	Usually a moment in time — refresh. A row stuck here moved on before the provider accepted it, so recheck before resending.
`sent`	Handed to the carrier or provider; no delivery receipt yet.	Wait for the receipt window. If it stays here past the window, the no-receipt tracker promotes it (below).
`delivered`	The carrier or provider confirmed receipt on the handset or mailbox.	Done — terminal success for SMS, email, and voice.
`read`	The recipient opened it (channels with read receipts — WhatsApp).	Done — terminal success beyond delivery.
`rejected`	The provider refused the message at submission (WhatsApp template rejection, sender-ID block).	Open the row and read the provider reason on the terminal step; fix the template or the variable shape before resending.
`failed`	The send failed — a carrier rejection, an unreachable route, or an error in the pipeline.	Open the row for the rejection reason. From the detail page the Retry action re-queues the same message; use the normal send path when the message body needs to change.
`undelivered`	The carrier gave a definitive non-delivery verdict — the handset cannot be reached, the number is out of service.	Unlike `failed`, no retry will land. Verify the number, then fix the audience list; repeated undelivered rows to one recipient are a list-hygiene signal.
`expired`	The validity window closed before the carrier delivered.	Set a longer validity period on the send, or resend if the content is still relevant.
`submitted_no_receipt`	Handed to the carrier, but no delivery receipt arrived within the grace window — a sent without a verdict state, not a failure.	Treat it as “sent, receipt missing.” A late delivery receipt still moves the row to `delivered`. If rows accumulate here, the provider is not returning receipts — chase it with the provider-side workflow in Developer → Delivery Logs.

Two statuses look similar but call for different moves: failed means “something went wrong — find the reason and retry,” while undelivered means “the destination cannot take it — stop retrying and fix the list.” submitted_no_receipt sits between: the send happened, only the verdict is missing. The page reads its initial filters from the URL, so any view you can build on screen is a link you can paste into a runbook, a ticket, or chat:

# Look up a specific message ID
/${locale}/messages/delivery-log?q=msg_a1b2c3d4e5f6a7b8

# All failed outbound WhatsApp deliveries
/${locale}/messages/delivery-log?channel=whatsapp&status=failed&direction=outbound

# Free-text recipient lookup across every channel
/${locale}/messages/delivery-log?q=%2B14155552671

Supported parameters: q (search text), channel, status, direction. A teammate opening the link lands on the same filtered result list you saw — no need to dictate filter settings over chat. The parameters map one-to-one onto the list-messages API filter vocabulary, so a URL built against the API works in the page too.

When the log cannot answer

The Delivery Log is a lookup surface: it answers “which messages, in what state.” Some questions need a different tool:

A lifecycle stalled at the provider. submitted_no_receipt rows and carrier rejections that need the provider’s own dashboard — open the step-by-step lifecycle in Developer → Delivery Logs, which reads the terminal rejection reason and the receipt trail per step.
Channel-specific work. Compose, template management, and channel settings stay in the per-channel workspaces under Messages. The Delivery Log row opens the same shared message detail page those workspaces use, so anything reachable there is reachable from a result row.
Voice interactions. Calls live on the interaction timeline, not the message log — use Interaction Search to scan conversations and calls in one list.

API access

The log is not a dashboard-only view: every lookup the page performs runs against GET /api/v1/messages, so a ledger reconciliation, a support script, or an on-call runbook can run the same lookup programmatically. Each request carries an X-API-Key header (live keys are prefixed dv_live_sk_).

export ORBIT_API_KEY="dv_live_sk_…"

Correlated-id lookup

Pass the msg_… id from the send API as q — the single-identifier scope the dashboard flags as a correlated lookup:

curl "https://api.orbit.devotel.io/api/v1/messages?q=msg_a1b2c3d4e5f6a7b8" \
  -H "X-API-Key: $ORBIT_API_KEY"

Response — 200 OK

{
  "data": [
    {
      "id": "msg_a1b2c3d4e5f6a7b8",
      "channel": "whatsapp",
      "direction": "outbound",
      "status": "delivered",
      "to": "+14155552671",
      "created_at": "2026-08-23T09:41:12.000Z"
    }
  ],
  "meta": {
    "request_id": "req_…",
    "timestamp": "2026-08-23T09:41:13.000Z",
    "pagination": { "cursor": null, "has_more": false, "total": 1 }
  }
}

Filtered scan

Pass the same channel / status / direction values the shareable link accepts:

curl "https://api.orbit.devotel.io/api/v1/messages?channel=whatsapp&status=failed&direction=outbound" \
  -H "X-API-Key: $ORBIT_API_KEY"

Response — 200 OK

{
  "data": [
    {
      "id": "msg_f1e2d3c4b5a69788",
      "channel": "whatsapp",
      "direction": "outbound",
      "status": "failed",
      "to": "+14155552671",
      "created_at": "2026-08-23T08:12:03.000Z"
    }
  ],
  "meta": {
    "request_id": "req_…",
    "timestamp": "2026-08-23T09:41:13.000Z",
    "pagination": { "cursor": null, "has_more": false, "total": 1 }
  }
}

Use the API when the dashboard page is one step in a script; use the page when a person needs to see and share the result. Both read the same rows. For a step-by-step console walkthrough of one failing message, Developer → Delivery Logs covers the same endpoint from the console side.

WhatsApp

Developer console

Guides

Messaging Controls

Audience & Support Tools

Delivery log

Delivery log

Searching

Filters

Working a result

When the log cannot answer

API access

Correlated-id lookup

Filtered scan

​Delivery log

​Searching

​Filters

​Working a result

​Sharing a view

​When the log cannot answer

​API access

​Correlated-id lookup

​Filtered scan

Delivery log

Searching

Filters

Working a result

Sharing a view

When the log cannot answer

API access

Correlated-id lookup

Filtered scan