Entre la llamada a la API y la vibración del teléfono pasan menos de cinco segundos y más de diez etapas. Recorremos el proceso completo según la documentación oficial de la API de Grupo Tecnophone.
Por qué conviene entender el recorrido
Para el equipo de desarrollo, un SMS es una petición HTTP que devuelve un identificador. Para el equipo de operaciones, es un renglón en un reporte. Para el cliente, es una vibración en el bolsillo. Entre esos tres puntos de vista hay una cadena de sistemas y decisiones que determina si el mensaje llega, cuánto tarda y cuánto cuesta.
Este artículo describe ese recorrido tal como lo implementa la plataforma de Grupo Tecnophone, siguiendo su documentación oficial de la API. Sirve para integrar mejor, diagnosticar más rápido y entender qué significa cada dato de la respuesta y de los reportes.
Etapa 1: su sistema hace la petición
Todo empieza con una petición POST a https://api.grupotecnophone.com/prod/v1/sms/send (o a /test/v1/sms/send en sandbox). El cuerpo es un JSON con dos campos: to, el número de destino, y body, el texto del mensaje. Los encabezados obligatorios son Authorization: Bearer {token}, con el token asignado a la conexión, y un User-Agent identificable, que la plataforma utiliza para trazabilidad, soporte y detección de patrones de uso anómalos.
POST /prod/v1/sms/send HTTP/1.1
Host: api.grupotecnophone.com
Authorization: Bearer SU_TOKEN
User-Agent: MiEmpresa/1.0
Content-Type: application/json
{"to": "+5215512345678", "body": "Su código MiEmpresa es 482913. No lo comparta."}Etapa 2: controles de seguridad
Antes de mirar el contenido, la plataforma verifica tres cosas. Que la comunicación llegue por HTTPS; toda la API opera exclusivamente sobre transporte cifrado. Que el token sea válido y esté activo; si falta o es inválido, responde 401. Y que la dirección IP de origen esté en la lista de IPs autorizadas para ese token, configurada desde el panel; si no lo está, responde 403.
Cada conexión opera además en un modo de cifrado definido por el cliente. En modo cifrado activo, los campos to y body deben llegar cifrados con RSA-OAEP-SHA256 y codificados en Base64; si llega texto plano, la API responde con el error ENCRYPTION_REQUIRED (código 1999). En modo cifrado desactivado ocurre lo contrario: si detecta contenido cifrado, responde ENCRYPTION_NOT_ALLOWED. La estructura del JSON es idéntica en ambos casos; solo cambia el contenido de los campos.
Etapa 3: validación y normalización
Superados los controles de acceso, la plataforma valida el número de destino y lo normaliza al formato internacional E.164 (por ejemplo, +5215512345678). El número puede enviarse con código de país o como número nacional; si la conexión está asociada a un único país, la plataforma completa automáticamente el prefijo configurado para esa ruta.
Luego aplica las reglas comerciales de la cuenta: verifica que el número no esté en una lista de exclusión (de lo contrario responde INPUT_PHONE_BLACKLISTED, código 1205), comprueba el saldo en cuentas prepagas (INSUFFICIENT_BALANCE, código 8001, si no alcanza) y valida cualquier otra restricción configurada. Todos estos rechazos devuelven un HTTP 400 con un código simbólico, un código numérico y un mensaje descriptivo, de modo que su sistema pueda tratarlos de forma diferenciada.
Etapa 4: codificación y segmentación
Con el mensaje aceptado, la plataforma determina cómo se codificará. Si el texto solo usa caracteres del alfabeto GSM7, cabe en segmentos de 160 caracteres. Si incluye caracteres que GSM7 no soporta (ciertos acentos, la ñ minúscula, emojis), necesita UCS-2, con segmentos de 70 caracteres.
El comportamiento depende de la configuración de la conexión: si solo está habilitado GSM7, los caracteres no soportados se normalizan o sustituyen por equivalentes compatibles; si UCS-2 está habilitado, la plataforma intenta usar GSM7 siempre que sea posible y solo recurre a UCS-2 cuando el texto lo exige, para evitar cargos adicionales. La concatenación también se controla por conexión: si no está activa, el mensaje se limita a un único segmento. El resultado se refleja en la respuesta en los campos encoding, num_chars y num_segments.
Etapa 5: aceptación y respuesta a su sistema
En este punto la plataforma asigna un identificador único a la solicitud, el sid (por ejemplo, sms_20251213164422_39bdafbd), y responde con HTTP 200. La respuesta incluye el estado, el número normalizado, la codificación, el número de caracteres y de segmentos, y un campo de error vacío. El estado inicial del mensaje es en cola: aceptado y pendiente de entrega.
{
"sid": "sms_20251213164422_39bdafbd",
"status": "success",
"to": "+5215512345678",
"encoding": "GSM7",
"num_chars": 48,
"num_segments": 1,
"error": null
}Es importante entender que el 200 significa aceptado por la plataforma, no entregado al teléfono. La entrega ocurre en las etapas siguientes, y su resultado llega después por el reporte de entrega. Guarde el sid: es la llave para todo lo que sigue.
Etapa 6: enrutamiento hacia el operador
El mensaje entra en la cola de envío de la plataforma, que decide la ruta según el operador de destino, consultando la portabilidad para saber a qué red pertenece hoy ese número. Grupo Tecnophone opera con conexiones directas a los principales operadores en México y rutas redundantes, de modo que si una conexión se degrada, otra toma el tráfico.
La comunicación con el operador se realiza mediante SMPP (Short Message Peer-to-Peer), el protocolo estándar entre plataformas de mensajería y los centros de mensajes (SMSC) de los operadores. Cuando el SMSC acepta el mensaje, devuelve su propio identificador, el msgid_smpp, que la plataforma asocia al sid. Ese identificador puede no estar disponible de inmediato en la respuesta inicial, pero queda registrado para trazabilidad.
Etapa 7: entrega por el operador
El SMSC del operador localiza al abonado en su red (en qué celda está registrado el teléfono) y le entrega el mensaje por el canal de señalización, lo que explica por qué un SMS llega aunque el usuario no tenga datos ni una app abierta. Si el teléfono está apagado o sin cobertura, el SMSC guarda el mensaje y reintenta durante el periodo de validez; si vence, lo marca como expirado.
Los operadores también aplican sus propios filtros de contenido y comportamiento en esta etapa. Un remitente registrado, un contenido claro y un patrón de tráfico consistente son la mejor garantía de pasar esos filtros.
Etapa 8: el reporte de entrega vuelve
Cuando el teléfono confirma la recepción, el SMSC genera un reporte de entrega (DLR) que viaja de vuelta por la conexión SMPP hasta la plataforma. Allí se asocia al sid original y el estado del mensaje pasa a entregado, con fecha y hora; si la entrega falló o expiró, el estado lo refleja con el motivo que el operador haya informado.
Ese estado queda disponible en el panel de la plataforma, por mensaje, campaña y operador; se puede exportar a CSV; y, si configuró un webhook, la plataforma envía una petición HTTP a su sistema con el sid y el estado final en cuanto lo recibe. Las respuestas del cliente (mensajes MO) siguen el camino inverso, del teléfono al operador, de allí a la plataforma y por webhook a su sistema.
Cuánto dura todo esto
En condiciones normales, desde la petición hasta la entrega pasan entre uno y cinco segundos. Las etapas 1 a 5 ocurren en milisegundos dentro de la plataforma; el tiempo restante es el enrutamiento y la entrega en la red del operador. Los factores que alargan el recorrido son la congestión del operador en horas pico, el teléfono apagado o sin cobertura, y las colas compartidas con tráfico masivo, razón por la que se recomienda separar el tráfico transaccional en su propia conexión.
Si quiere probar el recorrido completo sin enviar mensajes reales, el ambiente sandbox valida todas las etapas de la plataforma (token, IP, payload, cifrado, reglas) y le devuelve la misma estructura de respuesta. La documentación oficial, con ejemplos en cURL, PHP, Python, Node y Java, está en la sección de Desarrolladores; para configurar una conexión, escríbanos desde la página de contacto.
Preguntas frecuentes
¿Necesita una plataforma SMS para su empresa?
Grupo Tecnophone ofrece mensajería SMS empresarial con rutas directas 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.