Cómo elegir una API de mensajería: checklist para CTO

Esta checklist está dirigida a CTO, responsables de ingeniería y arquitectos que eligen una API de mensajería para SMS, WhatsApp, RCS y otros canales. Convierte una comparación difusa de proveedores en preguntas concretas, pruebas que se pueden hacer en una tarde y una tabla de puntuación que podrá defender ante los equipos de finanzas y de seguridad.

Si ya ha elegido proveedor y necesita construir la integración, lea mejor nuestra guía de integración de API de mensajería. Este artículo trata de la decisión previa.

¿Qué debe evaluar un CTO en una API de mensajería?

Evalúe lo que afecta a los resultados en producción: si los mensajes llegan, si puede ver lo que ha ocurrido, si la integración resiste los fallos y si sigue cumpliendo la normativa. Las listas de funciones se parecen entre proveedores; estas propiedades, no.

¿Cubre la API los canales que necesita?

Busque una única URL base, un único esquema de autenticación y un único modelo de estados de entrega para todos los canales. Las integraciones separadas por canal multiplican el código que hay que mantener y los puntos en los que se puede perder un estado.

• Enumere sus canales para los próximos dos años, no solo los de hoy. Los equipos que empiezan con OTP por SMS suelen añadir plantillas de WhatsApp, luego RCS y después correo electrónico o notificaciones push.
• Compruebe la profundidad de cada canal, no solo el logotipo. En WhatsApp, ¿puede gestionar plantillas, enviar mensajes interactivos y seguir su aprobación a través de la API? En SMS, ¿hay mensajería bidireccional, Unicode y consulta de números?
• Compruebe el respaldo. Si un mensaje de WhatsApp no se entrega, ¿puede la plataforma recurrir a RCS o SMS, y se puede configurar el orden por caso de uso? Nuestra comparativa de WhatsApp, SMS y RCS explica cuándo encaja cada canal.

¿Cómo se valora la calidad de las rutas?

Pregunte cómo llega el proveedor a cada operador de sus principales mercados y compruébelo usted mismo. La calidad de la ruta determina si el mensaje llega, si su ID de remitente se mantiene y si el informe de entrega refleja lo que realmente ocurrió.

Una ruta directa significa que el proveedor se conecta con el operador, o con un socio autorizado, mediante un acuerdo que cubre el tráfico de aplicación a persona (A2P). Una ruta gris canaliza tráfico A2P por caminos no pensados para ello, como conexiones de SIM de consumo. Las rutas grises pueden parecer más baratas en la tarifa, pero conllevan riesgos reales:

• el ID de remitente se sustituye por un número aleatorio, lo que rompe la confianza y los hábitos de autocompletado del OTP;
• los operadores detectan y bloquean el tráfico, a veces en mitad de una campaña;
• los informes de entrega pueden generarlos la propia ruta y no la red, así que «entregado» puede no significar entregado.

Preguntas que hacer:

1. ¿A cuáles de nuestros países y operadores de destino llegan de forma directa?
2. ¿Cómo gestionan el registro del ID de remitente en cada país?
3. ¿De dónde proceden sus informes de entrega y transmiten el código de error del operador?
4. ¿Qué ocurre con nuestro tráfico cuando una ruta se degrada? ¿El cambio de ruta es automático y nos lo comunican?

Después, pruébelo: envíe a móviles reales de cada operador principal, compruebe el ID de remitente que aparece y compare los informes de entrega con lo que muestran los teléfonos. Consulte qué es el SMS A2P para entender cómo llega el SMS empresarial a los operadores.

¿Cómo se gestionan los informes de entrega y los webhooks?

El proveedor debe enviar los estados de entrega a su endpoint HTTPS, en un formato normalizado para todos los canales, y darle una forma de recuperar los eventos que se haya perdido. Consultar mensaje a mensaje (polling) no es un diseño sostenible.

Cómo es lo correcto:

