Enviar el primer SMS mediante la API de un proveedor lleva una tarde. Lo que viene después —qué significa "enviado", qué pasa si una solicitud expira, cómo se atribuye un mensaje a un resultado de negocio y cuánto cuesta cambiar de proveedor— es lo que decide si la integración se mantiene sana o se convierte en un impuesto permanente.
Un contrato interno estable, no llamadas al SDK del proveedor
La decisión más importante es evitar que el código de la aplicación llame directamente al SDK de un proveedor. Conviene definir un contrato interno propio —destino, cuerpo o plantilla, clase de tráfico, remitente, referencia propia— y dejar todo lo específico del proveedor detrás de un adaptador. Así, incorporar un segundo proveedor es un adaptador nuevo, no una reescritura.
Referencias propias e idempotencia ante timeouts ambiguos
Hay que generar una referencia propia para cada mensaje antes de llamar al proveedor, porque el caso interesante es aquel en el que la solicitud expira sin respuesta: el mensaje puede o no haberse enviado. Conviene usar claves de idempotencia del proveedor cuando existan, o consultar por la referencia propia antes de reintentar, y definir una política explícita por clase de tráfico para los casos ambiguos.
Remitente, registro y clase de tráfico
La identidad del remitente no es un valor libre: según el mercado puede requerir sender ID alfanumérico registrado, número largo o código corto, con plazos de registro de semanas. La clase de tráfico debe ser un campo obligatorio en cada envío, porque determina remitente, ruta y si el mensaje está permitido en ese mercado.
Codificación y segmentación
GSM-7 permite 160 caracteres por segmento simple; un solo carácter Unicode —una comilla tipográfica, un emoji, un nombre acentuado— convierte todo el mensaje a UCS-2, reduciendo el límite a 70. Como la facturación es por segmento, conviene calcular la codificación antes del envío, guardar el conteo en el registro del mensaje y validar plantillas al guardarlas.
Mapeo de estados, webhooks y reintentos
Cada proveedor tiene su propio vocabulario de estados y errores; conviene mapearlos a un conjunto canónico propio y tratar los valores no reconocidos como una alerta explícita. Los webhooks necesitan verificación de firma, protección contra repetición, tolerancia a duplicados y a la llegada desordenada de eventos, y procesamiento asíncrono con reconciliación periódica de mensajes atascados. Los reintentos deben tener un único responsable de política, con límites acotados y una fecha límite tras la cual el mensaje se descarta en vez de entregarse tarde.
Medición y salida del proveedor
El acuse de entrega es un proxy débil del resultado: conviene medir en la capa de aplicación —finalización de la acción, clics, tasas de respuesta y baja— con un ID de correlación que abarque todo el recorrido. Flowstates suministra rutas de mensajería y puede operar esta capa; los clientes también pueden mantener sus propios contratos vía BYOV o combinar ambos modelos bajo un único contrato operativo.
Los límites de seguridad del SMS
El SMS ordinario no está cifrado de extremo a extremo: el contenido es visible para intermediarios en la cadena de entrega y se almacena en texto plano en el teléfono, a menudo en la pantalla de bloqueo. Nunca deben enviarse contraseñas, números de cuenta completos o datos de salud; los códigos de un solo uso deben ser de corta vida, vinculados a la sesión que los solicitó, y nunca acompañados del identificador de cuenta.