API de SMS o SMPP: ¿qué conexión le conviene?

Esta guía está dirigida a ingenieros y responsables técnicos que deciden cómo conectarse a un proveedor de SMS: mediante una API HTTP/REST de SMS, mediante SMPP o con ambas. Explica en qué se diferencian realmente las dos opciones en la red y en la operación, para que pueda elegir la interfaz adecuada para cada tipo de tráfico y planificar una migración si su primera elección se le queda pequeña.

Para una visión más amplia de los patrones de integración, incluidos los webhooks y la idempotencia, consulte nuestra guía de integración de API de mensajería.

¿Qué diferencia hay entre una API de SMS y SMPP?

Una API REST de SMS envía cada mensaje como una petición HTTPS independiente y devuelve un ID de mensaje. SMPP (Short Message Peer-to-Peer) mantiene abierta una única sesión autenticada de larga duración y por ella intercambia en ambos sentidos mensajes binarios llamados PDU. REST prioriza la sencillez; SMPP, el volumen sostenido de SMS.

¿Cómo funciona una API REST de SMS?

Usted hace un POST HTTPS con un token y un cuerpo JSON, y el proveedor responde con un ID. Cada petición es independiente, así que puede enviar desde cualquier servidor, función o contenedor sin gestionar ninguna conexión.

Un envío típico con nuestra API tiene este aspecto:

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "971500000000",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

La respuesta es 200 OK con el ID del mensaje como texto plano. El estado final llega después a su webhook como SUBMITTED, SENT, DELIVERED, FAILED o REJECTED. Los nombres de los campos y las opciones están en la referencia de la API de SMS.

Puntos fuertes de REST:

• Herramientas conocidas: cualquier lenguaje, cualquier cliente HTTP y códigos de estado estándar, definidos en la RFC 9110.
• Seguridad sencilla: TLS en todo momento y un token en la cabecera Authorization.
• Envíos masivos sin conexiones: suba un archivo de destinatarios en una sola petición en lugar de abrir una sesión.
• Una sola API para muchos canales: el mismo patrón envía plantillas de WhatsApp o tarjetas RCS.

Limitaciones de REST: cada mensaje, o cada lote, cuesta un viaje de ida y vuelta HTTP, y alcanzará un límite de peticiones por segundo antes que cualquier límite del operador. Para la mayoría del tráfico de aplicaciones, esto nunca llega a importar.

¿Cómo funciona SMPP?

SMPP es un protocolo binario definido por la especificación SMPP v3.4, publicada por el SMPP Developers Forum (más tarde SMS Forum), que sigue siendo la versión más implantada. Su sistema, llamado ESME (External Short Message Entity), se conecta al SMSC (Short Message Service Centre) del proveedor y abre una sesión llamada bind.

Tipos de bind

• Transmitter (TX), con bind_transmitter: solo envía mensajes.
• Receiver (RX), con bind_receiver: solo recibe informes de entrega y mensajes entrantes.
• Transceiver (TRX), con bind_transceiver: ambas cosas en una sola sesión. Es la opción habitual.

Ciclo de vida de la sesión

1. Abra una conexión TLS con el host y el puerto que le facilite su proveedor.
2. Envíe bind_transceiver con su system_id y su contraseña, y espere una respuesta con command_status 0.
3. Envíe los mensajes con submit_sm. Cada submit_sm_resp devuelve un message_id.
4. Reciba los informes de entrega como deliver_sm y responda a cada uno con deliver_sm_resp.
5. Envíe enquire_link periódicamente mientras no haya actividad, para que ambas partes sepan que la sesión sigue viva.
6. Cierre con unbind y espere unbind_resp.

Cada PDU lleva un número de secuencia, y las respuestas llevan el mismo número; así se asocia cada submit_sm_resp con el mensaje enviado. Nuestra documentación de SMPP explica cada paso con nuestra configuración.

¿Qué es la ventana de envío de SMPP y por qué importa?

