
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
emailverificado. - Sinalizadores de risco booleanos (
is_breached,is_disposable,is_undeliverable) e o array de suportebreaches[]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_idque identifica qual nó do grafo do fluxo gerou o relatório (apenas em sessões V3).
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.
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.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,RetryouUndeliverable;reasonénull, a menos que o envio tenha falhado (email_can_not_be_delivered, ouunknownpara valores legados não reconhecidos). - Eventos de verificação (
VALID_CODE_ENTERED,INVALID_CODE_ENTERED) —{ code_tried, status }comstatusApproved,Failed,Expired or Not FoundouDeclined. - Eventos de estado final —
null, excetoEMAIL_VERIFICATION_DECLINED/EMAIL_VERIFICATION_IN_REVIEW, que contêm{ "reason": "<risk code>" }(por exemplo,UNDELIVERABLE_EMAIL_DETECTED).
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 comoDeclined. 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 deinformation, uma vez que disposable_email_action foi mantido no seu valor predefinido NO_ACTION.
Conteúdo relacionado
- Visão geral da Verificação de e-mail — comportamento da funcionalidade e preços.
- Avisos da Verificação de e-mail — todos os códigos de risco, acionadores de recusa e ações configuráveis.
- Modelos de dados — verificação de e-mail — esquema canónico campo a campo.
- API de e-mail — Send OTP e Check OTP — endpoints autónomos de servidor para servidor.
- API de gestão — Listas — faça a gestão da lista de bloqueio de e-mails que alimenta
matches[]comsource: list_entry.