Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesFinalidades das mensagens
Atualmente, o carregamento de documentos aceita imagens JPEG, PNG e WebP até 5 MB.
Só aparecem as finalidades aplicáveis ao sujeito do caso.
Os modelos de e-mail para o cliente estão atualmente disponíveis em inglês, espanhol e português.
A consola usa o mesmo campo de e-mail e o mesmo seletor de idioma do reenvio de sessão.
Destinatários verificados e modelos fixos
Um destinatário tem de ter concluído a verificação de e-mail numa sessão pertencente ao sujeito do caso e à aplicação. Um endereço importado ou editado num perfil de utilizador não estabelece verificação. Se não existir nenhum contacto verificado, o editor de mensagens explica-o e o envio permanece desativado. Os revisores não podem fornecer texto de e-mail, ligações, endereços de remetente ou destinatários arbitrários. O e-mail usa a identidade visual Didit ou de marca branca existente. Um remetente personalizado exige que o domínio de e-mail configurado esteja verificado. Todos os modelos informam o destinatário de que o e-mail não pedirá palavras-passe, códigos de verificação nem pagamentos. O reenvio de sessão continua a ser uma ação separada para repetir as verificações. A respetiva pré-visualização mostra o e-mail de reenvio real e as verificações selecionadas.Entrega e respostas
O histórico de mensagens distingue os estados de entrega em fila, a enviar, enviado, simulado e desconhecido. Um e-mail simulado não é enviado. Um resultado desconhecido significa que o fornecedor poderá ter aceitado o e-mail; o sistema não o volta a enviar automaticamente. Tentar novamente um pedido confirmado usa o mesmo ID do pedido para evitar entregas duplicadas. Um pedido que exige ação tem uma ligação de resposta segura válida durante sete dias. Cancelar o pedido ou resolver o caso invalida essa ligação, incluindo depois de o caso ser reaberto. A página do cliente não divulga conclusões privadas do caso nem outros registos de origem. Uma resposta enviada aparece em Mensagens ao cliente como prova pendente de revisão. O caso volta ao estado Aberto, e uma resolução já pendente tem de ser revista novamente. As respostas não podem substituir um envio anterior, aprovar a verificação original, substituir a identidade de um cliente nem contribuir para um resultado de fraude. Eliminar a verificação de origem ou o caso elimina os respetivos pedidos ao cliente e as provas carregadas.Fluxo da API
Todos os endpoints da consola têm âmbito limitado a uma organização, a uma aplicação e a um caso:read:cases.
Compor, pré-visualizar, confirmar, cancelar e enviar lembretes requer write:cases.
A confirmação tem de incluir o mesmo contact_id, purpose e language, além de request_id, expires_at e preview_token devolvidos pela pré-visualização.
O recibo de confirmação expira após 15 minutos, independentemente do prazo de resposta do cliente.
Um lembrete reenvia o mesmo e-mail ao mesmo destinatário verificado, no máximo uma vez por pedido a cada 24 horas.
Não altera mais nada: o pedido mantém o prazo e o caso mantém o estado.
A resposta devolve o pedido, reminded_at, o próprio delivery_status do lembrete (SENT, SIMULATED ou UNKNOWN) e next_reminder_at.
Um pedido ao qual o cliente já não tem de responder devolve 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 devolve 429 com code case_request_reminder_too_soon, uma marca temporal retry_at e um cabeçalho Retry-After.
Enquanto uma resolução aguarda aprovação, um lembrete devolve 400.
O endpoint do cliente é GET ou POST /v3/case-requests/{request_uuid}/ com o cabeçalho X-Case-Request-Token específico do pedido.
A ligação de resposta transporta essa credencial no respetivo fragmento; a página remove o fragmento ao abrir.
O token concede acesso apenas a esse pedido.