Enviar un SMS es la mitad del trabajo; la otra mitad es saber si llegó. Explicamos los reportes de entrega, los estados de un mensaje y cómo recibir todo eso en su sistema mediante webhooks.
Por qué no basta con saber que el mensaje se envió
Cuando su sistema llama a la API y recibe una respuesta correcta, el mensaje fue aceptado por la plataforma, no entregado al teléfono. Entre ese momento y la llegada al dispositivo pasan varias etapas: enrutamiento al operador, aceptación por parte de la red, intentos de entrega si el teléfono está apagado o sin cobertura, y finalmente la confirmación o el rechazo.
Para una alerta bancaria, un OTP o un aviso de entrega, esa diferencia importa. Si el mensaje no llegó, su sistema debería saberlo para reintentar por otro canal, avisar al agente de soporte o simplemente registrarlo. El mecanismo que lo permite es el reporte de entrega, conocido como DLR (Delivery Report).
Qué es un reporte de entrega (DLR)
El DLR es una notificación que el operador móvil devuelve por cada mensaje, indicando su estado final. Viaja de vuelta por la misma cadena: del operador al gateway del proveedor, y de ahí a su panel, a sus reportes y, si lo configuró, a su sistema.
Los estados más habituales a lo largo del ciclo de vida son: aceptado (la plataforma validó la petición y asignó un sid), en cola (el mensaje está enrutado hacia el operador), enviado (el operador lo recibió en su red), entregado (el teléfono confirmó la recepción) y fallido o no entregado (el operador no pudo completar la entrega, con un motivo: número inexistente, teléfono apagado durante el periodo de validez, número en lista de exclusión, rechazo por filtros del operador). Algunos operadores también reportan expirado cuando se agotó el tiempo de reintentos.
En la plataforma de Grupo Tecnophone, los reportes se pueden consultar por mensaje, por campaña y por operador, exportar a CSV o recibir en tiempo real mediante webhook.
Qué es un webhook y por qué es mejor que consultar
Hay dos formas de conocer el estado de un mensaje: preguntar (polling) o que le avisen (webhook). Con polling, su sistema consulta periódicamente el estado de cada envío, lo que genera carga innecesaria y retrasos. Con un webhook, usted registra una URL de su sistema y la plataforma le envía una petición HTTP cada vez que ocurre un evento: el mensaje fue entregado, falló, o un cliente respondió.
El webhook convierte a su sistema en receptor de eventos. En cuanto el operador confirma la entrega, su base de datos se actualiza sin que nadie tenga que preguntar. Para operaciones críticas, es la única forma razonable de mantener sincronizado el estado real de las comunicaciones.
Cómo implementar el receptor del webhook
- Exponga un endpoint HTTPS en su sistema que acepte peticiones POST con cuerpo JSON.
- Responda rápido con un código 200; procese el evento de forma asíncrona (cola interna) si necesita hacer trabajo pesado.
- Haga el procesamiento idempotente: el mismo evento puede llegar más de una vez; use el sid como clave para no duplicar actualizaciones.
- Cruce el sid del evento con el registro de su envío original para actualizar el estado del pedido, la alerta o la sesión.
- Registre todos los eventos recibidos con su timestamp; le servirán para auditoría y para resolver reclamos.
- Restrinja el acceso al endpoint a las IPs de la plataforma y valide el formato del payload antes de procesarlo.
Si su endpoint no está disponible en el momento del evento, conviene tener un proceso de reconciliación que consulte los reportes exportados para cubrir cualquier hueco.
Mensajes entrantes (MO): cuando el cliente responde
Además de los reportes de entrega, el mismo mecanismo sirve para recibir mensajes originados por el cliente (MO, Mobile Originated): una respuesta a una encuesta, una confirmación de cita con la palabra SI, una solicitud de baja con la palabra BAJA. La plataforma recibe la respuesta del operador y la entrega a su sistema por webhook, con el número del remitente, el texto y la fecha.
Esto habilita flujos bidireccionales sin que el cliente instale nada: confirmar una entrega, validar una operación, atender una solicitud de contacto. Las respuestas también quedan visibles en el panel y se pueden exportar.
Qué hacer con los datos de entrega
Los reportes no son solo un registro; son una fuente de decisiones. Una tasa de fallos alta en un operador específico puede indicar un problema de ruta que su proveedor debe atender. Una lista de números que fallan de forma recurrente debería depurarse de sus bases para no pagar por mensajes que nunca llegan. Y los tiempos entre envío y entrega le dicen si su tráfico transaccional está compitiendo con campañas masivas y necesita una conexión separada.
En el panel de Grupo Tecnophone estos indicadores están disponibles por proyecto, campaña y operador. Para integrarlos a sus propios dashboards, el webhook y la exportación a CSV son el camino. Los detalles de configuración están en la sección de Desarrolladores.
Los reportes de entrega están disponibles tanto en la API SMS, mediante webhooks, como en la conexión SMPP, mediante deliver_sm.
Si está empezando, conviene entender primero qué es un SMS gateway y cómo conecta su sistema con las redes móviles.
Fuentes
- “Short Message Peer to Peer Protocol Specification v3.4”, SMPP Developers Forum, 12 de octubre de 1999. Ver fuente
- “RFC 9110: HTTP Semantics”, IETF, junio de 2022. Ver fuente
- “RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format”, IETF, diciembre de 2017. Ver fuente
Preguntas frecuentes
¿Necesita una plataforma SMS para su empresa?
Grupo Tecnophone ofrece mensajería SMS empresarial en México, API con sandbox y cifrado, reportes de entrega por mensaje y un panel para campañas. Hable con un experto o revise la documentación para desarrolladores.