Etapa 1: Obtenha suas credenciais
Há duas formas de obter umaapi_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
- Acesse o Didit Console.
- Crie ou selecione sua organização.
- Navegue até Settings → API & Webhooks.
- Copie:
- API Key: usada como cabeçalho
x-api-keyem todas as chamadas de verificação. - Webhook Secret Key: usada para verificar as assinaturas HMAC dos webhooks.
- API Key: usada como cabeçalho
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
- Acesse o Didit Console → Workflows
- Clique em Create Workflow
- Escolha um modelo base:
- Adicione recursos opcionais:
- 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 osession_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 aurl retornada na Etapa 3.
Opção C: Redirecionamento
Redirecione o usuário para a URL de verificação.Opção D: WebView em dispositivos móveis
Para aplicativos móveis sem SDK nativo.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:- Crie um destino do webhook no Console (API & Webhooks) ou via
POST /v3/webhook/destinations/comwebhook_version: "v3"e um arraysubscribed_events(por exemplo,["status.updated"]) - Guarde o
secret_shared_keyretornado na criação: ele é o segredo HMAC de todas as variantes de assinatura - Implemente um endpoint de webhook no seu servidor
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.
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.
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: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 destatus. 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
- Escolha seu método de integração:
- Aplicativos móveis → SDKs nativos
- Aplicações web → SDKs web
- Configure webhooks: Webhooks
- Planeje a capacidade: Limite de requisições
- Trate todos os status: Status de verificação
- Personalize seu fluxo: Fluxos
- Verifique se a API está acessível: Healthcheck
Precisa de ajuda?
- Suporte: support@didit.me
- Onboarding programático: Cadastro programático