¿Puede esta rama OTP local enviar un mensaje real?
Ejecutas el ejemplo de teléfono con la rama otp y obtienes un siguiente paso llamado customer_otp_provider. Es tentador leerlo como «el OTP va en camino» y hacer que la pantalla de registro espere un código. Sería un error: el fixture nombra un siguiente paso, nunca envía un mensaje. Este artículo muestra exactamente qué devuelve la rama otp, cómo tratarla en tu propio código de registro y cómo decidir si una integración sandbox encaja con tu tarea o si necesitas un proveedor OTP separado que estés autorizado a usar.
curl https://gridzen.ai/console/api/quickstart/trial \
-H 'Content-Type: application/json' \
-d '{"task": "signup_phone", "scenario": "success"}'El problema y la decisión
Un pequeño equipo B2B añade un campo de teléfono al registro y quiere confirmar que la persona puede recibir un código. El ejemplo descargable de cuatro ramas del directorio verification_delivery incluye una rama otp, así que parece que OTP está cubierto. No lo está. La guía indica que la entrega de OTP no está soportada aquí, y la ruta telefónica real gratuita actual tampoco solicita tipo de línea, titularidad, alcanzabilidad ni entrega de OTP. Tu decisión no es si confiar en que el fixture envíe códigos, sino qué componente de tu sistema es responsable de la entrega de OTP y cómo se comporta tu código cuando el paso telefónico responde unsupported.
Qué devuelve realmente la rama otp
Ejecutar la tarea phone con la rama otp imprime esta salida probada: mode es synthetic_fixture, branch es otp, otp_sent es false, live_line_type_available es false, state es unsupported, valid es null, line_type es null y next es customer_otp_provider. Cada campo importa. otp_sent false responde directamente a la pregunta del artículo: no se envió nada. state unsupported significa que el fixture rechaza la tarea en lugar de simular éxito. valid y line_type son null, así que tampoco hay evaluación del número en la que apoyarse. next es una etiqueta para que tu código enrute, no una acción que el fixture haya realizado. Los mismos otp_sent false y live_line_type_available false aparecen en todas las ramas, incluida normal, que devuelve un line_type mobile simulado solo dentro del fixture.
Un escenario hipotético desarrollado
Hipotéticamente, imagina un equipo cuyo manejador de registro llama al paso telefónico y luego muestra una pantalla de «introduce el código que enviamos». En su prueba, el paso devuelve state unsupported y next customer_otp_provider. Un diseño de aplicación propuesto: el manejador comprueba otp_sent antes de mostrar cualquier pantalla de código; como es false, no la muestra. En su lugar enruta según next y entrega el número a la integración OTP propia del equipo, que deben configurar por separado y estar autorizados a usar. Si aún no existe ese proveedor, el manejador marca el registro como pendiente de comprobación de canal y deja la creación de la cuenta a la política existente del equipo. Este diseño lo escribirías tú; el fixture solo aporta los campos devueltos.
Manejo de fallos que corresponde a tu código
Trata cada rama de forma distinta. normal devuelve state simulated, valid true, line_type mobile y next continue_customer_policy: continúa con tus propias reglas, sin inferir titularidad ni alcanzabilidad. unknown devuelve state unknown con valid y line_type null y next review_or_existing_otp: envía a revisión o a un flujo OTP que ya operes. provider_failure también devuelve state unknown pero next bounded_retry_then_review: reintenta un número limitado de veces y luego revisa, en lugar de rechazar. otp devuelve unsupported: no esperes un código. Una rama no reconocida lanza UNSUPPORTED_FIXTURE; muéstralo como error de configuración, no como fallo del usuario. Nunca permitas que un campo null se convierta en true por defecto.
Qué está implementado y qué es propuesta
Implementado en el fixture: una función Python sin dependencias que devuelve los cuatro resultados de rama anteriores sin llamadas de red ni credenciales, más pruebas. No implementado: envío de SMS u otro mensaje, adaptadores de proveedor, tipo de línea real y comprobaciones de titularidad. La prueba HTTP sin cuenta es algo distinto de esta descarga de cuatro ramas y no debe describirse como tal. Los resultados sintéticos no son aprobación de producción, y la ruta telefónica real gratuita disponible para empresas elegibles tampoco entrega OTP. Los límites de reintento, las colas de revisión y la elección del proveedor OTP son responsabilidad de tu aplicación.
Lista de aceptación
Antes de publicar: ejecuta la tarea phone con la rama otp y confirma otp_sent false, state unsupported y next customer_otp_provider. Confirma que no aparece pantalla de código cuando otp_sent es false. Confirma que tu manejador enruta según next en las cuatro ramas y registra UNSUPPORTED_FIXTURE por separado. Confirma que valid y line_type null nunca se convierten en aprobado. Confirma que los reintentos de provider_failure están acotados. Confirma que la entrega OTP está conectada a un proveedor que estás autorizado por separado a usar, y que las pruebas contra el fixture nunca se presentan como prueba de que se envían mensajes reales. Después decide si una solicitud sandbox guardada encaja con tu tarea.
Ejecutar el ejemplo sintético comprobado
Descargue y extraiga https://gridzen.ai/downloads/verification-delivery.zip, entre en verification_delivery y ejecute con Python 3.10+. El ejemplo local no hace llamadas de red. Use una base nueva para otra prueba de identidad.
python3 delivery.py phone --branch unknown
python3 delivery.py phone --branch provider_failureFuentes y alcance
https://gridzen.ai/guides/phone-otp-identity/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.
Probar por separado tres resultados del sandbox Crear una cuenta para continuar la integración
Una descarga no demuestra una ejecución correcta. Los ejemplos locales y el sandbox en línea se prueban por separado.