Checklist de puesta en producción para conexiones SMS A2P HTTP y SMPP

Qué significa estar listo para producción

Una conexión HTTP o SMPP operativa solo confirma que existe algún nivel de comunicación con el sistema remoto. No demuestra que el proveedor haya aceptado cada mensaje, que se haya recibido un informe de entrega ni que el SMS haya llegado al dispositivo.

Conviene separar la aceptación de la conexión, la aceptación de cada envío y la evidencia de entrega. Definan qué resultado esperan observar en cada etapa y qué fuente lo proporciona. Un DLR es un informe recibido; por sí solo no equivale a una verificación independiente en el teléfono.

Antes de abrir tráfico, acuerden el alcance: destinos, remitentes, tipos de mensaje, volúmenes previstos, horarios, responsables y condiciones de autorización y cumplimiento aplicables. La aceptación técnica no sustituye la revisión de permisos, consentimiento ni reglas locales.

• Documentar qué se considera una prueba de conectividad correcta y qué constituye una prueba de entrega.
• Acordar con la contraparte los parámetros de integración y los resultados esperados; no asumir valores que no estén documentados.
• Dejar fuera del criterio de aceptación cualquier garantía de entrega que no esté respaldada por evidencia y condiciones acordadas.

Preparar el entorno y separar la prueba del tráfico real

Mantengan diferenciados los entornos, credenciales, destinos y remitentes de prueba y producción en la medida que la arquitectura y el proveedor lo permitan. Si no existe una separación técnica completa, documenten las salvaguardas para evitar que una prueba alcance destinatarios reales.

Guarden las credenciales en mecanismos de acceso restringido y eviten incluirlas en registros, tickets o ejemplos compartidos. Asignen permisos solo a quienes los necesitan y definan cómo actuar si una credencial queda expuesta.

Usen únicamente destinos y contenidos autorizados para las pruebas. Antes de enviar, comprueben el alcance y la aprobación del tráfico, especialmente si se trata de mensajes de marketing, OTP o comunicaciones transaccionales.

• Inventariar credenciales, hosts, puertos, remitentes, destinos y responsables de cada entorno.
• Comprobar que los mensajes de prueba estén identificados y no se mezclen con los informes de tráfico productivo.
• Establecer quién puede habilitar tráfico y quién puede detenerlo.

Validar la integración HTTP

Verifiquen la autenticación y el transporte según la documentación acordada con el proveedor. Confirmen que la aplicación reconoce la diferencia entre una respuesta HTTP y el resultado operativo del mensaje: recibir una respuesta no basta para concluir que hubo entrega.

Definan tiempos de espera para la conexión y la respuesta de acuerdo con la implementación y el contrato técnico. Si vence el tiempo de espera, el resultado puede ser incierto: el sistema remoto podría haber procesado la solicitud aunque la aplicación no recibiera la respuesta. No reenvíen automáticamente sin una política que contemple duplicados e idempotencia.

Clasifiquen los errores según la respuesta documentada por la contraparte. Distingan fallos que pueden resolverse corrigiendo la solicitud o la configuración de aquellos que podrían ser transitorios. La evidencia disponible no fija códigos, reintentos ni una semántica universal para las API SMS: acuerden esos comportamientos antes de producir tráfico.

Si se contemplan reintentos, definan límites, pausas y condiciones de parada. Asegúrense de que un reintento no multiplique envíos ante una respuesta ambigua y de que el mecanismo de deduplicación, si existe, esté descrito y probado.

• Probar credenciales válidas e inválidas sin exponer secretos en los registros.
• Verificar respuestas de éxito y error con ejemplos documentados por el proveedor.
• Simular timeouts y confirmar cómo se identifica una solicitud cuyo resultado es incierto.
• Probar la política de reintentos y el tratamiento de duplicados antes de habilitar reenvíos automáticos.

Validar la sesión SMPP

SMPP v3.4 es una especificación pertinente para este tipo de conexión, pero los valores operativos concretos deben acordarse con la contraparte. Antes de abrir tráfico, confirmen los parámetros de conexión y la configuración de la sesión que realmente aplican a su enlace.

Comprueben que el tipo de bind y los parámetros de sesión correspondan al uso acordado. Definan cómo se detectan las sesiones inactivas, cómo se supervisa su estado y cómo se gestiona una desconexión o un cierre controlado. No presupongan intervalos, valores de ventana ni respuestas: deben proceder de la especificación aplicable y del acuerdo técnico.

Aseguren que la aplicación pueda distinguir una sesión conectada de una sesión apta para transmitir dentro de los límites acordados. Prueben la recuperación tras pérdida de conexión sin asumir que los mensajes pendientes quedaron procesados o descartados.

