Autenticação
Todos os endpoints da API de gerenciamento usam a chave de API da sua aplicação. Não é preciso incluir UUIDs de organização ou de aplicação nas URLs: a aplicação é identificada pela sua chave.Fluxos de verificação (workflows)
Os fluxos de verificação (workflows) definem as etapas de verificação pelas quais seus usuários passam (leitura do documento de identidade, prova de vida, correspondência facial, análise AML etc.). Cada fluxo é uma configuração reutilizável que você vincula às sessões.GET
Lista todos os fluxos da sua aplicação. Retorna os recursos e limiares de cada fluxo e se ele é o padrão.
POST
Cria um novo fluxo. Defina quais recursos de verificação ativar, configure limiares, os tipos de documento aceitos e muito mais.
GET
Obtém todos os detalhes de um fluxo específico, incluindo todas as configurações de recursos e limiares.
PATCH
Atualiza a configuração de um fluxo. Você pode modificar qualquer configuração de recurso, limiar ou documento aceito.
DELETE
Exclui um fluxo. As sessões que já usam esse fluxo não são afetadas.
Exemplo rápido: criar um fluxo
Oworkflow_type determina o conjunto base de recursos. Depois, cada recurso é ativado ou desativado com as flags is_*_enabled.
workflow_type: kyc, kyb, adaptive_age_verification, biometric_authentication, address_verification, questionnaire_verification, email_verification, phone_verification.
Nos fluxos kyc, a verificação de identidade é incluída automaticamente: você não precisa de uma flag separada para ela. Use as flags is_*_enabled para adicionar ou remover recursos opcionais, como correspondência facial, prova de vida, AML, NFC, telefone, e-mail, comprovante de endereço, Análise de dispositivo e IP e outros.
Em seguida, use o fluxo ao criar sessões:
Questionários
Formulários personalizados que você pode adicionar aos fluxos de verificação para coletar informações adicionais dos usuários.GET
Liste todos os questionários.
POST
Crie um novo questionário com perguntas personalizadas, lógica de ramificação e traduções.
GET
Obtenha os detalhes do questionário, incluindo todas as perguntas e a estrutura do formulário.
PATCH
Atualize um questionário.
DELETE
Exclua um questionário.
Usuários
Gerencie as pessoas verificadas (usuários) da sua aplicação. Cada usuário é identificado por uma stringvendor_data que você informa ao criar sessões.
GET
Lista todos os usuários da sua aplicação, incluindo o status de verificação e o histórico de sessões de cada um.
GET
Obtém os detalhes de um usuário pelo seu identificador vendor_data.
PATCH
Atualiza os metadados do usuário.
POST
Exclui usuários em lote. Corpo:
{"vendor_data_list": ["user-1", "user-2"]} ou {"delete_all": true}. Também elimina permanentemente todos os templates biométricos retidos desses usuários.Templates biométricos
Templates biométricos faciais, sem imagens, que uma aplicação que optou por esse recurso retém após excluir sessões. Consulte Templates biométricos.GET
Lista paginada com filtros (
vendor_data, vendor_user_uuid, status, source_type, retained_from, retained_to, ordering).GET
Contagem com os mesmos filtros.
GET
Um template: usuário proprietário, referência de procedência, validade, instrução e status.
DELETE
Elimina permanentemente um template. Retorna
{"uuid": "...", "outcome": "purged" | "already_purged"}.POST
Eliminação permanente em massa. Corpo:
{"template_uuids": [...]} ou {"delete_all": true}, além de filtros opcionais.Operações de sessão
POST
Exclui sessões em lote. Requer
delete:sessions. Corpo: {"session_numbers": ["1", "2", "3"]} ou {"delete_all": true} (restrinja o delete_all com os filtros de List Sessions prefixados com filter_, como filter_status), além dos parâmetros opcionais retain_face_embeddings, face_retention_days, face_retention_deadline, deletion_instruction e instruction_id. Até 20 sessões correspondentes retornam 200 com um face_retention_outcome por sessão; acima disso, a resposta é 202 com um job de exclusão.GET
Progresso e contagens de resultados de uma exclusão de sessões em massa que retornou
202.GET
Lista as revisões e o registro de atividades de uma sessão.
POST
Adiciona uma nota de revisão ou uma alteração de status a uma sessão.
Faturamento
GET
Obtém o saldo atual de créditos e as configurações de recarga automática.
POST
Cria uma sessão de checkout do Stripe para recarregar créditos. Cada recarga vai de $50 a $10,000 e é creditada pelo valor nominal.
Listas (listas de bloqueio, listas de permissões e personalizadas)
Gerencie listas classificadas por tipo para bloqueio, permissão e condições personalizadas de fluxo de verificação (workflow). Consulte a documentação completa da API de listas.GET
Lista todas as listas da aplicação (listas de bloqueio, listas de permissões e personalizadas).
POST
Adiciona uma entrada a uma lista. Aceita
reference_session_id para extrair dados automaticamente de uma sessão e reference_object_uuid para rastreabilidade até transações, usuários ou empresas.DELETE
Remove uma entrada de uma lista.
POST
Envia uma imagem de rosto para uma lista de bloqueio de rostos (base64).
Configuração de webhook
GET
Obtém a configuração atual do webhook, incluindo URL, versão, a chave secreta para verificar as assinaturas do webhook e a política de retenção de dados e de retenção de templates biométricos da aplicação.
A resposta também traz
allowed_domains, descrito em PATCH /v3/webhook/ abaixo.PATCH
Atualiza a URL e a versão do webhook ou rotaciona a chave secreta. Defina
rotate_secret_key: true para gerar um novo segredo do webhook (o antigo é invalidado imediatamente). Também define a política de retenção da aplicação: data_retention_months e face_retention_policy (delete_with_session, o padrão, ou retain_until_user_deleted), junto com um face_retention_days finito e obrigatório (1-3650) quando a retenção está ativada. Consulte Retenção de templates biométricos. Também registra allowed_return_hosts: até 20 nomes de host simples (por exemplo app.example.com, sem esquema, porta, caminho ou curinga) para os quais uma verificação da API de carteira de Digital ID pode enviar a pessoa de volta por HTTPS. Uma nova lista substitui a registrada, e o domínio de marca própria da sua aplicação é sempre permitido.Também define allowed_domains: até 50 origens web (por exemplo https://app.example.com) nas quais o fluxo de verificação hospedado pode ser incorporado e para as quais pode enviar o usuário de volta com um callback de sessão.
Cada entrada é um esquema, um host e uma porta opcional, sem caminho, query ou curinga.
Use https; http só é aceito para localhost, 127.0.0.1 e ::1.
A Didit armazena cada origem em letras minúsculas e sem porta padrão, e retorna a lista em allowed_domains.
Uma entrada inválida resulta em erro 400 em allowed_domains.
Uma nova lista substitui a registrada, e uma lista vazia remove a restrição.
Enquanto a lista não estiver vazia, POST /v3/session/ rejeita com 400 um callback web fora dela, e o fluxo hospedado não redireciona o usuário para um callback armazenado ou padrão do fluxo que esteja fora dela.
Esquemas de URL personalizados (deep links de apps) e chamadas de API entre servidores não são afetados.Se você enviar endpoints, todo destino do webhook que ficar fora da lista é excluído permanentemente, junto com seu segredo de assinatura e todo o seu registro de entregas, exatamente como DELETE /v3/webhook/destinations/{destination_uuid}/.
Isso não pode ser desfeito.
Para gerenciar os destinos um de cada vez, use os endpoints de destino do webhook.