Entorno de pruebas
Prueba tu integración con una clave test_ sin enviar un solo mensaje. Destinatarios fijos, un código fijo y la misma API que producción.
Qué es el entorno de pruebas
Una clave test_ habla con la misma API que una clave live_, pero nada sale de la plataforma: no se envía ningún WhatsApp, SMS ni correo, y nada se factura. En lugar de un número real usas los destinatarios de abajo, y el código es siempre el mismo.
Todo lo demás funciona como en producción: las respuestas, la cascada de canales, los intentos, el vencimiento, los límites, la Idempotency-Key y los webhooks.
Destinatarios de prueba
Con una clave test_ solo se aceptan estos destinatarios. Cualquier otro responde 400 con 20002 (sandbox_recipient_not_allowed). El mismo código rechaza estos destinatarios cuando la clave es live_.
| Teléfono | Correo | Qué pasa con cada envío |
|---|---|---|
+12025550101 | [email protected] | Se acepta en todos los canales. Unos segundos después el sandbox lo reporta como entregado. |
+12025550102 | [email protected] | Se rechaza en WhatsApp y correo. Se acepta en SMS y luego se reporta como entregado. |
+12025550103 | [email protected] | Falla en todos los canales. |
+12025550104 | [email protected] | Se acepta en todos los canales. Nunca se reporta nada: el envío queda sin confirmar hasta que la verificación expira. |
+12025550105 | — | Se acepta y se reporta como entregado. Su SIM cambió hoy: sirve para probar la protección contra SIM swap. |
+12025550106 | [email protected] | Se acepta en todos los canales y luego se reporta como fallo definitivo: la cascada pasa al siguiente paso de inmediato. |
+12025550107 | [email protected] | Se acepta en todos los canales y luego se reporta como fallo transitorio: la cascada espera el tiempo del canal antes de avanzar. |
Para la verificación, «aceptado» y «rechazado» significan lo mismo que en producción:
- Un envío aceptado espera el tiempo del canal y luego pasa al siguiente paso. A menos que un reporte de entrega diga otra cosa (más abajo), la verificación sigue
pendinghasta que tu usuario comprueba el código o vence. - Un envío rechazado pasa al siguiente paso al instante. Cuando todos los pasos se rechazan, la verificación termina en
failedy el webhookverification.failedtraereason: "cascade_exhausted".
Dos ejemplos con channels: ["whatsapp", "sms"]:
| Destinatario | Qué pasa |
|---|---|
+12025550102 | WhatsApp se rechaza al instante y el paso de SMS se acepta. Al aprobar, channel_used es sms. |
+12025550103 | Los dos pasos fallan y la verificación termina en failed enseguida. |
El código
El entorno de pruebas no sortea un código: es siempre el comienzo de una secuencia fija, cortada a la longitud del código.
| Tipo de código | Secuencia | Con 6 caracteres |
|---|---|---|
numeric | 2345678923 | 234567 |
alphanumeric | ABCDEFGHJK | ABCDEF |
Un código numérico de 4 dígitos es 2345; uno de 8, 23456789. Compruébalo como cualquier otro: el correcto responde approved y uno incorrecto gasta un intento. Una verificación live_ nunca recibe este valor ni lo acepta, así que un código aprendido en pruebas no sirve en producción.
Canales
Con una clave test_ los tres canales están disponibles sin configurar nada: ni plantilla ni remitente de WhatsApp, ni plantilla de correo. La cascada, la espera por canal y los campos channel y channel_used se comportan como en producción.
Lo que el entorno de pruebas no simula:
- El mensaje. Nadie recibe nada: no hay texto que leer.
Cómo llegar a cada estado
Todos los estados que tu integración debe manejar se pueden alcanzar con los destinatarios de arriba y la misma API. Ninguno necesita un número especial fuera de la tabla.
| Quieres ver | Haz esto |
|---|---|
approved | Crea con +12025550101 y comprueba el código fijo. |
| Un código incorrecto | Comprueba cualquier otro código: la verificación sigue pending y gasta un intento. |
max_attempts_reached | Sigue comprobando códigos incorrectos hasta agotar los intentos. |
expired | Crea con "expires_in": 60 y espera un minuto sin comprobar. |
| Salto al siguiente canal | Crea con +12025550102 y channels: ["whatsapp", "sms"]. |
failed (cascade_exhausted) | Crea con +12025550103. |
| Aceptado pero nunca confirmado | Crea con +12025550104 y no compruebes: nunca llega un reporte y queda pending hasta que expira. |
verification.channel.delivered | Crea con +12025550101: el webhook llega unos tres segundos después del envío. |
| Un fallo de entrega tras la aceptación | Crea con +12025550106 (verification.channel.failed, la cascada avanza ya) o +12025550107 (el mismo evento, la cascada espera). |
| Rechazo por SIM swap | Crea con +12025550105 con una aplicación que bloquea cambios recientes. |
| Destinatario no permitido | Usa cualquier otro destinatario: 400 con 20002. |
Separado de producción
El entorno de pruebas y producción son dos mundos separados bajo la misma cuenta.
| En el entorno de pruebas | |
|---|---|
| Verificaciones | Una creada con clave test_ solo se puede comprobar con una clave test_ de la misma aplicación. Con cualquier otra clave responde 404 con 30001, como si no existiera. |
| Límites | Aplican los mismos límites por destinatario y por aplicación, con contadores propios: el tráfico de pruebas nunca consume tu cupo de producción. |
Idempotency-Key | Las claves son por entorno: una clave usada en pruebas queda libre en producción. |
| Webhooks | Un endpoint pertenece a un solo entorno. Los eventos de pruebas solo llegan a endpoints registrados para test, y cada evento dice cuál es en data.environment. |
| Facturación | Nada se factura. Una verificación approved de pruebas nunca produce un evento facturable. |
Pruébalo desde la consola
La consola tiene una pantalla Sandbox que ejecuta estas llamadas contra la API real, para que explores cada parámetro sin escribir código.
- Pega una clave. Pega una clave
test_cada vez: la consola nunca la guarda y solo muestra sus últimos cuatro caracteres. Una clavelive_también sirve, con un aviso de costo y una confirmación en cada envío. - Elige un escenario. Cada destinatario reservado de arriba es una tarjeta que rellena la petición; el formulario de parámetros y el JSON se mantienen sincronizados, y una lista de disparadores de error provoca a propósito los errores documentados.
- Síguela. Tras una llamada, la pantalla sigue la verificación: intentos restantes, tiempo que queda, canal actual, las entregas de webhook (con reenvío para administradores) y si es facturable. Cada intercambio se ve como petición y respuesta crudas o como vista legible, con sus equivalentes en cURL y Node.js.
Pueden usarla administradores y desarrolladores. La pantalla lee a un ritmo limitado y se frena sola cuando llega al límite.
Una prueba completa
# 1. Crear: no se envía nada.
curl https://verify-api.inalambria.com/v1/verifications \
-H "Authorization: Bearer $VERIFY_TEST_API_KEY" \
-H "Idempotency-Key: sandbox-run-1" \
--json '{ "to": "+12025550101", "channels": ["whatsapp", "sms"] }'
# 2. Comprobar el código fijo con el id de la respuesta.
curl https://verify-api.inalambria.com/v1/verifications/ver_01J9XQ4M7K2VBN3P/check \
-H "Authorization: Bearer $VERIFY_TEST_API_KEY" \
--json '{ "code": "234567" }'La segunda llamada responde 200 con status: "approved". Repite la primera con +12025550103 para ver una verificación failed y su webhook.
Updated 4 days ago