Pular para o conteúdo principal
O relatório de Verificação de telefone registra o resultado completo de um desafio de OTP por telefone: para quem enviamos o código, qual operadora e qual canal o processaram, quantas tentativas foram necessárias, se o número é descartável ou VoIP e quaisquer correspondências entre sessões com a sua lista de bloqueio ou com sessões de outros usuários. Esta página documenta a estrutura JSON retornada pelo endpoint de decisão, para que você possa interpretar os resultados de OTP, os metadados da operadora e os indicadores de risco de cada número verificado.
Relatório de verificação de telefone da Didit mostrando o resultado do OTP, os metadados da operadora e os indicadores de risco

Visão geral

Um relatório de telefone é gerado sempre que um nó do fluxo executa o recurso Verificação de telefone. Cada relatório representa um desafio OTP para um número de telefone e contém:
  • O número de telefone dividido em prefixo, número nacional e formato E.164 completo, além do código de país ISO e do nome do país.
  • Metadados da operadora (name, type) obtidos a partir da rede de destino.
  • Indicadores de risco booleanos (is_disposable, is_virtual) derivados da análise do tipo de linha.
  • O canal de entrega efetivamente usado (verification_method) e a quantidade de tentativas de envio do OTP.
  • Um registro cronológico lifecycle[] de cada envio, nova tentativa, evento de entrega e tentativa de verificação do código.
  • Um array matches[] que mostra o mesmo número em outras sessões (qualquer status, em verificações KYC, KYB e verificações avulsas via API) ou na sua lista de bloqueio.
  • Um array warnings[] com os eventos de risco emitidos durante a verificação (consulte Avisos da Verificação de telefone).
  • Um node_id que identifica qual nó do grafo do fluxo gerou o relatório (somente sessões V3).
Nos fluxos de verificação hospedados, a Didit executa a troca do OTP para você. Em integrações diretas via API, o mesmo fluxo é feito com duas chamadas: POST /v3/phone/send/ para enviar o código e POST /v3/phone/check/ para validar o que o usuário digitou. Um OTP pendente é válido por 5 minutos a partir do primeiro envio (novas tentativas não estendem esse prazo). Em sessões de fluxo, por padrão, os usuários têm 2 tentativas de envio do OTP (phone_max_retries) e 2 tentativas de digitação do código (phone_max_check_attempts), ambas ajustáveis por nó do fluxo; esgotar qualquer um desses limites finaliza a etapa como Declined com VERIFICATION_CODE_ATTEMPTS_EXCEEDED. A API avulsa de telefone permite 3 tentativas de digitação do código por verificação.

Onde aparece nas respostas da API

O endpoint de decisão (GET /v3/session/{sessionId}/decision/) retorna os relatórios de verificação de telefone na chave de array no plural phone_verifications. O array contém uma entrada para cada nó de Verificação de telefone no grafo do fluxo. Normalmente há apenas uma, mas fluxos com verificação adicional (step-up) podem gerar várias.
Um valor null significa que nenhuma etapa de Verificação de telefone foi executada ainda. Percorra o array (em vez de ler phone_verifications[0]) quando o seu fluxo puder coletar mais de um número de telefone.

Schema

O schema canônico, campo a campo, está na página Modelos de dados.

Valores de status

Tipos de evento do ciclo de vida

lifecycle[] é ordenado cronologicamente. Cada evento tem type, timestamp, details e uma fee faturável (quando aplicável): O payload de details depende da família do evento:
  • Eventos de envio (PHONE_VERIFICATION_MESSAGE_SENT, PHONE_VERIFICATION_RETRY_MESSAGE_SENT, PHONE_VERIFICATION_BLOCKED): { status, reason, channel, actual_channel }. status é Success, Retry ou Blocked; reason é null, a menos que o envio tenha sido bloqueado (invalid_phone_number, repeated_attempts, suspicious, spam, unknown); channel é o canal solicitado e actual_channel é o canal pelo qual a mensagem foi efetivamente entregue (por exemplo, um envio por WhatsApp que recorreu ao SMS).
  • Eventos de entrega (PHONE_DELIVERY_DELIVERED, PHONE_DELIVERY_UNDELIVERABLE): { channel, status } com status delivered ou undeliverable.
  • Eventos de checagem (VALID_CODE_ENTERED, INVALID_CODE_ENTERED): { code_tried, status } com status Approved, Declined, Failed ou Expired or Not Found.
  • Eventos de status final: null, exceto PHONE_VERIFICATION_DECLINED / PHONE_VERIFICATION_IN_REVIEW, que trazem { "reason": "<risk code>" } (por exemplo, PHONE_NUMBER_IN_BLOCKLIST).
A fee em um evento de envio é o preço total desse envio: o preço da operadora ou do WhatsApp mais a taxa de $0.02 da Didit, ou apenas a taxa de $0.02 da Didit no caso de um código por WhatsApp enviado a partir do seu próprio número do WhatsApp Business. Ela é o preço estimado até que a entrega seja confirmada e, depois disso, o valor efetivamente cobrado. Somente os envios Blocked são garantidamente gratuitos: qualquer outro envio é cobrado quando a verificação é finalizada ou expira, mesmo que a entrega nunca tenha sido confirmada ou que a mensagem não tenha podido ser entregue. Eventos de entrega, de checagem e de status sempre trazem fee: 0.

Correspondências entre sessões

matches[] registra outras sessões na mesma aplicação em que o mesmo número foi visto, em verificações de KYC, KYB e da API independente, independentemente do status delas, além de ocorrências em listas de bloqueio configuradas nas listas da management API. Sessões que compartilham o vendor_data da sessão atual são excluídas (um mesmo usuário final não gera uma correspondência consigo mesmo), e o array é limitado a 5 entradas. Quando o número está na sua lista de bloqueio, mas nenhuma das sessões correspondentes está na lista de bloqueio, uma entrada sintética com source: "list_entry" (com todos os campos de sessão null) é inserida no início do array.

Exemplos

Aprovado: OTP por WhatsApp, operadora móvel

Recusado: número VoIP na lista de bloqueio

O usuário inseriu um OTP válido, mas a finalização encontrou o número na lista de bloqueio da aplicação (recusa automática) e sinalizou o tipo de linha VoIP (voip_number_action mantido em NO_ACTION, por isso é registrado como information). Como nenhuma sessão correspondente está na lista de bloqueio, a ocorrência na lista de bloqueio aparece como uma correspondência sintética list_entry.

Relacionados

Última modificação em 1 de novembro de 2026