API de verificación en el registro

Es una comprobación situada dentro del registro que exige que una cuenta nueva esté asociada a un número de teléfono cuyo titular pueda demostrar que posee. Es la señal de identidad más barata disponible justo en el momento en que menos sabes de un usuario, y la única que no puede generar en masa gratis.

La distinción que importa es entre recoger un número y verificarlo. Un formulario que solo guarda lo que se escribió tiene un campo de contacto. Un formulario que lo verifica tiene una restricción — y la economía del abuso funciona sobre restricciones.

Los registros automatizados son el caso evidente: un script puede fabricar direcciones de correo indefinidamente, pero cada número verificado cuesta una SIM real o una cuenta de WhatsApp real. Ese solo hecho convierte un ataque gratuito en uno con precio.

Los casos más sutiles valen más. Los programas de referidos y los bonos de bienvenida solo son tan sólidos como su definición de persona distinta, y una dirección de correo sin verificar no lo es. Tampoco lo es un buzón desechable detrás de una prueba gratuita. La verificación en el registro es lo que impide que la misma persona reclame cincuenta veces una oferta para nuevos usuarios.

Coloca la verificación tan pronto como pueda justificar su coste, y no antes. Verificar antes de que el usuario haya visto valor alguno es la forma más común de perderlo; verificar después de que haya creado contenido o gastado dinero obliga a deshacer una cuenta existente.

Un valor por defecto razonable es verificar al final del registro, con la cuenta ya creada pero antes de que pueda actuar: publicar, transaccionar, invitar o reclamar algo. Si tu producto tiene un modo anónimo realmente útil, aplaza la verificación hasta la primera acción que te cueste algo.

Cada paso añadido pierde usuarios, y eso es un coste real, no un argumento que descartar. Lo que controlas es cuánta fricción lleva ese paso. Un flujo de código clásico pide salir de tu página, encontrar un mensaje, leer un código, volver y escribirlo — cuatro oportunidades de abandonar, más una espera de entrega del operador que puede no resolverse.

Un flujo Reverse OTP sustituye todo eso por un toque y un envío. El usuario no se aleja mucho tiempo, no transcribe nada y no espera la entrega a un dispositivo que ya tiene en la mano. La comprobación es la misma; las formas de fallarla son muchas menos.

Abre una sesión con POST /start-verification cuando el usuario llegue al paso de verificación, pasando tu propio identificador como session_id para que el resultado se asocie directamente a la cuenta pendiente. Muestra el enlace profundo de WhatsApp devuelto como código QR en escritorio o como botón en móvil.

Después espera el callback, o consulta GET /check-verification-status cuando el usuario vuelva a la pestaña. Marca la cuenta como verificada solo si el estado es verified — y guarda el número que devuelve la API, no el que escribió el usuario, porque pueden diferir legítimamente.

Las sesiones caducan: haz que reiniciar una sea una acción visible y corriente, no un estado de error. Los usuarios sin WhatsApp necesitan que el respaldo por SMS se presente con claridad, no como un último recurso escondido. Y los números compartidos o reciclados existen: decide deliberadamente si un número puede asociarse a más de una cuenta, porque el valor por defecto que elijas se convierte en política en silencio.

Por último, trata la verificación como reutilizable. Una vez demostrado un número en el registro, la misma prueba puede respaldar la recuperación de cuenta y comprobaciones reforzadas posteriores sin pedir un nuevo registro.