• Una lista de estados documentada. Por ejemplo, SUBMITTED, SENT, DELIVERED, READ, FAILED y REJECTED, indicando cuáles son finales. Nuestra guía de estados de entrega explica qué significa cada uno en la práctica.
• Motivos de fallo. Un estado FAILED o REJECTED debe incluir el motivo del operador o del canal cuando exista.
• Recuperación. Si su endpoint no está disponible, ¿puede pedir que se reenvíen los informes de entrega de un intervalo de fechas o consultar el estado por destinatario?
• Pautas honestas sobre orden y duplicados. Los eventos pueden llegar desordenados y más de una vez. Una documentación que lo reconoce es más fiable que una que lo ignora.
• Seguridad del endpoint. Pregunte si los webhooks van firmados. Si no lo están, el proveedor debe explicar cómo proteger el endpoint, por ejemplo solo HTTPS, una ruta imposible de adivinar, validación estricta del cuerpo y confirmación del estado antes de acciones irreversibles.

¿Qué autenticación y seguridad cabe esperar?

Como mínimo: tokens enviados en una cabecera Authorization sobre TLS, nunca en las URL; un proceso claro para rotar y revocar credenciales; y controles de seguridad auditados de forma independiente. Los tokens Bearer se definen en la RFC 6750, y el OWASP API Security Top 10 es una buena lista para repasar con el proveedor.

Pregunte:

• ¿Cómo se emiten, se acotan y se revocan los tokens? ¿Puede tener tokens distintos por servicio o entorno? ¿Con qué rapidez se revoca un token filtrado?
• ¿Se pasan alguna vez las credenciales como parámetros de URL? Algunas API HTTP antiguas siguen recibiendo usuario y contraseña en la cadena de consulta, donde acaban en los registros. Evítelo en las integraciones nuevas.
• ¿Hay lista de IP permitidas y dónde? Es habitual en los binds SMPP; compruebe si también se aplica a REST.
• ¿Qué certificaciones cubren el servicio? Pida el certificado o el informe, no solo un logotipo, y compruebe su alcance.
• ¿Dónde se almacena el contenido de los mensajes y durante cuánto tiempo? Es importante para las revisiones de protección de datos.

¿Qué límites de peticiones y qué capacidad hay que prever?

Espere límites por defecto documentados, una respuesta 429 Too Many Requests (RFC 6585) con la cabecera Retry-After cuando los supere y un proceso para acordar techos más altos en los picos de producción. Los límites no documentados se descubren durante su campaña más importante.

• Pida los límites por interfaz: las peticiones REST, los binds SMPP y las consultas de números suelen tener límites distintos.
• Compruebe los endpoints de envío masivo. Enviar una sola petición con un archivo de destinatarios respeta mejor los límites que miles de peticiones individuales.
• Pregunte cómo se gestionan los picos. Las ventas flash y las alertas de incidencias exigen planificación con el proveedor, no esperanza.
• Planifique su lado. Una cola y un limitador de tipo token bucket delante de la API mantienen a varios procesos dentro de su cuota.

Nuestra referencia de errores y límites muestra cómo es esta documentación en la práctica.

¿Qué calidad tienen los SDK y la documentación?

Una buena documentación permite a un ingeniero enviar un mensaje real, recibir un estado y gestionar un error sin abrir una incidencia de soporte. Pida el documento OpenAPI; un proveedor que lo mantiene puede ofrecerle clientes generados, colecciones de Postman y nombres de campo exactos.

Señales de calidad:

• una especificación OpenAPI 3.x que coincide con la API real;
• al menos un SDK mantenido y ejemplos HTTP sencillos para otros lenguajes;
• nombres exactos de los campos de la petición, un cuerpo de error documentado con un código legible por máquina y ejemplos de respuestas;
• una guía de inicio rápido que termina con un estado de entrega, no solo con «200 OK»;
• notas honestas sobre lo que no está soportado.

¿Cómo gestiona la API los reintentos y los duplicados?

Una petición de envío puede completarse en el servidor y perderse la respuesta, de modo que un reintento a ciegas envía dos veces el mismo mensaje al cliente. Pregunte cómo espera el proveedor que lo evite.

Algunas API aceptan una clave de idempotencia: envía un valor único con la petición y, si la repite con el mismo valor, recibe el resultado original. Otras, incluida la nuestra, no la aceptan; el patrón documentado consiste entonces en registrar cada envío en su base de datos antes de hacerlo, guardar el ID de mensaje devuelto y, tras un tiempo de espera agotado, buscar pruebas de que fue aceptado antes de reenviar. Ambos enfoques sirven si están documentados. Lo que no sirve es un proveedor que no lo ha pensado. La página de errores y límites muestra el patrón de registrar antes de enviar.

