> ## 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. # Estados de entrega de mensajes > Distinga la aceptación, el envío, la entrega, la lectura y los fallos al realizar el seguimiento de un mensaje saliente de WhatsApp. Enviar una solicitud y entregar un mensaje son eventos distintos. Una respuesta satisfactoria de la API confirma el resultado de la solicitud en esa fase; no garantiza que el cliente haya recibido o leído el mensaje. Utilice el estado del mensaje de YCloud y los detalles de error disponibles para comprender lo sucedido. ## Estados de mensajes salientes El recurso de mensajes salientes de WhatsApp de YCloud utiliza estos estados: | Estado | Significado | Qué hacer | | - | - | - | | `accepted` | YCloud aceptó la solicitud de mensajería. | Realice el seguimiento de las actualizaciones posteriores. No interprete esto como una entrega. | | `sent` | El mensaje está en tránsito dentro de los sistemas de WhatsApp. | Espere una actualización de entrega o de fallo. | | `delivered` | El mensaje llegó al dispositivo del cliente. | Trátelo como entregado, no necesariamente leído. | | `read` | WhatsApp informó que el cliente leyó el mensaje. | Utilice esta señal en su flujo de trabajo sin asumir que la lectura implica acuerdo o finalización. | | `failed` | No se pudo enviar el mensaje. | Inspeccione el error y solucione la causa antes de volver a intentarlo. | Una progresión satisfactoria típica es `accepted → sent → delivered → read`. No asuma que su aplicación recibirá cada actualización intermedia ni que las actualizaciones llegarán en ese orden exacto. ## Por qué una solicitud exitosa no es la entrega final Con el endpoint en cola, YCloud acepta la solicitud y la envía de forma asíncrona. Con el endpoint directo, el envío a la WhatsApp Business API se realiza de forma síncrona. La entrega final sigue siendo asíncrona en ambos casos. Para obtener detalles de implementación, consulte [Enviar un mensaje de WhatsApp](/es/api-reference/guides/whatsapp-platform/send-whatsapp-message). Si el estado actual sigue siendo `accepted` o `sent`, no envíe repetidamente el mismo contenido. Una solicitud adicional puede dar lugar a un mensaje duplicado. ## Confirmaciones de entrega y lectura Entregado significa que el mensaje llegó al dispositivo del cliente. No significa que el cliente haya abierto la conversación. Las confirmaciones de lectura no están disponibles en todas las situaciones. Por ejemplo, los ajustes de confirmación de lectura del cliente pueden determinar si se notifica una actualización de lectura. La ausencia de una actualización de lectura no demuestra que el cliente haya ignorado el mensaje. Para conocer las definiciones de estado de origen, consulte la [referencia de webhooks de estados de mensajes](https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks/components/) de Meta. ## Rastrear el mismo mensaje en distintos sistemas Al solucionar problemas, mantenga junta la siguiente información: | Información | Por qué es de ayuda | | - | - | | ID del mensaje de YCloud | Identifica el recurso del mensaje en YCloud. | | ID del mensaje de WhatsApp, si está disponible | Correlaciona el mensaje con el procesamiento previo de WhatsApp. | | Remitente, destinatario y WABA | Identifica el negocio y la interacción afectados. | | Su referencia externa, si se utiliza | Conecta el mensaje a un pedido, caso de soporte u otro evento interno. | | Marcas de tiempo del estado | Ayuda a reconstruir la secuencia cuando las actualizaciones llegan tarde o desordenadas. | | Detalles del error | Explica un fallo y guía la siguiente acción. | No incluya claves de API ni información innecesaria del cliente al compartir registros de resolución de problemas. Las integraciones de API pueden recibir webhooks de `whatsapp.message.updated` y recuperar el recurso del mensaje. Consulte las [prácticas recomendadas para la mensajería de WhatsApp](/es/api-reference/guides/whatsapp-platform/whatsapp-messages-api-best-practices) para conocer la gestión de sincronización y reintentos. ## Investigar un mensaje fallido Comience por el error devuelto, no solo por el nombre del estado. * **Problema con la plantilla:** confirme que la plantilla esté disponible y que su idioma y parámetros sean correctos. * **Problema con la ventana:** compruebe si el mensaje requiere una [ventana de atención al cliente](/es/documentation/whatsapp-business-platform/messaging/service-messages#customer-service-window) abierta. * **Problema con la cuenta o el número:** inspeccione el recurso afectado y sus restricciones actuales. * **Problema con el contenido o los archivos multimedia:** verifique los requisitos del tipo de mensaje seleccionado. * **Control de entrega:** siga las instrucciones específicas del error. Los reintentos repetidos e inmediatos podrían no resolver una restricción de la plataforma. Un mensaje fallido no demuestra que un cliente haya bloqueado su número. Utilice los detalles reales del error y evite deducir comportamientos de los clientes que la plataforma no haya informado. Para conocer los controles de entrega de la plataforma, consulte [Controles de calidad y entrega](/es/documentation/whatsapp-business-platform/pricing-limits-and-quality/quality-and-delivery-controls). Para ver avisos de cumplimiento, consulte [Restricciones de cuenta y apelaciones](/es/documentation/whatsapp-business-platform/consent-policies-and-account-health/account-restrictions-and-appeals). ## Decidir si es seguro reintentar | Evidencia actual | Gestión recomendada | | - | - | | La solicitud devolvió un ID y el estado no es final | Continúa haciendo el seguimiento de ese mensaje. No envíes otra copia solo porque el cliente no ha respondido. | | La solicitud se agotó por tiempo de espera y no sabes si fue aceptada | Concilia usando el contexto de la solicitud almacenado y los registros de mensajes disponibles antes de reintentar. Un tiempo de espera agotado no prueba que no se haya enviado nada. | | Error permanente de contenido, plantilla o permisos | Corrige la entrada subyacente o detén el envío. Repetir la misma solicitud no lo solucionará. | | Error técnico temporal | Reintenta únicamente según las indicaciones específicas del error, con un retraso, un límite de intentos y comprobando que el mensaje siga siendo útil. | | El cliente optó por no recibir mensajes o un control a nivel de destinatario bloquea la entrega | Suprime la comunicación afectada; no alternes remitentes para forzar la entrega. | | El evento comercial quedó obsoleto | Cancela el reintento incluso si el error técnico se pudiera reintentar. | Un buen registro de mensajes vincula una acción comercial prevista con sus solicitudes y resultados. Tu referencia externa ayuda a la correlación, pero no asumas que proporciona idempotencia en la API a menos que el endpoint garantice explícitamente ese comportamiento. ### Ejemplo de actualizaciones de estado retrasadas Tu sistema recibe `delivered`, y luego un evento `sent` retrasado para el mismo mensaje. No vuelvas a cambiar el estado del cliente a “no entregado”. Guarda las marcas de tiempo de los eventos y aplica un modelo de estados que tolere actualizaciones duplicadas y fuera de orden. Del mismo modo, la falta de un evento `read` no significa que el mensaje haya fallado. Separa estas métricas: * **Alcance entregado:** mensajes con comprobante de entrega. * **Alcance leído:** mensajes con confirmación de lectura reportada. * **Respuesta del cliente:** una respuesta entrante o interacción real. * **Conversión comercial:** una reserva confirmada, compra o verificación exitosa en el sistema correspondiente. ## Próximos pasos * [Revisar las reglas de mensajería](/es/documentation/whatsapp-business-platform/messaging/how-messaging-works). * [Consultar los mensajes de servicio](/es/documentation/whatsapp-business-platform/messaging/service-messages). * [Implementar el seguimiento de entregas](/es/api-reference/guides/whatsapp-platform/send-whatsapp-message). * [Contactar con el soporte de YCloud](/es/documentation/support/ycloud-support-team) con los identificadores de mensaje pertinentes y los detalles del error. ## Preguntas frecuentes No puedes llegar a esa conclusión. Las confirmaciones de lectura pueden no estar disponibles, incluso cuando el destinatario las desactiva. Mantén entregado y leído como métricas independientes. Ni la falta de una confirmación de lectura ni un error general de no entregable identifican el motivo del cliente o prueban un bloqueo. No de inmediato. Es posible que la plataforma ya haya aceptado la solicitud. Comprueba el identificador del mensaje, los registros disponibles y los eventos de webhook posteriores antes de emitir otro envío. Correlaciona los intentos con la misma acción comercial y diseña protección contra duplicados; una referencia externa no garantiza automáticamente la idempotencia del endpoint. Una limitación de visualización y un fallo de entrega son cosas distintas. Inspecciona la dirección real, el estado, el tipo de mensaje y cualquier error. Para el contenido entrante, sigue la [guía de mensajes no admitidos de Inbox](/es/documentation/inbox/unsupported-messages-in-inbox); no adivines el contenido ni consideres un marcador de posición como un envío saliente fallido. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.