
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
emailverificado. - Indicadores de risco booleanos (
is_breached,is_disposable,is_undeliverable) e o arraybreaches[]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_idque identifica qual nó do grafo do fluxo gerou o relatório (somente sessões V3).
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.
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.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,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 }comstatusigual aApproved,Failed,Expired or Not FoundouDeclined. - Eventos de status final:
null, excetoEMAIL_VERIFICATION_DECLINED/EMAIL_VERIFICATION_IN_REVIEW, que trazem{ "reason": "<risk code>" }(por exemplo,UNDELIVERABLE_EMAIL_DETECTED).
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 comoDeclined. 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ívelinformation, porque disposable_email_action permanece no padrão NO_ACTION.
Relacionados
- Visão geral da Verificação de e-mail: comportamento do recurso e preços.
- Avisos da Verificação de e-mail: todos os códigos de risco, gatilhos de recusa e ações configuráveis.
- Modelos de dados: verificação de e-mail: schema canônico, campo por campo.
- API de e-mail: enviar OTP e verificar OTP: endpoints independentes para comunicação entre servidores.
- Management API: listas: gerencie a lista de bloqueio de e-mails que alimenta
matches[]comsource: list_entry.