¿Hay un acceso de prueba seguro?

Debe poder probar con mensajes reales a números que controla antes de que el tráfico llegue a los clientes. Pregunte cómo es el acceso de prueba: un sandbox que simula respuestas o envíos reales restringidos a números verificados.

Los sandboxes simulados son útiles para las pruebas unitarias, pero rara vez reproducen el comportamiento de los operadores. Los envíos reales a números verificados muestran cómo aparece de verdad el ID de remitente, la codificación y los informes de entrega. Pregunte cuánto se tarda en pasar del acceso de prueba al de producción, ya que en algunos países la aprobación del ID de remitente depende de los plazos del regulador.

¿Necesita una opción SMPP?

Probablemente no desde el primer día, pero quizá más adelante. SMPP v3.4 es el protocolo de telecomunicaciones para intercambiar SMS a través de una conexión persistente, adecuado para volúmenes de SMS altos y sostenidos, agregadores y revendedores. Pregunte si el proveedor ofrece SMPP sobre TLS, cómo se provisionan los binds y si se usan las mismas rutas que con REST. Nuestra guía API de SMS frente a SMPP compara ambas opciones en detalle.

¿Pueden los agentes de IA usar la API de forma segura?

Si sus equipos usan asistentes de IA o construyen agentes, un servidor Model Context Protocol (MCP) les permite descubrir y llamar a herramientas de mensajería sin código de integración a medida. Pregunte qué puede hacer el agente y con qué permisos.

Preguntas que hacer:

• ¿Actúa el servidor MCP con el mismo token y los mismos permisos que nuestro propio código?
• ¿Podemos activar solo las herramientas que necesita un agente, como los informes de entrega sin las herramientas de envío?
• ¿Hay claves temporales para experimentos?
• ¿Aparecerán los envíos en los mismos informes de entrega, para poder auditar el comportamiento del agente?

Consulte la documentación de nuestro servidor MCP como ejemplo de estos controles.

¿Qué apoyo al cumplimiento normativo debe ofrecer el proveedor?

El proveedor debe ayudarle a registrar los ID de remitente donde sea obligatorio, facilitar la gestión de las bajas y tratar los datos con controles de seguridad y privacidad reconocidos. La responsabilidad sobre el consentimiento sigue siendo suya; el proveedor debe hacerla viable.

• ID de remitente: algunos países exigen registrar los identificadores alfanuméricos y otros exigen identificadores regulatorios en cada mensaje. Consulte nuestra guía de registro del ID de remitente en Emiratos Árabes Unidos y Arabia Saudí.
• Consentimiento: pregunte cómo se recogen las bajas en el SMS bidireccional y cómo llegan a sus sistemas. Nuestra guía de consentimiento explica las obligaciones.
• Protección de datos: pregunte por los acuerdos de encargo del tratamiento, la ubicación del alojamiento, la conservación y los subencargados.

¿Qué preguntar sobre el soporte y los SLA?

Trate las condiciones de soporte como parte del producto y consígalas por escrito. No compare las cifras destacadas de los materiales comerciales; compare a qué se compromete el contrato.

• ¿Cómo se detectan, comunican y cierran las incidencias?
• ¿Qué horarios, zonas horarias e idiomas cubre el soporte?
• ¿Quién gestiona los problemas del lado del operador, como un ID de remitente bloqueado en un país?
• ¿Hay un contacto asignado o un ingeniero de incorporación durante la integración?
• ¿A qué se compromete el acuerdo, cómo se mide y qué ocurre si no se cumple?

¿Qué transparencia tienen los precios?

Debe poder estimar la factura mensual a partir de una tarifa publicada y sus volúmenes. Pregunte:

• ¿Los precios son por mensaje, por segmento o por mensaje entregado, y varía esto según el canal?
• ¿Qué cargos de terceros se repercuten por separado, como los cargos de WhatsApp de Meta?
• ¿La facturación es prepago o pospago, y qué ocurre si el saldo se agota en mitad de una campaña?
• ¿Se cobran aparte la consulta de números, el registro del ID de remitente y los binds SMPP dedicados?

Recuerde que los mensajes Unicode y los largos ocupan más segmentos de SMS. Nuestra guía de límites de caracteres explica por qué una campaña en árabe puede costar más que su versión en inglés.

¿Cómo se puntúa a los proveedores?

