API de verificação no cadastro

É uma checagem colocada dentro do cadastro que exige que uma conta nova esteja vinculada a um número de telefone cujo dono consiga provar que possui. É o sinal de identidade mais barato disponível exatamente no momento em que você menos sabe sobre um usuário, e o único que ele não consegue gerar em massa de graça.

A distinção que importa é entre coletar um número e verificar um número. Um formulário que apenas guarda o que foi digitado tem um campo de contato. Um formulário que verifica tem uma restrição — e a economia do abuso funciona em cima de restrições.

Cadastros automatizados são o caso óbvio: um script fabrica endereços de e-mail indefinidamente, mas cada número verificado custa um chip real ou uma conta de WhatsApp real. Só esse fato transforma um ataque gratuito num ataque com preço.

Os casos mais sutis valem mais. Programas de indicação e bônus de boas-vindas só são tão sólidos quanto sua definição de pessoa distinta, e um e-mail não verificado não é uma. Uma caixa descartável atrás de um teste gratuito também não. A verificação no cadastro é o que impede a mesma pessoa de resgatar cinquenta vezes uma oferta para novos usuários.

Coloque a verificação tão cedo quanto ela se pague, e não antes. Verificar antes de o usuário ter visto qualquer valor é a forma mais comum de perdê-lo; verificar depois de ele ter criado conteúdo ou gastado dinheiro obriga a desfazer uma conta já existente.

Um padrão razoável é verificar no fim do cadastro, com a conta já criada mas antes de ela poder agir — publicar, transacionar, convidar ou resgatar qualquer coisa. Se o seu produto tem um modo anônimo genuinamente útil, adie a verificação até a primeira ação que custe algo a você.

Cada etapa adicional perde usuários, e isso é um custo real, não um argumento a descartar. O que você controla é quanta fricção essa etapa carrega. Um fluxo de código clássico pede sair da sua página, encontrar uma mensagem, ler um código, voltar e digitá-lo — quatro oportunidades de desistir, mais uma espera de entrega da operadora que pode nunca se resolver.

Um fluxo Reverse OTP substitui tudo isso por um toque e um envio. O usuário não se afasta por muito tempo, não transcreve nada e não espera a entrega num aparelho que já está na mão dele. A checagem é a mesma; as formas de falhar são bem menos.

Abra uma sessão com POST /start-verification quando o usuário chegar à etapa de verificação, passando seu próprio identificador como session_id para que o resultado volte direto à conta pendente. Exiba o deep link do WhatsApp devolvido como QR code no desktop ou como botão no celular.

Depois espere o callback, ou leia GET /check-verification-status quando o usuário voltar à aba. Marque a conta como verificada apenas se o status for verified — e guarde o número que a API devolve, não o que o usuário digitou, porque eles podem legitimamente diferir.

Sessões expiram: faça de reiniciar uma ação visível e banal, não um estado de erro. Usuários sem WhatsApp precisam da alternativa por SMS apresentada com clareza, não como último recurso escondido. E números compartilhados ou reciclados existem: decida deliberadamente se um número pode estar ligado a mais de uma conta, porque o padrão que você escolher vira política silenciosamente.

Por fim, trate a verificação como reutilizável. Uma vez provado um número no cadastro, a mesma prova pode sustentar a recuperação de conta e checagens reforçadas depois, sem um novo cadastro do fator.