Skip to main content
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: 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. 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 de Meta.

​
Rastrear el mismo mensaje en distintos sistemas

Al solucionar problemas, mantenga junta la siguiente informació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 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 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. Para ver avisos de cumplimiento, consulte Restricciones de cuenta y apelaciones.

​
Decidir si es seguro 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

​
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; no adivines el contenido ni consideres un marcador de posición como un envío saliente fallido.