¿Este número está en WhatsApp? Lo que una verificación telefónica en el registro puede y no puede decir
Una pregunta pública plantea cómo saber si un número tiene WhatsApp antes de enviar un mensaje mediante la WhatsApp Cloud API. No podemos responder por esa plataforma, no representamos a quien preguntó y nada de lo que sigue cambia el comportamiento de WhatsApp. La decisión adyacente para un equipo B2B pequeño es más acotada: cuando un formulario de registro recoge un número, ¿qué puede concluir su aplicación antes de intentar contactar ese número por cualquier canal? Este artículo ejecuta el ejemplo telefónico sintético verificado de cuatro ramas. Muestra que ninguna de sus salidas demuestra presencia en una app de mensajería, alcanzabilidad ni titularidad, y propone cómo debe enrutar su código cada resultado.
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 que le corresponde
Su equipo quiere enviar mensajes de bienvenida, y alguien propone descartar en el registro los números que no estén en WhatsApp. El diseño tentador llama a una verificación telefónica, interpreta un resultado positivo como "alcanzable por WhatsApp" y toma cualquier otro resultado como motivo para rechazar al usuario. Ese diseño mezcla tres preguntas. ¿El número está bien formado y es válido? ¿Qué tipo de línea podría ser? ¿Entregará una app de mensajería concreta un mensaje a quien lo escribió? Una verificación telefónica responde, como mucho, a las dos primeras. Si un servicio de mensajería entregará un mensaje solo puede saberse a través de ese canal, según sus propias reglas documentadas, y normalmente solo al intentar la entrega. Por tanto, la decisión no es cómo detectar WhatsApp con una verificación telefónica. Es qué debe hacer su flujo de registro con cada resultado y dónde encaja, dentro de ese flujo, un intento de entrega específico del canal. Ese enrutamiento es un diseño de aplicación propuesto. El fixture descrito a continuación solo demuestra las entradas y salidas que ese enrutamiento debe manejar.
Lo que el ejemplo verificado implementa realmente
El ejemplo descargable funciona sin conexión con Python 3.10 o superior, sin credenciales y sin llamadas de red. La tarea phone recibe una única entrada, branch, y devuelve estos campos: mode, branch, state, valid, line_type, next, otp_sent y live_line_type_available. En todas las ramas, mode es synthetic_fixture, otp_sent es false y live_line_type_available es false. No existe ningún campo para WhatsApp ni para otra app de mensajería, ni para alcanzabilidad o titularidad. El valor mobile de line_type en la rama normal es un dato simulado. La ruta gratuita actual de Basic Lookup no solicita el tipo de línea, y tampoco verifica titularidad, alcanzabilidad ni entrega de OTP. Aunque line_type fuera mobile, eso no significaría que el número esté registrado en una app concreta. No confunda este ejemplo de cuatro ramas con la prueba HTTP anónima independiente, que cubre tres escenarios.
Escenario hipotético con salidas esperadas del fixture
Hipótesis: el formulario de registro de un equipo recibe cuatro números, y el desarrollador asigna cada uno a una rama para probar el enrutamiento antes de tocar cualquier servicio real. La rama normal devuelve state simulated, valid true, line_type mobile y next continue_customer_policy. Manejo propuesto: aceptar el número como dato de contacto y dejar que su propia política decida si intentar un mensaje más adelante. No marque al usuario como alcanzable por WhatsApp. La rama unknown devuelve state unknown, valid null, line_type null y next review_or_existing_otp. Manejo propuesto: no rechazar al usuario. Envíe la cuenta a revisión o use un flujo OTP que ya tenga en marcha. La rama provider_failure devuelve state unknown, valid null, line_type null y next bounded_retry_then_review. Manejo propuesto: reintentar un número pequeño y fijo de veces y después enviar la cuenta a revisión. Nunca bloquee el registro de forma indefinida. La rama otp devuelve state unsupported, valid null, line_type null y next customer_otp_provider. Manejo propuesto: delegar en su proveedor de OTP existente. El fixture no envía ningún código y otp_sent sigue en false.
Dónde encaja un intento de entrega por canal
Si el objetivo del negocio es enviar mensajes a los usuarios por una app concreta, trate la entrega como un paso posterior e independiente, regido por la documentación de esa plataforma, sus requisitos de consentimiento y su manejo de respuestas. Registre el resultado de la entrega como un estado propio, por ejemplo intentado, entregado o fallido según lo que informe el canal. Manténgalo separado de los campos de la verificación telefónica. Una entrega fallida no debe convertir valid en false, y un número válido no debe guardarse como "en WhatsApp". Mantener estos estados separados hace que el paso posterior a SMS, correo o revisión sea explícito y comprobable. Esto es una propuesta de diseño. El fixture no implementa ni prueba ningún canal de mensajería.
Manejo de fallos que debe asumir su código
El fixture nombra los siguientes pasos; ejecutarlos le corresponde a quien lo llama. Una rama no reconocida lanza UNSUPPORTED_FIXTURE, y su arnés debe tratarlo como un error de prueba, no como un veredicto sobre el usuario. Un null en valid significa que no hay conclusión, no que el número sea inválido. Limite los reintentos y registre qué rama produjo cada ruta. Las pruebas de ingeniería cubren solo transiciones simuladas y no demuestran éxito en producción. La disponibilidad de la ruta real requiere una confirmación aparte, y los resultados sintéticos nunca otorgan permisos de negocio reales.
Lista de aceptación
Antes de integrar, confirme cada uno de estos puntos. Las cuatro ramas se ejecutan y sus salidas coinciden exactamente con los campos descritos. Ni unknown ni provider_failure provocan un rechazo automático. La rama otp delega en su proveedor, y nada espera un código que el fixture nunca envió. Ningún campo almacenado afirma presencia en una app de mensajería, titularidad ni alcanzabilidad. Los resultados de entrega viven en un estado separado. Los reintentos están limitados y terminan en revisión. Cada registro conserva mode synthetic_fixture hasta que se confirme una ruta real autorizada. Cuando todo esto se cumpla, decida si guardar una solicitud de sandbox para la ruta gratuita de Basic Lookup, teniendo en cuenta que no devuelve el tipo de línea.
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/signup-phone-check/ 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.