> ## Documentation Index > Fetch the complete documentation index at: https://docs.ycloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Message delivery statuses > Distinguish acceptance, sending, delivery, reading, and failure when tracking an outbound WhatsApp message. Sending a request and delivering a message are different events. A successful API response confirms the request's result at that stage; it does not guarantee that the customer has received or read the message. Use the YCloud message status and any available error details to understand what happened. ## Outbound message statuses The YCloud outbound WhatsApp message resource uses these statuses: | Status | Meaning | What to do | | - | - | - | | `accepted` | YCloud accepted the messaging request. | Track later updates. Do not treat this as delivery. | | `sent` | The message is in transit within WhatsApp's systems. | Wait for a delivery or failure update. | | `delivered` | The message reached the customer's device. | Treat it as delivered, not necessarily read. | | `read` | WhatsApp reported that the customer read the message. | Use the signal in your workflow without assuming that reading means agreement or completion. | | `failed` | The message failed to send. | Inspect the error and address the cause before retrying. | A typical successful progression is `accepted → sent → delivered → read`. Do not assume that your application will receive every intermediate update or that updates will arrive in that exact order. ## Why a successful request is not final delivery With the queued endpoint, YCloud accepts the request and submits it asynchronously. With the direct endpoint, submission to the WhatsApp Business API happens synchronously. Final delivery is still asynchronous in both cases. For implementation details, see [Send a WhatsApp message](/en/api-reference/guides/whatsapp-platform/send-whatsapp-message). If the current status is still `accepted` or `sent`, do not repeatedly submit the same content. An additional request can result in a duplicate message. ## Delivery and read receipts Delivered means that the message reached the customer's device. It does not mean that the customer opened the conversation. Read receipts are not available in every situation. For example, the customer's read-receipt settings can affect whether a read update is reported. The absence of a read update is not proof that the customer ignored the message. For the upstream status definitions, see Meta's [message status webhook reference](https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks/components/). ## Track the same message across systems When troubleshooting, keep the following information together: | Information | Why it helps | | - | - | | YCloud message ID | Identifies the message resource in YCloud. | | WhatsApp message ID, when available | Correlates the message with upstream WhatsApp processing. | | Sender, recipient, and WABA | Identifies the affected business and interaction. | | Your external reference, if used | Connects the message to an order, support case, or another internal event. | | Status timestamps | Helps reconstruct the sequence when updates arrive late or out of order. | | Error details | Explains a failure and guides the next action. | Do not include API keys or unnecessary customer information when sharing troubleshooting records. API integrations can receive `whatsapp.message.updated` webhooks and retrieve the message resource. See [WhatsApp messaging best practices](/en/api-reference/guides/whatsapp-platform/whatsapp-messages-api-best-practices) for synchronization and retry handling. ## Investigate a failed message Start with the returned error, not the status name alone. * **Template issue:** confirm that the template is available and that its language and parameters are correct. * **Window issue:** check whether the message requires an open [customer service window](/en/documentation/whatsapp-business-platform/messaging/service-messages#customer-service-window). * **Account or number issue:** inspect the affected asset and its current restrictions. * **Content or media issue:** check the requirements of the selected message type. * **Delivery control:** follow the specific error guidance. Immediate repeated retries may not resolve a platform restriction. A failed message does not establish that a customer blocked your number. Use the actual error details and avoid inferring customer behavior that the platform has not reported. For platform delivery controls, see [Quality and delivery controls](/en/documentation/whatsapp-business-platform/pricing-limits-and-quality/quality-and-delivery-controls). For an enforcement notice, see [Account restrictions and appeals](/en/documentation/whatsapp-business-platform/consent-policies-and-account-health/account-restrictions-and-appeals). ## Decide whether retrying is safe | Current evidence | Recommended handling | | - | - | | Request returned an ID and status is not final | Keep tracking that message. Do not submit another copy just because a customer has not replied. | | Request timed out and you do not know whether it was accepted | Reconcile using your stored request context and available message records before retrying. A timeout is not proof that nothing was sent. | | Permanent content, template, or permission failure | Correct the underlying input or stop the send. Repeating the same request will not fix it. | | Temporary technical failure | Retry only under the specific error guidance, with a delay, an attempt limit, and a check that the message is still useful. | | Customer opted out or a recipient-level control blocks delivery | Suppress the affected communication; do not rotate senders to force delivery. | | Business event became obsolete | Cancel the retry even if the technical error could be retried. | A good message record ties one intended business action to its requests and results. Your external reference helps correlation, but do not assume it provides API idempotency unless the endpoint explicitly guarantees that behavior. ### Example of delayed status updates Your system receives `delivered`, then a delayed `sent` event for the same message. Do not change the customer's status back to “not delivered.” Store event timestamps and apply a state model that tolerates duplicate and out-of-order updates. Likewise, a missing `read` event is not a failed message. Separate these measures: * **Delivered reach:** messages with delivery evidence. * **Read reach:** messages with a reported read receipt. * **Customer response:** an actual inbound reply or interaction. * **Business conversion:** a confirmed booking, purchase, or successful verification in the system that owns it. ## Next steps * [Review messaging rules](/en/documentation/whatsapp-business-platform/messaging/how-messaging-works). * [Check service messages](/en/documentation/whatsapp-business-platform/messaging/service-messages). * [Implement delivery tracking](/en/api-reference/guides/whatsapp-platform/send-whatsapp-message). * [Contact YCloud support](/en/documentation/support/ycloud-support-team) with the relevant message identifiers and error details. ## Frequently asked questions You cannot conclude that. Read receipts may be unavailable, including when the recipient disables them. Keep delivered and read as separate measurements. Neither a missing read receipt nor a general undeliverable error identifies the customer's reason or proves blocking. Not immediately. The platform may already have accepted the request. Check the message identifier, available logs, and later webhook events before issuing another send. Correlate attempts to the same business action and design duplicate protection; an external reference is not automatically an endpoint idempotency guarantee. A display limitation and a delivery failure are different. Inspect the actual direction, status, message type, and any error. For incoming content, follow the [Inbox unsupported-message guide](/en/documentation/inbox/unsupported-messages-in-inbox); do not guess the content or count a placeholder as a failed outbound send. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.