Haga la misma prueba práctica con cada proveedor preseleccionado y puntúelos después en una sola tabla. Pondere los criterios según sus propias prioridades; los pesos siguientes son un punto de partida, no un estándar.

Procedimiento de puntuación

1. Preseleccione de dos a cuatro proveedores que cubran sus canales y países.
2. Solicite acceso de prueba a cada uno y anote cuánto tarda.
3. Haga con cada proveedor la prueba rápida que se describe más abajo.
4. Envíe a móviles reales de cada operador principal de sus mercados clave.
5. Formule por escrito las preguntas de cada sección anterior.
6. Puntúe cada criterio de 1 a 5, multiplique por el peso y sume.
7. Revise las dos mejores puntuaciones con seguridad, finanzas y el equipo que gestionará la integración.

Una prueba rápida

La documentación de cada proveedor debería permitirle hacer algo así. Esta es la llamada equivalente a nuestra API, tal como aparece en la guía de inicio rápido:

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

Una llamada correcta devuelve 200 OK con el ID del mensaje como texto plano. Durante la prueba, compruebe cuatro cosas más: qué pasa con un token deliberadamente no válido (cabe esperar un 401), con un número mal formado (cabe esperar un 400 con un código de error), con un mensaje en árabe (debe enviarse como Unicode; consulte la referencia de la API de SMS) y si llega un estado DELIVERED a su webhook.

Ejemplo práctico: una fintech elige proveedor de OTP y alertas

«Nakheel Pay» (ficticia), una app de pagos en Arabia Saudí y Emiratos Árabes Unidos, necesita OTP por SMS ya y alertas de transacciones por WhatsApp en el plazo de un año.

• Preselección: tres proveedores que cubren ambos países y ambos canales.
• Prueba rápida: el acceso de prueba de un proveedor llega en pocos días; otro exige un largo proceso comercial antes de cualquier prueba. Queda anotado en el criterio de acceso de prueba.
• Pruebas en móviles: con un proveedor, el ID de remitente registrado aparece en todos los operadores probados; con otro, un operador muestra un remitente numérico. Se pregunta a ese proveedor por su ruta y obtiene una puntuación baja en calidad de ruta.
• Duplicados: el equipo confirma cómo gestiona cada proveedor los reintentos. Uno acepta una clave de idempotencia; otro documenta un patrón de registrar antes de enviar. Ambos son aceptables; el equipo implementa el patrón una sola vez en su servicio de envío.
• Revisión de seguridad: el equipo de seguridad comprueba el alcance de los certificados y el proceso de revocación de tokens.
• Decisión: la tabla ponderada favorece al proveedor con rutas directas, webhooks normalizados y una opción SMPP para crecer más adelante, aunque otro tenía un precio por SMS algo más bajo en su tarifa.

Errores habituales al elegir una API de mensajería

• Elegir solo por el precio por mensaje. Los mensajes no entregados y los ID de remitente sustituidos cuestan más de lo que ahorran.
• Probar solo en un sandbox simulado. El comportamiento de los operadores solo se ve en móviles reales.
• Ignorar los duplicados. Un bucle de reintentos sin protección envía los OTP dos veces.
• Confundir «enviado» con «entregado». Pregunte cómo se comunican los estados finales.
• Dejar la revisión de seguridad para después de la integración, cuando cambiar de proveedor sale caro.
• Aceptar compromisos verbales. Las condiciones de soporte y de servicio deben figurar en el contrato.
• Límites de esta checklist: describe buenas prácticas, no asesoramiento jurídico. Confirme las normas de cada país con los reguladores y con su proveedor.

Cómo ayuda OmniChannels.ai

OmniChannels.ai le ofrece una única API REST en https://api.broadnet.me para SMS, WhatsApp, RCS, Messenger, Instagram, Telegram, Email y Push, con autenticación por token Bearer, unas 330 rutas documentadas, una especificación OpenAPI 3.1 y el SDK de TypeScript @broadnet/cpaas-sdk. Los estados de entrega llegan a su webhook en un único formato. Para SMS de gran volumen está disponible SMPP 3.4 sobre TLS, y un servidor MCP permite a los agentes de IA usar la misma API. El tráfico circula por las conexiones directas de BroadNet con más de 1.000 operadores y agregadores. El acceso de prueba se limita a sus propios números verificados; empiece por la introducción para desarrolladores.