Pular para o conteúdo principal
Este guia mostra o fluxo completo para integrar a verificação de identidade da Didit pela API REST: obter as credenciais, criar uma sessão, apresentá-la ao usuário e receber os resultados.

Etapa 1: Obtenha suas credenciais

Há duas formas de obter uma api_key:

Opção A: Registro programático (sem navegador)

Ideal para CI/CD e agentes de IA. Duas chamadas de API, POST /programmatic/register/ e depois POST /programmatic/verify-email/, retornam a api_key inline. → Consulte Registro programático para ver o fluxo completo, as regras de senha, a validade do JWT e a política de bloqueio.

Opção B: Pelo Didit Console

  1. Acesse o Didit Console.
  2. Crie ou selecione sua organização.
  3. Navegue até Settings → API & Webhooks.
  4. Copie:
    • API Key: usada como cabeçalho x-api-key em todas as chamadas de verificação.
    • Webhook Secret Key: usada para verificar as assinaturas HMAC dos webhooks.

Variáveis de ambiente


Etapa 2: Crie um fluxo de verificação

Antes de criar sessões, você precisa de um fluxo de verificação (workflow). Os fluxos definem as etapas de verificação pelas quais os usuários passam.

Criar no Console

  1. Acesse o Didit Console → Workflows
  2. Clique em Create Workflow
  3. Escolha um modelo base:
  1. Adicione recursos opcionais:
  1. Copie o seu Workflow ID
Consulte a documentação de fluxos para ver as opções de configuração em detalhes.

Etapa 3: Criar uma sessão de verificação

Chame a API para criar uma sessão para o seu usuário.

Requisição

Parâmetros da requisição

Exemplo completo com todas as opções

expected_details.expected_document_types restringe a etapa de verificação de identidade a tipos de documento específicos: a tela de seleção de documento mostra apenas os tipos solicitados. Valores permitidos: P (passaporte), ID (documento nacional de identidade), DL (carteira de motorista), RP (autorização de residência), HIC (cartão de plano de saúde), TC (cartão fiscal), SSC (cartão de seguridade social). Os valores não diferenciam maiúsculas de minúsculas e duplicatas são removidas; valores desconhecidos retornam 400. Consulte a referência de Create Session para ver o esquema completo.

Resposta

201 Created:

Principais campos da resposta

Idempotência. Quando vendor_data é informado e já existe uma sessão não concluída (Not Started, In Progress, Resubmitted ou Awaiting User) com o mesmo vendor_data na versão publicada mais recente do fluxo, essa sessão existente é retornada (ainda com 201) em vez de ser criada uma duplicata, com callback e metadata atualizados para os novos valores e status refletindo a sessão existente.
A ausência de x-api-key retorna 403 com {"detail": "You do not have permission to perform this action."}, o mesmo corpo de uma chave válida sem permissão. Uma chave incorreta, revogada ou expirada retorna 401. Créditos insuficientes retornam 400. Consulte a referência da API Create Session para ver a documentação completa.

Etapa 4: Apresentar a verificação ao usuário

Escolha como apresentar o fluxo de verificação ao seu usuário:

Opção A: SDK nativo (recomendado para dispositivos móveis)

Use o session_token com os SDKs nativos para integração com câmera, NFC e biometria. → SDK para iOS · SDK para Android · React Native · Flutter

Opção B: iframe InContext (recomendado para web)

Incorpore a verificação na sua página usando a url retornada na Etapa 3.
→ iframe InContext

Opção C: Redirecionamento

Redirecione o usuário para a URL de verificação.
→ Redirecionamento web

Opção D: WebView em dispositivos móveis

Para aplicativos móveis sem SDK nativo.
→ WebView no iOS/Android

Etapa 5: receber os resultados

Via webhook (recomendado)

Os webhooks notificam seu servidor em tempo real quando o status da verificação muda. Configuração:
  1. Crie um destino do webhook no Console (API & Webhooks) ou via POST /v3/webhook/destinations/ com webhook_version: "v3" e um array subscribed_events (por exemplo, ["status.updated"])
  2. Guarde o secret_shared_key retornado na criação: ele é o segredo HMAC de todas as variantes de assinatura
  3. Implemente um endpoint de webhook no seu servidor
Exemplo de payload de webhook: Dentro de decision, cada resultado por recurso é entregue como um array no plural (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …), com uma entrada por nó do fluxo. Esse é o contrato da V3 e é inviolável: nunca escreva código que dependa de uma chave no singular como nfc / id_verification / liveness.
O objeto decision só está presente quando status é Approved, Declined, In Review ou Abandoned (um evento Resubmitted traz resubmit_info no lugar dele). A Didit reutiliza o mesmo event_id entre novas tentativas e entre destinos de fan-out, então baseie sua idempotência nele. Consulte Modelos de dados para ver todos os arrays no plural e todos os campos. Verifique a assinatura (X-Signature-V2, recomendado): X-Signature-V2 é um HMAC-SHA256 calculado sobre uma recodificação canônica do corpo JSON: floats com valor inteiro reduzidos a ints, chaves ordenadas recursivamente, separadores compactos e Unicode preservado.
→ Documentação completa de webhooks, incluindo o X-Signature sobre os bytes brutos, o X-Signature-Simple obsoleto que cobre apenas o envelope e como escolher entre eles. A Didit tenta novamente as entregas que falham (5xx, 404, timeout) até 2 vezes (após ~1 min e depois ~4 min) e encerra a espera após 5 segundos, então retorne 2xx rapidamente.

Via API (opcional)

Busque o mesmo payload de decisão a qualquer momento:
O formato da resposta (arrays no plural) é idêntico ao do objeto decision dentro do payload do webhook, e o endpoint pode ser chamado em qualquer ponto do ciclo de vida da sessão. Use webhooks para atualizações em tempo real e reserve as chamadas à API para preenchimento retroativo, auditoria e reconstruções. O endpoint /decision/ tem limite de requisições de 600 requisições GET/min por chave de API (consulte Limite de requisições). Semântica de erros: um session_id desconhecido retorna 404 com {"detail": "Not found."}, e falhas de autenticação aparecem como 403. Este endpoint nunca retorna 401. As URLs de mídia na resposta são links pré-assinados de curta duração: baixe o conteúdo logo, em vez de armazenar os links. → Referência da API de consulta de sessão

Exemplos de código completos

Node.js / Express

Python / FastAPI


Status da sessão

Estes são os 10 valores possíveis de status. São strings exatas, que diferenciam maiúsculas de minúsculas (observe que Kyc Expired usa apenas o K maiúsculo): Consulte Status de verificação para ver o ciclo de vida completo, as transições e o diagrama Mermaid.

Próximos passos

  1. Escolha seu método de integração:
  2. Configure webhooks: Webhooks
  3. Planeje a capacidade: Limite de requisições
  4. Trate todos os status: Status de verificação
  5. Personalize seu fluxo: Fluxos
  6. Verifique se a API está acessível: Healthcheck

Precisa de ajuda?

Última modificação em 1 de novembro de 2026