• Validar los parámetros de conexión y credenciales con la contraparte.
• Acordar el comportamiento de bind, comprobación de actividad y cierre de sesión.
• Confirmar cómo se reconcilian los envíos pendientes tras una desconexión.
• Registrar los errores de protocolo y su correlación con la sesión afectada.

Acordar límites, colas y control de presión

No deduzcan la capacidad de una conexión por el hecho de que acepte mensajes de prueba. Antes de activar tráfico, obtengan los límites aplicables —por ejemplo, la tasa de envío o concurrencia permitida— de la contraparte y de la configuración contratada. No hay un TPS universal que pueda recomendarse sin esos datos.

Definan cómo se comportan las colas cuando la aplicación produce mensajes más rápido de lo que puede procesarlos la integración. Establezcan cuándo se ralentiza el emisor, cuándo se deja de aceptar trabajo y cómo se evita que una ráfaga convierta un problema temporal en una acumulación difícil de recuperar.

Prueben gradualmente y dentro de los límites acordados. Si no hay autorización para una prueba de carga, no la realicen: soliciten primero un plan y condiciones expresas.

• Registrar los límites acordados y dónde se aplican: aplicación, conexión o proveedor.
• Definir umbrales para ralentizar o detener la producción de mensajes.
• Comprobar el comportamiento de la cola y la recuperación tras una interrupción.
• Evitar pruebas de carga no autorizadas o basadas en límites supuestos.

Trazabilidad, estados y DLR

Cada mensaje debería poder seguirse desde la solicitud original hasta las respuestas y actualizaciones recibidas. Definan qué identificador conserva cada sistema y cómo se relacionan el identificador interno, la referencia devuelta por la plataforma y los eventos posteriores.

Registren marcas temporales y estados con suficiente contexto para investigar incidencias. Limiten los datos personales y el contenido almacenado a lo necesario, protejan los registros y establezcan quién puede consultarlos y durante cuánto tiempo, de acuerdo con sus obligaciones aplicables.

Si reciben callbacks o DLR, prueben cómo se autentican, correlacionan y procesan, incluidos eventos repetidos o tardíos si la interfaz los contempla. Un DLR recibido debe presentarse como el estado informado por la fuente correspondiente; no como prueba independiente de que una persona vio el mensaje o de que llegó a un dispositivo concreto.

• Correlacionar solicitud, respuesta inicial y eventos posteriores mediante identificadores documentados.
• Registrar hora, estado, destino y contexto técnico necesario para el diagnóstico.
• Probar callbacks y DLR según el comportamiento documentado, sin atribuirles más certeza de la que ofrecen.
• Definir controles de acceso y retención para los registros.

Ejecutar pruebas controladas y evaluar la evidencia

Realicen primero pruebas de transporte y configuración con casos aprobados. Después, si existe autorización y un destino de prueba adecuado, evalúen el ciclo de envío y los informes disponibles. Mantengan separados los resultados de conectividad y los resultados de entrega.

Clasifiquen cada observación: solicitud enviada, aceptación comunicada por la interfaz, DLR recibido y, cuando sea posible, recepción comprobada de forma independiente en un destino controlado. Estas categorías no son intercambiables. Una prueba de pocos mensajes tampoco permite inferir por sí sola el comportamiento de todos los destinos o volúmenes.

Documenten resultados, hora, entorno, parámetros utilizados y limitaciones. Si falta una respuesta o existe discrepancia entre estados, traten el caso como no concluyente hasta que se investigue.

• Aprobar previamente destinos, remitentes y contenido de prueba.
• Comprobar primero la conectividad y luego el flujo de estados del mensaje.
• Conservar evidencia suficiente para reproducir el diagnóstico, sin almacenar secretos.
• No convertir una muestra limitada en una garantía general de entregabilidad.

Alertas, responsables y reversión

Antes del lanzamiento, asignen responsables para integración, operación y contacto con la contraparte. Definan cómo se detectan la pérdida de conectividad, el aumento de errores, la acumulación de colas y las discrepancias de estados, usando señales disponibles en su sistema.

Acuerden criterios explícitos de parada: por ejemplo, fallos que impidan identificar el resultado de los envíos, credenciales expuestas o una desviación respecto de los límites pactados. Los umbrales concretos deben ajustarse a los datos y acuerdos del servicio, no a cifras inventadas.

Preparen una reversión antes de habilitar tráfico: quién puede detener nuevos envíos, cómo se trata la cola pendiente, cómo se informa a los equipos afectados y qué condiciones deben cumplirse para reanudar. Detener la producción de nuevos mensajes no resuelve automáticamente el estado de los ya enviados; esos casos deben reconciliarse.

• Asignar un responsable de guardia y un canal de escalamiento.
• Definir señales observables y umbrales acordados para alertar y parar.
• Probar el procedimiento para detener nuevos envíos y gestionar trabajo pendiente.
• Documentar las condiciones de reanudación y la revisión posterior al incidente.