API de Verificación por SMS para Devs: Prueba OTP en Todo el Mundo

Una API de verificación por SMS le da a tu código lo que el equipo de QA siempre hizo a mano: pedir un número de teléfono real en un país, pasarlo al flujo bajo prueba, esperar el código de un solo uso y cerrar. TempSMS expone exactamente ese ciclo por HTTP, cobrado por código que llega, con un servidor simulado para que construyas la integración antes de gastar un centavo.

Para qué sirve realmente una API de verificación por SMS

Los equipos recurren a una API de verificación por tres razones legítimas, y todas tienen que ver con probar sistemas propios.

Probar registro y OTP en muchos países

Tu onboarding funciona en la oficina. ¿Funciona con un número colombiano, donde algunos operadores retrasan los códigos cortos? ¿Con un número argentino prepago? Una API de verificación permite que una prueba de extremo a extremo pida un número en cada país objetivo y compruebe que tu OTP llega, en cuánto tiempo y con el texto correcto.

Automatizar la creación de cuentas para pruebas legítimas

Staging, pruebas de carga, suites de regresión: todo consume cuentas, y un cajón lleno de SIM no escala. Con la API, la prueba crea el pedido, lee el número, completa tu registro, lee el código y limpia todo.

Monitorear que tu propio OTP llega desde el exterior

El bug de OTP más caro es el silencioso: tu proveedor falla en un país y solo te enteras por los tickets de soporte. Un job programado que pide un número en cada país clave, dispara tu OTP y alerta cuando el código se retrasa o no llega es el monitoreo más barato que vas a construir.

Cómo funciona el flujo

La API refleja lo que una persona hace en el panel. Cada paso es una llamada HTTP simple con cuerpo JSON y la clave de API en la cabecera.

1. Crea un pedido. Envía la app que verificas (o un servicio genérico "otro"), el país y, opcionalmente, un servidor preferido. La respuesta incluye el ID del pedido, el número en formato internacional y el precio que se cobrará si llega un código.
2. Usa el número. Tu prueba pega el número en el flujo bajo prueba y dispara el envío del OTP.
3. Consulta hasta que llegue el código. Pide el pedido por su ID hasta que el estado cambie de esperando a recibido. La respuesta trae entonces el texto completo del SMS y el código extraído. Consulta cada pocos segundos; los códigos suelen aparecer mucho antes de un minuto.
4. Finaliza o cancela. Con el código en mano, marca el pedido como finalizado para liberar el número. Si nunca llegó ningún SMS, cancela el pedido y no se cobra nada.

Además de esas cuatro operaciones, la API permite listar apps y países disponibles, listar los servidores de una combinación app y país con su etiqueta de entrega actual, consultar tu saldo y obtener el historial de pedidos. Los formatos completos de petición y respuesta, códigos de error y límites están en la documentación de la API.

Pago por código, no por intento

El precio sigue exactamente la regla del panel: solo pagas por un código que llega. Un pedido cancelado no cuesta nada, y un pedido que expira sin SMS se reembolsa automáticamente. Los precios son céntimos por código en la mayoría de apps y varían por app y país; la respuesta de creación del pedido siempre te dice el precio antes de que uses el número en una prueba.

Así puedes correr la matriz de países cada noche: las únicas líneas de costo son las entregas exitosas, justo lo que quieres medir.

Sandbox con servidor simulado

Antes de apuntar nada a producción, usa el sandbox. Es un servidor simulado que implementa los mismos endpoints y formatos de respuesta, devuelve números ficticios y "entrega" un código tras un retraso corto y configurable. No se cobra nada y nada toca operadores reales.

Úsalo para:

• Escribir y probar tu lógica de consulta, timeouts y reintentos.
• Simular la ruta sin SMS y asegurarte de que la prueba cancela limpiamente.
• Ejecutar la integración en CI en cada commit sin gastar crédito.
• Incorporar gente nueva al equipo sin repartir una clave con saldo.

Cuando la integración esté en verde en el sandbox, cambia la URL base y la clave, y el mismo código corre contra números reales.

Elegir servidores por código

Igual que en el panel, cada combinación app y país puede ser atendida por varios servidores independientes, y cada uno expone una etiqueta de entrega. Para verificar una plataforma estricta como WhatsApp o Google, lee primero la lista de servidores y elige la etiqueta más alta: las grandes redes rechazan muchos rangos VoIP, y la etiqueta señala que una ruta está pasando ahora. Para probar tu propio OTP, cualquier servidor vale: el número solo necesita recibir SMS.

Uso ético y para qué no sirve la API

Una API de verificación por SMS es una herramienta de pruebas. Los términos son simples y se aplican:

• Nada de spam. No uses números para enviar mensajes no solicitados ni para registrar cuentas que los enviarán.
• Nada de cuentas falsas masivas. Crear grandes cantidades de cuentas en una plataforma de terceros para manipularla, venderlas o evadir bloqueos está prohibido y termina con la clave revocada.
• Nada de acoso ni evasión. No uses números temporales para saltarte un bloqueo que alguien te puso.
• Respeta los términos de la plataforma. El servicio donde te registras tiene sus propias reglas; un número temporal no las cambia.

Usos legítimos: probar tu producto, QA entre países, monitoreo, investigación con consentimiento y privacidad personal. Si dudas, pregunta antes de construir.

Cómo empezar

1. Crea una cuenta en TempSMS y confirma tu correo.
2. Genera una clave de API desde el panel, y una clave separada de sandbox.
3. Lee la documentación y ejecuta el flujo en el sandbox: crear, consultar, finalizar.
4. Añade un poco de crédito, cambia a la clave de producción y ejecuta un pedido real en un país que puedas verificar a mano.
5. Conéctalo a CI o a tu programador de monitoreo.

Para elegir país y servidor cuando el objetivo es una app de terceros, consulta cómo elegir un servicio de verificación por SMS y VoIP vs no VoIP.

Preguntas frecuentes

¿Qué tan rápido aparece el código?

La mayoría de códigos llegan segundos después de que la plataforma remitente envía el SMS, y el estado del pedido se actualiza en cuanto el mensaje toca el número. Diseña tu poller con un timeout de uno a dos minutos y un intervalo de pocos segundos. Si no llega nada al vencer el timeout, cancela el pedido y no se cobra.

¿Puedo usar el mismo número en varias pruebas?

Una activación estándar es de un solo uso y se libera al finalizar el pedido. Para escenarios que necesitan un número estable durante días, por ejemplo probar reinicio de sesión o recuperación de cuenta, la API soporta alquileres más largos. Revisa en la documentación los endpoints de alquiler y su modelo de precio.

¿El sandbox se comporta igual que producción?

Implementa los mismos endpoints, formatos de respuesta y códigos de error, y simula la entrega del código y la ruta sin SMS. No simula la variabilidad real (retrasos de operador, plataformas que rechazan un tipo de número), así que ejecuta algunos pedidos reales antes de confiar en una matriz de países.

¿Cuáles son los límites de peticiones?

Los límites se fijan por clave y son suficientes para CI y monitoreo. Están documentados en la página de docs junto con el error exacto que recibes al superarlos, para que tu código retroceda correctamente.

¿Hay webhook en lugar de consulta?

La consulta es la base y funciona en todas partes. Donde hay callbacks disponibles, están descritos en la documentación, pero diseña la integración con la consulta como respaldo; un callback que nunca se dispara no debe dejar una prueba colgada.

Empieza a construir con números reales en más de 150 países

Lee la documentación de la API, ejecuta el sandbox y luego explora el catálogo para ver qué apps, países y servidores puedes usar hoy. Solo pagas por códigos que llegan.