Saltar para o conteúdo principal
As sessões são a unidade de verificação na Didit. Quando inicia uma verificação, é criada uma sessão; quando a verificação termina, a sessão contém o payload de decisão completo. A mesma API de sessões trata os dois tipos: Na lição da Academy sobre o que os utilizadores veem, o capítulo 5:34 compara o fluxo alojado com a criação de ecrãs próprios, que é exatamente o compromisso que esta API decide por si.

​
O tipo é determinado pelo fluxo

Quando cria uma sessão, passa um workflow_id. O tipo do fluxo determina se a sessão é de Verificação de utilizadores ou de Verificação de empresas; quem chama a API não escolhe separadamente. Os fluxos KYB criam sessões de Verificação de empresas; os fluxos KYC criam sessões de Verificação de utilizadores.

​
Discriminador session_kind

Cada resposta de sessão (de criar, obter, listar, atualizar estado, partilhar e importar) inclui um campo de nível superior:
  • "user": a sessão é uma sessão de Verificação de utilizadores (KYC). A resposta contém arrays de funcionalidades específicos de utilizadores.
  • "business": a sessão é uma sessão de Verificação de empresas (KYB). A resposta contém arrays de funcionalidades específicos de empresas.
Use este campo para determinar a estrutura da resposta no seu sistema.
Os valores do enum são os identificadores curtos "user" e "business". Mantemo-los curtos para facilitar a utilização da API. Os nomes completos Verificação de utilizadores (KYC) e Verificação de empresas (KYB) são usados ao longo da documentação para maior clareza.

​
Arrays de funcionalidades por tipo

Os arrays de funcionalidades presentes numa decisão dependem do tipo. Os campos que não existem num dos tipos simplesmente não aparecem na resposta desse tipo (sem valores nulos e sem marcadores de posição):

​
Campos de nível superior partilhados

Todas as sessões (dos dois tipos) incluem estes campos:

​
Endpoints abrangidos

Os endpoints seguintes aceitam qualquer um dos tipos. Não existem caminhos /v3/business-session/* separados.

​
Como funcionam as pesquisas

As sessões de Verificação de utilizadores e as de Verificação de empresas são dois tipos distintos. Os IDs usam UUID, pelo que colisões são impossíveis. Quando chama um endpoint com um session_id, a Didit:
  1. Procura o ID primeiro na tabela de Verificação de utilizadores (cobre a maior parte do tráfego).
  2. Recorre à tabela de Verificação de empresas se não o encontrar.
  3. Devolve 404 se nenhuma das tabelas tiver correspondência.
Não precisa de indicar à API o tipo que procura.

​
Os estados são idênticos

Os valores de estado são os mesmos nos dois tipos, e a API devolve-os exatamente como estão escritos aqui: "Not Started", "In Progress", "Approved", "Declined", "In Review", "Abandoned", "Expired", "Kyc Expired", "Resubmitted", "Awaiting User". A comparação é exata e diferencia maiúsculas de minúsculas. Consulte estados de verificação para a referência completa.

​
Webhooks

Os eventos de webhook já incluem um campo session_kind, para que os seus manipuladores de webhook possam encaminhar cada evento consoante o tipo: Consulte webhooks para a verificação da assinatura e o comportamento das novas tentativas, e webhooks KYB para o catálogo de eventos de Verificação de empresas (KYB).

​
Próximos passos

Criar sessão

Inicie uma verificação: Verificação de utilizadores ou Verificação de empresas (KYB).

Obter sessão

Obtenha a decisão. Funciona para os dois tipos.

Listar sessões

Filtre por session_kind.

Atualizar estado

Aprovar, recusar, analisar, reenviar.

Gerar PDF

Relatórios PDF por tipo.

Partilhar e importar

Transfira sessões entre aplicações.
Última modificação em 7 de novembro de 2026