Pular para o conteúdo principal
O relatório de Verificação de e-mail registra o resultado completo de um desafio OTP por e-mail: para quem a mensagem foi enviada, se o endereço é descartável ou não entregável, se ele aparece em vazamentos de dados conhecidos, quantas tentativas o usuário fez e quaisquer correspondências com a sua lista de bloqueio ou com outros usuários aprovados em diferentes sessões. Esta página documenta o formato JSON retornado pelo endpoint de decisão, para que você possa interpretar os resultados do OTP, a exposição a vazamentos e os indicadores de risco de cada endereço verificado.
Relatório de verificação de e-mail da Didit mostrando o resultado do OTP, dados de vazamentos e indicadores de risco

Visão geral

Um relatório de e-mail é gerado sempre que um nó do fluxo de verificação (workflow) executa o recurso de Verificação de e-mail. Cada relatório representa um desafio OTP para um endereço e contém:
  • O endereço email verificado.
  • Indicadores de risco booleanos (is_breached, is_disposable, is_undeliverable) e o array breaches[] de apoio, obtido de um banco de dados de inteligência sobre vazamentos.
  • O número de tentativas de envio do OTP (verification_attempts) e a data e hora da aprovação.
  • Um registro cronológico lifecycle[] de cada envio, nova tentativa e tentativa de verificação do código.
  • Um array matches[] que mostra o mesmo endereço em outras verificações de e-mail aprovadas ou na sua lista de bloqueio.
  • Um array warnings[]: eventos de risco emitidos durante a verificação (consulte Avisos da Verificação de e-mail).
  • Um node_id que identifica qual nó do grafo do fluxo gerou o relatório (somente sessões V3).
Em sessões de fluxo hospedadas, o desafio OTP é executado dentro da interface de verificação da Didit; você apenas lê o resultado no payload da decisão. Para OTP de servidor para servidor sem um fluxo hospedado, use a API de e-mail independente: POST /v3/email/send/ envia o código e POST /v3/email/check/ valida o código digitado pelo usuário. As verificações independentes finalizadas aparecem no mesmo formato de relatório. Por padrão, as sessões hospedadas limitam o usuário a 2 tentativas incorretas de inserir o código (email_max_check_attempts) e a 2 envios de OTP, o envio inicial mais um reenvio (email_max_retries), e esses limites podem ser ajustados em cada nó do fluxo. Ultrapassar qualquer um dos limites finaliza a etapa como Declined com EMAIL_CODE_ATTEMPTS_EXCEEDED.

Onde aparece nas respostas da API

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

Schema

O schema canônico, campo por campo, está na página Modelos de dados.
Um endereço que não pode receber e-mails (sintaxe inválida, domínio inexistente, registros MX ausentes ou falha no envio do OTP) finaliza a etapa como Declined com o aviso de recusa automática UNDELIVERABLE_EMAIL_DETECTED. A única exceção: quando o próprio usuário digitou o endereço (ele não foi pré-preenchido na criação da sessão), um envio não entregue retorna um erro inline para que ele possa tentar novamente com outro endereço em vez de ser recusado imediatamente.

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 (EMAIL_VERIFICATION_MESSAGE_SENT, EMAIL_VERIFICATION_RETRY_MESSAGE_SENT): { status, reason }. status é Success, Retry ou Undeliverable; reason é null, a menos que o envio tenha falhado (email_can_not_be_delivered, ou unknown para valores legados não reconhecidos).
  • Eventos de verificação (VALID_CODE_ENTERED, INVALID_CODE_ENTERED): { code_tried, status } com status igual a Approved, Failed, Expired or Not Found ou Declined.
  • Eventos de status final: null, exceto EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW, que trazem { "reason": "<risk code>" } (por exemplo, UNDELIVERABLE_EMAIL_DETECTED).
Envios com status Success ou Undeliverable registram a taxa de $0.02 da Verificação de e-mail; envios Retry, eventos de verificação e eventos de status sempre trazem fee: 0.

Correspondências entre sessões

matches[] registra o mesmo endereço em verificações de e-mail aprovadas anteriormente na mesma aplicação (em sessões de KYC, KYB e da API independente), além de ocorrências na lista de bloqueio configurada nas listas da management API. Verificações que compartilham o vendor_data da sessão atual são excluídas (o mesmo usuário final não gera correspondência consigo mesmo), e o array é limitado a 5 entradas, ordenadas da mais antiga para a mais recente. Quando o endereço está na sua lista de bloqueio, mas nenhuma das sessões correspondentes está bloqueada, uma entrada sintética com source: "list_entry" (com todos os campos de sessão null) é adicionada ao início do array.

Exemplos

Aprovado: OTP sem problemas com uma violação informativa

Recusado: endereço não entregável

Um endereço pré-preenchido que falha na validação de sintaxe ou de DNS (MX), ou cujo e-mail com o OTP não pode ser entregue, é finalizado imediatamente como Declined. Não aparecem eventos de verificação de código porque nenhum código chegou ao usuário.

Recusado: caixa de e-mail descartável na lista de bloqueio

O usuário concluiu o OTP, mas o endereço constava na sua lista de bloqueio de e-mails (recusa automática). O e-mail também é sinalizado como descartável, aqui no nível information, porque disposable_email_action permanece no padrão NO_ACTION.

Relacionados

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