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

# iMessage Delivery: Sent vs Delivered vs Read

> What each Tuco message status actually proves, why sent is not delivered, and why read receipts are a floor rather than an exact count.

**`sent` means Tuco handed the message to the channel. `delivered` means the channel confirmed it reached the device. They are different guarantees, and a message can sit at `sent` forever without ever being `delivered`.** Read receipts are a further step again: they only exist when the recipient has read receipts switched on, so treat them as a floor on how many people read you, never as an exact count.

## The statuses you can build on

| Status                | What it proves                                                                                          | What it does not prove                                                  |
| --------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| `queued`              | The send is planned but not yet eligible — waiting on allowed hours, line capacity, or a campaign delay | Nothing has left Tuco                                                   |
| `pending` / `sending` | Actively in flight                                                                                      | —                                                                       |
| `sent`                | Tuco handed the message to the channel per that channel's contract                                      | That any device received it                                             |
| `delivered`           | The channel confirmed it reached the recipient's device or mailbox                                      | That a human saw it                                                     |
| `failed`              | Tuco determined the message cannot be sent. Not silently retried                                        | —                                                                       |
| `fallback`            | The primary channel is unavailable for this recipient — typically no iMessage-capable address           | That the contact is unreachable; your SMS fallback may still reach them |

Full detail: [Failures, fallbacks and delivery outcomes](/features/failures-and-fallbacks).

## Why sent is not delivered

`sent` is a statement about Tuco's side of the boundary: the message was accepted by the channel. Everything after that is outside Tuco's control — the device may be off, the number may no longer be in use, the recipient may have blocked the sender, or the message may have been downgraded at the carrier on the SMS leg.

If a message shows `sent` but the lead says nothing arrived, the problem is downstream. Work through [Message not received](/troubleshooting/message-not-received) and [Sent vs Delivered](/troubleshooting/message-statuses).

## Why read receipts undercount

A read receipt only exists if the recipient has read receipts enabled on their device. Many people do not. So:

<Warning>
  Read rate is a **floor**, not a measurement. A 40% read rate means at least 40% read it — not that 60% did not. Never report read receipts as an engagement ceiling, and never compare read rate across audiences with different device settings.
</Warning>

The metric that survives this problem is **reply rate against contacts you actually reached**: `replied / reached`, where `reached` counts distinct recipients a message actually got to. That is comparable across workspaces regardless of how iMessage delivery landed. See [the analytics API](/api-reference/endpoint/analytics-insights) for the `insights.unique` breakdown.

## Building automations on outcomes

<Steps>
  <Step title="Trigger on sent for internal bookkeeping">
    Activity feeds, CRM timeline entries, "message went out" notifications.
  </Step>

  <Step title="Trigger on delivered for time-based follow-up">
    Waiting "3 days after delivery" is only meaningful once delivery is confirmed.
  </Step>

  <Step title="Trigger on fallback to switch channel">
    Route to SMS or email, or tag the lead as not reachable on iMessage.
  </Step>

  <Step title="Alert on failed rates, not individual failures">
    A single failure is data hygiene. A rising failure rate on one line or campaign is an operational signal.
  </Step>
</Steps>

Webhooks fire on these transitions — see [message webhooks](/api-reference/message-webhooks).

## Related

* [Check iMessage availability](/features/check-availability) — avoid failures before they happen
* [Does iMessage need A2P 10DLC registration?](/guides/imessage-a2p-10dlc-carrier-filtering)
* [Send bulk iMessage](/guides/send-bulk-imessage) — pacing and caps