La ventana de envío (windowing) consiste en enviar varias PDU submit_sm antes de que vuelvan sus respuestas. El número de PDU sin confirmar que se permite tener en curso es la ventana. Es la principal razón por la que SMPP sostiene un rendimiento mayor que el HTTP de una petición cada vez.

Con una ventana de 1, su cliente envía un mensaje, espera un viaje de ida y vuelta completo a que llegue la respuesta y después envía el siguiente. El rendimiento queda limitado por la latencia de la red, no por la tasa acordada. Con una ventana mayor, la conexión sigue ocupada mientras llegan las respuestas.

Reglas prácticas:

• Use el tamaño de ventana que acuerde con su proveedor y no lo supere nunca; las PDU de más pueden rechazarse.
• Respete la tasa acordada por bind. Si recibe ESME_RTHROTTLED, reduzca el ritmo y reintente con espera progresiva (backoff).
• Lleve el control de los números de secuencia pendientes para que una desconexión no le haga perder la pista de qué mensajes se aceptaron.
• Escale con más binds, hasta el número acordado para su cuenta, en lugar de con una ventana cada vez mayor.

Los límites por defecto de nuestra API REST y de los binds SMPP figuran en errores y límites; los límites de su cuenta se confirman al provisionar el acceso.

¿En qué se diferencian los informes de entrega?

En REST, el proveedor envía un evento JSON a su webhook. En SMPP, el informe de entrega llega como una PDU deliver_sm en la sesión, con el bit de informe de entrega activado en esm_class. Ambos son asíncronos; ni 200 OK ni submit_sm_resp significan que el móvil haya recibido el mensaje.

La especificación SMPP v3.4 ofrece el formato de texto del informe de entrega como ejemplo y deja el formato exacto en manos del fabricante del SMSC, pero la mayoría de los proveedores lo siguen:

id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code

Si sus sistemas consumen ambas interfaces, asigne los estados de SMPP a un único modelo de estados. Una correspondencia típica:

Hay dos diferencias prácticas que importan más que el formato:

• Confirmación. Un cliente SMPP debe responder a cada deliver_sm. Los informes de entrega sin confirmar se reenvían y pueden ralentizar el bind. Por el mismo motivo, un gestor de webhooks debe responder 2xx con rapidez.
• Recuperación. Si su cliente SMPP se desconecta, los informes de entrega esperan al siguiente bind o pueden caducar en la cola del proveedor. En REST, el proveedor puede ofrecer el reenvío de los informes de entrega de un intervalo de fechas. Pregunte cómo funciona cada caso.

Lea más sobre el significado de cada estado en estados de entrega de mensajes, explicados.

¿Cómo se gestiona la codificación?

En ambas interfaces hay que elegir entre GSM-7 y Unicode, y ambas dividen los mensajes largos en segmentos. La diferencia está en quién hace el trabajo.

• REST: usted fija un campo como messageType en TEXT o UNICODE, y la plataforma segmenta los mensajes largos. Nuestra API ofrece además POST /sms/identify para contar antes los caracteres y los segmentos.
• SMPP: usted fija data_coding (0 para el alfabeto GSM-7 por defecto, 8 para UCS-2) y codifica los bytes por su cuenta. Para los mensajes largos, o bien añade una cabecera de datos de usuario (UDH) a cada parte y fija esm_class en 0x40, o bien envía todo el texto en el campo message_payload si su proveedor lo habilita.

Según la 3GPP TS 23.040, un SMS individual transporta 140 octetos: 160 caracteres GSM-7 o 70 caracteres UCS-2, que bajan a 153 o 67 por parte cuando se añade la cabecera. Una sola letra árabe o un emoji convierten todo el mensaje en Unicode. Los errores de codificación son el fallo más habitual en las integraciones SMPP, así que haga pruebas con árabe, emoji y textos largos. Consulte nuestra guía de límites de caracteres.

¿Cómo se comparan los modelos de seguridad?

REST se apoya en TLS y en un token Bearer en cada petición. SMPP v3.4 no tiene cifrado propio y envía las credenciales en el bind, así que depende del transporte y de los controles de red que lo rodean.

