Pular para o conteúdo principal
As sessões são a unidade de verificação na Didit. Quando você inicia uma verificação, uma sessão é criada; quando a verificação termina, a sessão traz o payload completo da decisão. A mesma API de sessões atende aos dois tipos: Na aula da Academy sobre o que os usuários veem, o capítulo de 5:34 compara o fluxo hospedado com a criação das suas próprias telas, que é justamente a escolha que esta API faz por você.

​
O tipo é definido pelo fluxo de verificação

Ao criar uma sessão, você informa um workflow_id. O tipo do fluxo de verificação (workflow) define se a sessão é de Verificação de Usuário ou de Verificação de Empresas; quem chama a API não escolhe isso separadamente. Fluxos de KYB criam sessões de Verificação de Empresas; fluxos de KYC criam sessões de Verificação de Usuário.

​
Discriminador session_kind

Toda resposta de sessão (de criação, consulta, listagem, atualização de status, compartilhamento e importação) inclui um campo de nível superior:
  • "user": a sessão é uma sessão de Verificação de Usuário (KYC). A resposta contém arrays de recursos específicos do usuário.
  • "business": a sessão é uma sessão de Verificação de Empresas (KYB). A resposta contém arrays de recursos específicos da empresa.
Use este campo para tratar o formato da resposta do seu lado.
Os valores do enum são os identificadores curtos "user" e "business"; eles são curtos para facilitar o uso da API. Os nomes completos Verificação de Usuário (KYC) e Verificação de Empresas (KYB) são usados em toda a documentação para maior clareza.

​
Arrays de recursos por tipo

Os arrays de recursos presentes em uma decisão dependem do tipo. Campos que não existem em um tipo simplesmente não aparecem nessa resposta (sem nulos, sem valores de preenchimento):

​
Campos de nível superior compartilhados

Toda sessão (dos dois tipos) traz estes campos:

​
Endpoints abrangidos

Todos os endpoints a seguir aceitam os dois tipos. Não há caminhos /v3/business-session/* separados.

​
Como funcionam as consultas

As sessões de Verificação de Usuário e de Verificação de Empresas são dois tipos distintos. Os IDs são UUIDs, então colisões são impossíveis. Quando você chama um endpoint com um session_id, a Didit:
  1. Procura o ID primeiro na tabela de Verificação de Usuário (que cobre a maior parte do tráfego).
  2. Recorre à tabela de Verificação de Empresas se não o encontrar.
  3. Retorna 404 se nenhuma das tabelas tiver correspondência.
Você nunca precisa informar à API qual tipo está procurando.

​
Os status são idênticos

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

​
Webhooks

Os eventos de webhook já trazem um campo session_kind, para que seus handlers de webhook possam direcionar o processamento conforme o tipo: Consulte webhooks para verificação de assinatura e a semântica de novas tentativas, e webhooks de KYB para o catálogo de eventos da Verificação de empresas.

​
Próximos passos

Criar sessão

Inicie uma verificação: Verificação de Usuários ou Verificação de Empresas.

Consultar sessão

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

Listar sessões

Filtre por session_kind.

Atualizar status

Aprove, recuse, envie para revisão ou solicite novo envio.

Gerar PDF

Relatórios em PDF por tipo.

Compartilhar e importar

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