Primeiros passos
Integração / SDKs
Verificação de usuários
Verificação de empresas
Monitoramento de transações
Registro de alteraçõesFinalidades da mensagem
No momento, o envio de documentos aceita imagens JPEG, PNG e WebP de até 5 MB.
Aparecem apenas as finalidades aplicáveis ao titular do caso.
No momento, os modelos de e-mail para clientes estão disponíveis em inglês, espanhol e português.
O console usa o mesmo campo de e-mail e o mesmo seletor de idioma do reenvio de sessão.
Destinatários verificados e modelos fixos
O destinatário precisa ter concluído a verificação de e-mail em uma sessão que pertença ao titular do caso e à aplicação. Um endereço importado ou editado em um perfil de usuário não comprova a verificação. Se não houver um contato verificado, o editor de mensagens explica isso e o envio permanece desativado. Os revisores não podem fornecer texto de e-mail, links, endereços de remetente ou destinatários arbitrários. O e-mail usa a identidade visual existente da Didit ou de marca própria. Um remetente personalizado exige que o domínio de e-mail configurado esteja verificado. Todos os modelos informam ao destinatário que o e-mail não solicitará senhas, códigos de verificação nem pagamentos. O reenvio de sessão continua sendo uma ação separada para repetir as verificações. A prévia dele mostra o e-mail de reenvio que será enviado e as verificações selecionadas.Entrega e respostas
O histórico de mensagens diferencia os resultados de entrega na fila, enviando, enviado, simulado e desconhecido. Um e-mail simulado não é enviado. Um resultado desconhecido significa que o provedor pode ter aceitado o e-mail; o sistema não o envia novamente de forma automática. Tentar novamente uma requisição confirmada usa o mesmo ID de requisição para evitar entrega duplicada. Uma requisição que exige ação tem um link de resposta seguro, válido por sete dias. Cancelar a requisição ou resolver o caso invalida esse link, inclusive depois que o caso é reaberto. A página do cliente não revela constatações privadas do caso nem outros registros de origem. Uma resposta enviada aparece em Customer messages como evidência pendente de revisão. O caso volta ao status Aberto, e uma resolução pendente existente precisa ser revisada novamente. As respostas não podem substituir um envio anterior, aprovar a verificação original, sobrescrever a identidade de um cliente nem contribuir para um resultado de fraude. Excluir a verificação ou o caso de origem exclui as requisições ao cliente e as evidências enviadas.Fluxo da API
Todos os endpoints do console têm como escopo uma organização, aplicação e caso:read:cases.
Redigir, gerar a prévia, confirmar, cancelar e enviar lembretes exige write:cases.
A confirmação deve incluir os mesmos contact_id, purpose e language, além de request_id, expires_at e preview_token retornados pela prévia.
O comprovante de confirmação expira após 15 minutos, independentemente do prazo de resposta do cliente.
Um lembrete envia o mesmo e-mail novamente ao mesmo destinatário verificado, no máximo uma vez por requisição a cada 24 horas.
Ele não altera mais nada: a requisição mantém o prazo e o caso mantém o status.
A resposta retorna a requisição, reminded_at, o delivery_status do próprio lembrete (SENT, SIMULATED ou UNKNOWN) e next_reminder_at.
Uma requisição que o cliente não precisa mais responder retorna 409 com code case_request_not_waiting e um reason: answered, cancelled, expired, closed, not_actionable, not_delivered ou contact_unavailable.
Um segundo lembrete dentro de 24 horas retorna 429 com code case_request_reminder_too_soon, um timestamp retry_at e um cabeçalho Retry-After.
Enquanto uma resolução aguarda aprovação, um lembrete retorna 400.
O endpoint destinado ao cliente é GET ou POST /v3/case-requests/{request_uuid}/ com o cabeçalho X-Case-Request-Token específico da requisição.
O link de resposta leva essa credencial no fragmento; a página remove o fragmento ao ser aberta.
O token dá acesso apenas a essa requisição.