Para SMPP:

• Use TLS (TLS 1.3 se define en la RFC 8446) o un enlace privado; nunca SMPP sin cifrar a través de internet.
• Registre las direcciones IP de origen para que solo sus servidores puedan abrir un bind.
• Guarde el system_id y la contraseña como secretos, distintos para cada entorno, y rótelos si quedan expuestos.
• Supervise los fallos de bind, que pueden indicar un error de configuración o un uso indebido de las credenciales.

Para REST:

• Mantenga el token solo en los servidores, nunca en apps móviles ni en código del navegador.
• Evite las interfaces HTTP antiguas que pasan usuario y contraseña en la URL, donde acaban en los registros.
• Proteja el webhook con HTTPS, una ruta imposible de adivinar y validación estricta del cuerpo.

¿Cuánto le cuesta operar cada opción?

REST apenas añade carga operativa: las peticiones se completan o devuelven un error que puede reintentar. SMPP añade un componente de ejecución continua que hay que supervisar y mantener.

Un cliente SMPP necesita:

1. gestión de conexiones, con reconexión mediante espera progresiva y variación aleatoria (jitter), no en un bucle cerrado;
2. mensajes de keep-alive y detección de conexiones semiabiertas silenciosas;
3. control de ventana y de tasa por bind;
4. seguimiento de secuencias y conciliación tras las desconexiones;
5. confirmación y almacenamiento de los informes de entrega;
6. lógica de codificación y concatenación;
7. supervisión del estado del bind, el rendimiento, los errores de limitación y el retraso de los informes de entrega.

Las librerías de código abierto maduras gestionan el protocolo, pero su equipo sigue siendo responsable del comportamiento que las rodea, también durante una ventana de mantenimiento del proveedor a las tres de la madrugada.

¿Cuándo conviene usar cada una?

Use REST salvo que tenga un motivo claro para añadir SMPP.

Elija una API REST de SMS cuando

• envíe OTP, alertas, notificaciones o campañas desde aplicaciones;
• necesite WhatsApp, RCS u otros canales además del SMS;
• su plataforma funcione con funciones serverless o contenedores de vida corta;
• su equipo no tenga experiencia en SMPP ni necesidad de adquirirla.

Elija SMPP cuando

• envíe un volumen de SMS alto y sostenido y haya alcanzado los límites de REST;
• ya opere una pasarela SMPP o una plataforma de mensajería;
• sea un agregador, un operador o un revendedor que conecta el tráfico SMS de sus propios clientes;
• necesite el mismo protocolo con varios proveedores de origen.

¿Cómo es una configuración híbrida?

Muchas empresas usan ambas en la misma cuenta: REST para el tráfico multicanal y de aplicaciones, y SMPP para el SMS masivo. La trampa es acabar con dos modelos de entrega.

• Enrute por caso de uso, no al azar: por ejemplo, OTP y WhatsApp por REST, y extractos masivos por SMS a través de SMPP.
• Normalice los estados de los webhooks y de deliver_sm en una única tabla con el ID de mensaje como clave.
• Aplique una sola política de ID de remitente (sender ID) en ambas, ya que los registros valen sea cual sea la interfaz.
• Elabore los informes de forma conjunta, para que una campaña repartida entre ambas interfaces muestre un único resultado.

¿Cómo se migra de una API de SMS a SMPP?

Hágalo de forma gradual, con ambas interfaces en funcionamiento, y mida antes de trasladar volumen.

1. Confirme la necesidad: documente el volumen o el rendimiento que REST no alcanza.
2. Solicite la provisión: comparta los países de destino, los ID de remitente, el rendimiento previsto en los picos y las direcciones IP de origen.
3. Elija una librería cliente madura para su stack y encapsúlela en su propia interfaz de envío.
4. Construya primero la gestión de informes de entrega, asignada al mismo modelo de estados que sus webhooks.
5. Pruebe la codificación: GSM-7, árabe, emoji y mensajes de varias partes en móviles reales.
6. Pruebe los fallos: corte la conexión a mitad de un envío, provoque limitaciones y compruebe la conciliación.
7. Funcione en paralelo: pase a SMPP una pequeña parte de un tipo de tráfico y compare la entrega y los informes de entrega.
8. Traslade el volumen por etapas, manteniendo REST como vía de respaldo.

