Saltar para o conteúdo principal
O relatório de Verificação de e-mail regista 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 consta de violações de dados conhecidas, quantas tentativas o utilizador realizou e quaisquer correspondências entre sessões com a sua lista de bloqueio ou outros utilizadores aprovados. Esta página documenta a estrutura JSON devolvida pelo endpoint de decisão para que possa analisar resultados de OTP, exposição a violações de dados e sinalizadores de risco para cada endereço verificado.
Relatório de verificação de e-mail da Didit a mostrar o resultado do OTP, dados de violações e sinalizadores de risco

Visão geral

É gerado um relatório de e-mail sempre que um nó do fluxo executa a funcionalidade Verificação de e-mail. Cada relatório representa um desafio OTP para um endereço e contém:
  • O endereço de email verificado.
  • Sinalizadores de risco booleanos (is_breached, is_disposable, is_undeliverable) e o array de suporte breaches[] obtido a partir de uma base de dados de inteligência sobre violações de dados.
  • A contagem de tentativas de envio de OTP (verification_attempts) e o timestamp de aprovação.
  • Um registo cronológico lifecycle[] de cada tentativa de envio, nova tentativa e verificação de código.
  • Um array matches[] que identifica o mesmo endereço noutras 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 de Verificação de e-mail).
  • Um node_id que identifica qual nó do grafo do fluxo gerou o relatório (apenas em sessões V3).
Em sessões de fluxo alojadas, o desafio OTP é executado dentro da interface de verificação da Didit — apenas precisa de ler o resultado a partir do payload de decisão. Para OTP de servidor para servidor sem um fluxo alojado, utilize a API de e-mail autónoma: POST /v3/email/send/ entrega o código e POST /v3/email/check/ valida a introdução do código pelo utilizador; as verificações autónomas finalizadas são apresentadas através da mesma estrutura de relatório. As sessões alojadas limitam o utilizador a 2 introduções de código erradas (email_max_check_attempts) e a 2 envios de OTP — o envio inicial mais um reenvio (email_max_retries) por predefinição, configuráveis por nó do fluxo. Exceder qualquer um dos limites finaliza o passo como Declined com EMAIL_CODE_ATTEMPTS_EXCEEDED.

Onde surge nas respostas da API

O endpoint de decisão (GET /v3/session/{sessionId}/decision/) devolve relatórios de e-mail com a chave de array no plural email_verifications. O array contém uma entrada por cada nó de Verificação de e-mail no grafo do fluxo — tipicamente uma, mas fluxos de escalamento podem gerar várias.
Um valor null significa que nenhum passo de Verificação de e-mail foi ainda executado. Itere sobre o array (em vez de ler email_verifications[0]) quando o seu fluxo puder recolher mais do que um endereço de e-mail.

Esquema

O esquema canónico campo a campo encontra-se na página Modelos de dados.
Um endereço não entregável — sintaxe inválida, domínio inexistente, registos MX em falta ou falha na entrega do OTP — finaliza o passo como Declined com o aviso de recusa automática UNDELIVERABLE_EMAIL_DETECTED. A única exceção: quando o utilizador introduziu ele próprio o endereço (não foi pré-preenchido na criação da sessão), um envio que não possa ser entregue devolve um erro em linha para que possa tentar novamente com um endereço diferente em vez de ser recusado de imediato.

Valores de estado

Tipos de eventos do ciclo de vida

lifecycle[] está ordenado cronologicamente. Cada evento tem type, timestamp, details e uma fee faturável (quando aplicável): O payload details depende da família de eventos:
  • 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 Approved, Failed, Expired or Not Found ou Declined.
  • Eventos de estado final — null, exceto EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW, que contêm { "reason": "<risk code>" } (por exemplo, UNDELIVERABLE_EMAIL_DETECTED).
Envios com status Success ou Undeliverable registam a taxa de $0.02 de Verificação de e-mail; envios de Retry, eventos de verificação e eventos de estado contêm sempre fee: 0.

Correspondências entre sessões

matches[] regista o mesmo endereço em verificações de e-mail anteriormente aprovadas na mesma aplicação — entre sessões de KYC, KYB e API autónoma — além de correspondências na lista de bloqueio configuradas nas listas da API de gestão. As verificações que partilham o vendor_data da sessão atual são excluídas (o mesmo utilizador final não corresponde a si próprio), o array está 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á na lista de bloqueio, uma entrada sintética com source: "list_entry" (todos os campos da sessão null) é acrescentada no início do array.

Exemplos

Aprovada — OTP limpo com uma infração informativa

Recusada — endereço não entregável

Um endereço pré-preenchido que falhe a validação de sintaxe ou de DNS (MX) — ou cujo e-mail com o OTP não possa ser entregue — finaliza imediatamente como Declined. Não surgem eventos de verificação de código, uma vez que nenhum código chegou ao utilizador.

Recusada — caixa de correio descartável na lista de bloqueio

O utilizador concluiu a verificação por OTP, mas o endereço foi encontrado na sua lista de bloqueio de e-mails (recusa automática). O sinalizador de e-mail descartável também é ativado — neste caso ao nível de information, uma vez que disposable_email_action foi mantido no seu valor predefinido NO_ACTION.

Conteúdo relacionado

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