La llamada a la API no es el sistema
Enviar un SMS A2P es una petición HTTP. Operar SMS A2P es gestionar dependencias que no controlas: registros de remitente por mercado, rutas de proveedor, filtrado de carrier, estado del terminal y el flujo de aplicación al que sirve el mensaje.
El registro de remitente es una dependencia de mercado
En EE. UU. el tráfico A2P sobre long codes se registra vía The Campaign Registry (10DLC), y el caso de uso declarado influye en el tratamiento del tráfico. En varios mercados europeos y de Oriente Medio, los sender IDs alfanuméricos se preregistran por operador, con requisitos distintos según operador y proveedor.
- Cambiar una identidad de remitente depende de terceros: es un proyecto, no un cambio de configuración. Confirma el plazo actual con el proveedor y el operador del mercado.
- Añadir un segundo proveedor para failover suele implicar repetir el trabajo de registro.
- Mantén un registro de identidades por mercado con estado, proveedor titular y evidencia usada.
Aísla las clases de tráfico
Códigos de autenticación, avisos de servicio y campañas promocionales tienen plazos, consentimiento y revisión de contenido distintos. Sepáralos en cuatro niveles: identidad de remitente y registro, ruta, cola y prioridad, y línea base de monitorización con su alerta.
Mapea DLR y errores a tu propio vocabulario
Un DLR describe lo que reportó la red, no lo que hizo la persona. Define estados canónicos (aceptado, enviado, entregado, fallido, expirado, desconocido), razones de fallo agrupadas por quién puede actuar, y conserva el código bruto del proveedor. Registra qué estados no consideras fiables en cada ruta.
Monitoriza por ruta, destino y clase
Los porcentajes agregados esconden el fallo relevante, que casi siempre es específico. Usa líneas base por programa y ruta a partir de su propio histórico, distribuciones de latencia en lugar de medias, y canarios en vivo sobre rutas y mercados significativos. Cada alerta necesita responsable y acción definida.
Reintentos, idempotencia y plazos
- Referencia generada por tu aplicación en cada envío, guardada antes de enviar; envío idempotente contra esa referencia.
- Un plazo útil por clase de tráfico: pasado ese punto, detener en lugar de reintentar.
- Un reintento o failover nunca debe generar un segundo código para la misma sesión: deduplica a nivel de estado.
Mide el resultado en la aplicación
El resultado vive en tu aplicación: verificación, clic, respuesta, pago. Únelo a los envíos y estados con un identificador de correlación. Dos rutas con entrega reportada similar pueden dar tasas de verificación distintas.
Suministro y operación son decisiones separadas
Flowstates vende y opera rutas de mensajería, admite que el cliente mantenga sus propios contratos (BYOV) y admite modelos híbridos. La capa operativa —registros, enrutamiento, mapeo canónico, monitorización, escalado y reporting— es el mismo trabajo en cualquiera de los casos.
Checklist operativo
- Registro de identidades de remitente por mercado.
- Clases de tráfico separadas en identidad, ruta, prioridad de cola y alertas.
- Mapeo canónico de estados y errores, conservando códigos brutos.
- Líneas base por ruta, destino y clase, del propio histórico del programa.
- Canarios en vivo en rutas y mercados significativos.
- Referencia de aplicación en cada envío, guardada antes de enviar.
- Plazo útil por clase, con condiciones de parada.
- Deduplicación a nivel de estado en reintentos y failover.
- Un identificador que une envíos, estados y resultados de aplicación.
- Responsable y acción definidos para cada alerta.