Una configuración de bind ilustrativa tiene este aspecto. El host, el puerto y los límites son marcadores de posición; los valores reales llegan con sus credenciales provisionadas.

host:                 <provided with your bind>
port:                 <TLS port provided with your bind>
bind type:            transceiver
system_id:            <your system_id>
password:             <your password>
system_type:          (vacío salvo indicación contraria)
interface_version:    0x34
source_addr_ton/npi:  5 / 0   (identificador de remitente alfanumérico)
dest_addr_ton/npi:    1 / 1   (número internacional)
registered_delivery:  1       (solicitar recibos de entrega)
data_coding:          0 (GSM-7) or 8 (UCS-2)
enquire_link:         every 30 seconds while idle
window:               as agreed for your account

Ejemplo práctico: un minorista regional añade SMPP para los extractos

«Souq Rafiq» (ficticio), un comercio online con presencia en Emiratos Árabes Unidos, Egipto y Jordania, envía OTP y actualizaciones de pedidos a través de una API REST, y plantillas de WhatsApp a través de la misma API. Los extractos mensuales de cuenta, enviados por SMS a toda su base de clientes, han crecido hasta el punto de que el proceso por REST tarda más de lo que el negocio quiere.

• Decisión: mantener los OTP, las actualizaciones de pedidos y WhatsApp en REST, y trasladar los SMS de extractos mensuales a un bind transceiver SMPP.
• Provisión: el equipo registra dos IP de origen, confirma los ID de remitente por país y acuerda el rendimiento y el número de binds.
• Desarrollo: un pequeño servicio SMPP usa una librería de código abierto, escribe los informes de entrega en la misma tabla de estados que usa el webhook y expone la misma interfaz interna de envío que la vía REST.
• Pruebas: se confirma en varios móviles que los extractos en árabe se envían en UCS-2 con una concatenación correcta.
• Despliegue: primero migra un país. Tras comparar la entrega y los tiempos de los informes de entrega con la referencia de REST, le siguen los demás, con REST como respaldo.

Errores habituales

• Elegir SMPP por prestigio. Si REST cubre su volumen, SMPP solo añade trabajo.
• Trabajar con una ventana de 1 y culpar después al proveedor del bajo rendimiento.
• No confirmar los deliver_sm, lo que provoca reenvíos de informes de entrega y limitaciones.
• Reconectar en un bucle cerrado tras una desconexión, lo que puede parecer un ataque.
• Mezclar short_message y message_payload en la misma PDU, lo que provoca errores de longitud.
• SMPP sin cifrar a través de internet, que expone credenciales y contenido.
• Dos modelos de estados en una configuración híbrida, con informes que no cuadran.
• Limitaciones: esta guía describe prácticas habituales. Los tamaños de ventana, las tasas, los puertos TLS y los detalles de los informes de entrega varían según el proveedor y la cuenta; confírmelos durante la provisión.

Cómo ayuda OmniChannels.ai

OmniChannels.ai ofrece ambas opciones. La API REST en https://api.broadnet.me usa un token Bearer y cubre el SMS junto con WhatsApp, RCS, Messenger, Instagram, Telegram, Email y Push, con los estados de entrega enviados a su webhook en un único formato. Para el SMS de gran volumen, los binds SMPP 3.4 sobre TLS se provisionan por cuenta, con IP de origen autorizadas, y usan las mismas rutas SMS sobre la conectividad directa de BroadNet con los operadores. Los revendedores y los socios mayoristas pueden disponer de binds dedicados. Empiece por la documentación de SMPP o la guía de inicio rápido, o consulte la introducción para desarrolladores.