
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_idque identifica qual nó do grafo do fluxo gerou o relatório (somente sessões V3).
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.
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,RetryouBlocked;reasonénull, a menos que o envio tenha sido bloqueado (invalid_phone_number,repeated_attempts,suspicious,spam,unknown);channelé o canal solicitado eactual_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 }comstatusdeliveredouundeliverable. - Eventos de checagem (
VALID_CODE_ENTERED,INVALID_CODE_ENTERED):{ code_tried, status }comstatusApproved,Declined,FailedouExpired or Not Found. - Eventos de status final:
null, excetoPHONE_VERIFICATION_DECLINED/PHONE_VERIFICATION_IN_REVIEW, que trazem{ "reason": "<risk code>" }(por exemplo,PHONE_NUMBER_IN_BLOCKLIST).
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
- Visão geral da Verificação de telefone: comportamento do recurso, preços e canais compatíveis.
- Avisos da Verificação de telefone: todos os códigos de risco, gatilhos de recusa e ações configuráveis.
- Modelos de dados: verificação de telefone: schema canônico, campo a campo.
- API de telefone independente: endpoints
POST /v3/phone/send/ePOST /v3/phone/check/. - Management API: listas: gerencie a lista de bloqueio de números de telefone que alimenta
matches[]comsource: list_entry.