Delivery reports and statuses

The status lifecycle

The practical consequence: a status can legitimately take longer for some messages in the same batch than others, because each one waits on its own carrier confirmation.

1. AcceptedYour authenticated request passes validation. The API responds with a message id and the message's initial status — the homepage's safe example shows a 202 Accepted response with status queued.
2. DispatchedThe message is handed to the carrier route for the recipient's number.
3. Delivery statusThe carrier's confirmation comes back and the message's status updates. Delivery confirmation depends on the carrier callback — statuses arrive per message and per carrier, not on a fixed clock.

Where to read delivery reporting

Delivery reporting is available in customer detail and the user-sent SMS audit. The audit capture below has recorded provenance:

• Customer detail — delivery intelligence: per-message delivery objectives, failure classification and DLR (delivery receipt) latency, so causes are distinguishable rather than a single undifferentiated failure count.
• User-sent SMS audit: every send on the account is accounted for, message by message.

Enlarge screenshot

The same per-message statuses your portal shows are what the API returns — the two views read from the same underlying message records, so there is no separate 'dashboard truth' and 'API truth'.

Using failure classification

Use the classes to decide where to act first: audience hygiene, registration accuracy, or simply patience with a slow carrier callback. Treating all failures as one undifferentiated number leads to fixing the wrong thing.

• Numbers and recipients — invalid or unreachable numbers fail regardless of content; clean these from future audiences.
• Registration and content — template or header mismatches fail at the content check; fix the template or the send's registered values (see Sender ID and template setup).
• Carrier and network — transient carrier-side conditions may succeed on retry or simply arrive late; DLR latency tells you how much of your 'pending' traffic is delay rather than failure.

What a delivery report cannot tell you

Honest limits, stated plainly: a delivery report reflects carrier confirmations, and carriers differ in how promptly and how definitively they confirm. DLR latency varies by carrier and route. No delivery report on any platform is a guarantee of future delivery, and a delivered status means the carrier confirmed handoff to the recipient's network — it is not proof a human read the message.

That is also why this site publishes no delivery-rate percentage anywhere: a single number would say less than the per-message reporting you can already read.

Frequently asked questions

Next step

Create your account and start the workflow this guide covers — where a step is managed by our team rather than self-serve, we say so during signup. Prefer to talk first? Contact us and we will walk through it with you.