Saltar para o conteúdo principal
Este guia orienta-o pelo fluxo completo de integração da verificação de identidade da Didit através da API REST: obter as credenciais, criar uma sessão, apresentá-la ao utilizador e receber os resultados.

Passo 1: Obter as suas credenciais

Tem duas formas de obter um api_key:

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

Ideal para CI/CD e agentes de IA. Duas chamadas à API — POST /programmatic/register/ e depois POST /programmatic/verify-email/ — devolvem o api_key na própria resposta. → Consulte o Registo programático para ver o fluxo completo, as regras de palavra-passe, a validade do JWT e a política de bloqueio.

Opção B: Através da Didit Console

  1. Aceda à Didit Console.
  2. Crie ou selecione a sua organização.
  3. Navegue até Definições → API e Webhooks.
  4. Copie:
    • Chave de API — usada como cabeçalho x-api-key em cada chamada de verificação.
    • Chave secreta do webhook — usada para verificar as assinaturas HMAC dos webhooks.

Variáveis de ambiente


Passo 2: Criar um fluxo de verificação

Antes de criar sessões, precisa de um fluxo de verificação. Os fluxos definem os passos de verificação pelos quais os utilizadores passam.

Criar na consola

  1. Aceda à Didit Console → Fluxos
  2. Clique em Criar fluxo
  3. Escolha um modelo base:
  1. Adicione funcionalidades opcionais:
  1. Copie o seu ID do fluxo
Consulte a documentação dos fluxos para ver as opções de configuração detalhadas.

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

Chame a API para criar uma sessão para o seu utilizador.

Pedido

Parâmetros do pedido

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: o ecrã de seleção de documentos mostra apenas os tipos pedidos. Valores permitidos: P (passaporte), ID (documento de identidade nacional), DL (carta de condução), RP (título de residência), HIC (cartão de seguro de saúde), TC (cartão fiscal), SSC (cartão de segurança social). Os valores não diferenciam maiúsculas de minúsculas e são eliminados os duplicados; valores desconhecidos devolvem 400. Consulte a referência de criação de sessão para o esquema completo.

Resposta

201 Created:

Campos principais da resposta

Idempotência. Quando é fornecido vendor_data 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 é devolvida (ainda com 201) em vez de criar um duplicado. O seu callback e metadata são atualizados para os novos valores, e status reflete o estado da sessão existente.
Um x-api-key em falta devolve 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 devolve 401. Créditos insuficientes devolvem 400. Consulte a referência da API de Criar sessão para a documentação completa.

Passo 4: Apresentar a verificação ao utilizador

Escolha a forma como pretende apresentar o fluxo de verificação ao seu utilizador:

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

Utilize o session_token com os SDK nativos para a câmara, NFC e integração biométrica. → SDK iOS · SDK Android · React Native · Flutter

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

Incorpore a verificação na sua página com o url devolvido no Passo 3.
→ iframe InContext

Opção C: Redirecionamento

Redirecione o utilizador para o URL de verificação.
→ Redirecionamento web

Opção D: WebView móvel

Para aplicações móveis sem SDK nativo.
→ WebView em iOS/Android

Passo 5: Receber resultados

Através de webhook (recomendado)

Os webhooks notificam o seu servidor em tempo real sempre que o estado da verificação muda. Configuração:
  1. Crie um destino do webhook na Consola (API e Webhooks) ou através de POST /v3/webhook/destinations/ com webhook_version: "v3" e um array subscribed_events (por exemplo, ["status.updated"])
  2. Armazene o secret_shared_key devolvido na criação, que é o segredo partilhado HMAC para 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 funcionalidade é entregue como um array plural (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …), com uma entrada por nó do fluxo. Este é o contrato V3 e é intocável: nunca use chaves no singular nfc, id_verification ou liveness.
O objeto decision só está presente quando status é Approved, Declined, In Review ou Abandoned (um evento Resubmitted inclui resubmit_info). A Didit reutiliza o mesmo event_id nas novas tentativas e nos destinos de distribuição, por isso use-o como chave de idempotência. Consulte Modelos de dados para ver todos os arrays plurais e campos. Verificar a assinatura (X-Signature-V2, recomendado): X-Signature-V2 é um HMAC-SHA256 sobre uma recodificação canónica do corpo JSON: valores float com valor inteiro são encurtados para inteiros, as chaves são ordenadas recursivamente, usam-se separadores compactos e o Unicode é preservado.
→ Documentação completa sobre webhooks, incluindo o X-Signature com bytes brutos, o X-Signature-Simple obsoleto, que só cobre o envelope, e como escolher. A Didit repete as entregas falhadas (5xx, 404, tempo limite) até 2 vezes (cerca de 1 min, depois cerca de 4 min) e o tempo limite é de 5 segundos: devolva 2xx rapidamente.

Através da API (opcional)

Obtenha o mesmo payload de decisão em qualquer momento:
A estrutura da resposta (arrays plurais) é idêntica ao objeto decision do payload do webhook, e o endpoint pode ser chamado em qualquer momento do ciclo de vida da sessão. Use os webhooks para atualizações em tempo real e reserve as chamadas à API para sincronização retroativa, auditoria e reconstruções. O endpoint /decision/ tem limite de 600 pedidos GET por minuto por chave de API (consulte Limites de pedidos). Semântica de erros: um session_id desconhecido devolve 404 com {"detail": "Not found."}; as falhas de autenticação aparecem como 403, e este endpoint nunca devolve 401. Os URLs de multimédia na resposta são ligações pré-assinadas de curta duração, por isso obtenha-os de imediato em vez de os guardar. → Consultar a referência da API de sessão

Exemplos de código completos

Node.js / Express

Python / FastAPI


Estados da sessão

Estes são os 10 valores possíveis de status, strings exatas e sensíveis a maiúsculas e minúsculas (repare que Kyc Expired usa um único K maiúsculo): Consulte Estados de verificação para o ciclo de vida completo, as transições e o diagrama Mermaid.

Próximos passos

  1. Escolha o seu método de integração:
  2. Configure os webhooks: Webhooks
  3. Planeie a capacidade: Limites de pedidos
  4. Trate todos os estados: Estados de verificação
  5. Personalize o seu fluxo: Fluxos
  6. Verifique se a API está acessível: Verificação do estado

Precisa de ajuda?

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