WA Lookup
Um fluxo abstrato de verificação de números de telefone que termina em um resultado confirmado
Uma requisição síncrona fornece ao fluxo de trabalho um sinal atual antes da próxima decisão.

Use um sinal atual no ponto em que a decisão acontece

A qualificação de leads costuma ser tratada como uma etapa de limpeza posterior. Isso é útil em alguns fluxos, mas não é o único momento em que um sinal de registro importa. Um envio de formulário, uma solicitação de suporte ou uma atualização do CRM pode precisar de uma resposta antes que a próxima regra seja executada.

O WA Lookup fornece essa resposta por meio de uma API síncrona. Quem faz a chamada pode enviar um número de telefone ou uma verificação múltipla de até 100 números e recebe os resultados do WhatsApp selecionados na mesma resposta HTTP. Isso torna a resposta adequada para um fluxo que precisa decidir agora se vai enriquecer registros, escolher uma fila ou solicitar mais informações.

O resultado é propositalmente restrito. Ele informa os campos documentados para o produto selecionado no momento da verificação. Ele não identifica a pessoa por trás de um número, não comprova consentimento, não revela status online nem histórico de mensagens e não garante a alcançabilidade futura.

Escolha o menor sinal que responda à pergunta do fluxo

Todas as verificações do WA Lookup usam o mesmo formato de requisição; o service_type define os campos da resposta.

Tipo de serviço Resultado a usar Exemplo de decisão no fluxo
ws registered Seguir com uma regra de roteamento de leads somente depois de registrar o sinal de registro atual.
ws_avatar registered, avatar, avatar_url Acrescentar os campos documentados de disponibilidade de perfil a um fluxo de revisão do CRM.
ws_business registered, business Encaminhar um registro para uma trilha de revisão B2B quando essa distinção for útil.

Use o produto mais barato que responda à pergunta imediata. Um campo de avatar ou Business acrescenta contexto; ele não torna o resultado de registro mais confiável.

Envie uma requisição clara e use o contrato de resposta

Normalize o identificador antes de chamar a API. O E.164 dá a um número internacional uma forma clara, com código do país, e evita tratar um número local ambíguo como se estivesse completo em escala global.

curl -X POST "https://walookup.com/api/v1/check" \
  -H "X-API-Key: sk_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"service_type":"ws","identifier":"+17253100591"}'

Um resultado de registro concluído é retornado no envelope de resposta documentado:

{
  "code": 0,
  "msg": "ok",
  "data": {
    "service_type": "ws",
    "identifier": "+17253100591",
    "registered": true
  }
}

Use data.registered somente depois de um resultado concluído. Uma requisição inválida, uma resposta de saldo insuficiente, uma rejeição por concorrência, um tempo limite excedido ou uma verificação indeterminada não são evidência de que o número não está registrado. Mantenha esse resultado operacional separado da observação de registro e siga o caminho documentado de nova tentativa ou correção.

Armazene uma observação, não uma afirmação de identidade

Um registro útil no CRM preserva o que foi enviado, o que foi verificado e quando o resultado foi observado. Isso torna as atualizações posteriores explicáveis, em vez de substituir silenciosamente um valor mais antigo.

  • Armazene o valor de origem e o identificador E.164 normalizado separadamente.
  • Armazene o service_type selecionado junto com os campos retornados.
  • Registre o horário da verificação junto com o resultado concluído.
  • Mantenha os erros de requisição e os resultados indeterminados separados de registered=false.
  • Verifique novamente quando um fluxo posterior precisar de uma observação mais recente.

Revise o saldo e o histórico de verificações no painel; consulte a página de preços e a documentação da API para conhecer as regras de cobrança atuais.

Uma regra de roteamento simples

A regra segura é direta: ramifique o fluxo somente com base em uma resposta concluída e trate os campos como entradas atuais do fluxo, e não como verdade permanente. Por exemplo, um CRM pode salvar registered=true com o horário e o tipo de serviço, enquanto uma falha temporária continua passível de nova tentativa e não sobrescreve uma observação concluída anterior.

É aí que a verificação síncrona é mais útil: ela dá ao fluxo de trabalho uma resposta estruturada no ponto em que uma decisão está de fato sendo tomada.

Fontes