Saltar para o conteúdo principal
Cada sessão de verificação passa por uma série de estados. Compreendê-los ajuda-o a acompanhar o progresso do utilizador, automatizar decisões de conformidade e otimizar a conversão. Este enum é a única fonte de verdade para as strings devolvidas por GET /v3/session/<id>/decision/ e por todos os webhooks da Didit.

Todos os valores de estado

Cada estado é uma string exata devolvida pela API e pelos webhooks da Didit. Use sempre a comparação estrita de strings (por exemplo, === "In Review") no seu código: estes valores diferenciam maiúsculas de minúsculas e incluem espaços. O valor Kyc Expired também usa um K maiúsculo único (e não KYC).

Estados da sessão

Valor na API: "Not Started"A sessão foi criada através da API, mas o utilizador ainda não abriu a ligação de verificação.
  • O que fazer: Aguardar que o utilizador comece ou enviar um lembrete se passar demasiado tempo.
  • Transita para: "In Progress", "Expired"
Valor na API: "In Progress"O utilizador abriu a ligação e está a concluir os passos de verificação do fluxo (captura do documento, prova de vida, etc.).
  • O que fazer: Não é necessária qualquer ação — o utilizador está a seguir o fluxo.
  • Transita para: "Approved", "Declined", "In Review", "Abandoned"
Valor na API: "Approved"Todas as verificações foram concluídas com êxito. A identidade do utilizador foi verificada.
  • O que fazer: Conceder acesso ao utilizador, atualizar o respetivo perfil e guardar os dados da decisão.
  • O webhook inclui: O objeto decision completo com os resultados de todas as funcionalidades.
  • Transita para: "Kyc Expired" (quando a data de validade do documento verificado é ultrapassada, salvo se o Expiration mode estiver definido como Allow expired para esse país e tipo de documento; Reject expired é o valor predefinido). Um revisor ou o endpoint de atualização de estado também pode defini-la como "Declined" ou "Resubmitted".
Valor na API: "Declined"Uma ou mais verificações falharam. O utilizador não passou na verificação.
  • O que fazer: Notificar o utilizador. Opcionalmente, pedir uma nova submissão se o problema puder ser corrigido.
  • O webhook inclui: O objeto decision completo com os avisos que explicam a falha.
  • Transita para: "Resubmitted" (se um revisor o pedir). Um revisor ou o endpoint de atualização de estado também pode defini-la como "Approved".
Valor na API: "In Review"As verificações automáticas sinalizaram avisos que precisam de revisão humana. Um revisor de conformidade tem de tomar a decisão final.
  • O que fazer: Um revisor deve abrir a sessão na Console e aprovar, recusar ou pedir uma nova submissão.
  • O webhook inclui: O objeto decision completo com os avisos.
  • Transita para: "Approved", "Declined", "Resubmitted"
Valor na API: "Awaiting User"Usado em sessões KYB (verificação de empresas) quando o passo de pessoas-chave submeteu a lista de partes e criou sessões KYC / KYB filhas. A sessão principal aguarda até que todas as partes obrigatórias concluam a respetiva verificação individual.
  • O que fazer: Acompanhar os estados das sessões KYC filhas. Quando todas as partes obrigatórias terminarem (aprovadas, recusadas ou expiradas), a sessão principal recalcula automaticamente o seu estado final.
  • O webhook inclui: A lista atual de partes e os estados das respetivas sessões filhas.
  • Transita para: "Approved", "Declined", "In Review" (quando todas as sessões filhas estiverem em estado terminal)
  • Transita de: "In Progress" (depois de submetido o passo de pessoas-chave)
  • Nota: Se uma sessão KYC filha for submetida novamente, a sessão principal volta a "Awaiting User" até que a sessão submetida novamente seja concluída. Uma KYB Registry Check com estado "Declined" tem prioridade sobre "Awaiting User".
Valor na API: "Resubmitted"Um revisor pediu que o utilizador refaça passos específicos de verificação (por exemplo, tirar outra fotografia desfocada do documento).
  • O que fazer: Aguardar que o utilizador conclua os passos cuja repetição foi solicitada. O sistema reavaliará automaticamente.
  • O webhook inclui: O objeto resubmit_info com a lista de funcionalidades a repetir e os motivos.
  • Transita para: "Approved", "Declined", "In Review", ou "Abandoned" quando a janela da sessão terminar antes de a pessoa refazer os passos.
Valor na API: "Expired"A sessão expirou antes de o utilizador abrir a ligação de verificação.
  • O que fazer: Criar uma nova sessão e enviar ao utilizador uma ligação nova.
  • Estado terminal, sem transições seguintes.
Valor na API: "Abandoned"O utilizador iniciou mas não concluiu a verificação dentro do prazo permitido.
  • O que fazer: Enviar um lembrete ou criar uma nova sessão.
  • Sem transições automáticas. Um revisor, ou PATCH /v3/session/{sessionId}/update-status/, pode ainda defini-la como "Approved", "Declined" ou "Resubmitted".
Valor na API: "Kyc Expired"O documento verificado durante a sessão ultrapassou a respetiva data de validade. O acionador é essa data, e não um prazo contado a partir da aprovação, e não é enviado nenhum aviso prévio.
  • O que fazer: Pedir ao utilizador que se verifique novamente com uma nova sessão. status.updated transmite a transição, e o resultado da verificação de identidade inclui um aviso DOCUMENT_EXPIRED.
  • Controlado por: o Expiration mode desse país e tipo de documento em ID verification → Additional settings by country & document type. Reject expired (o valor predefinido) monitoriza o documento; Allow expired significa que a sessão nunca transita para este estado.
  • Sem transições automáticas. Um revisor, ou PATCH /v3/session/{sessionId}/update-status/, pode ainda defini-la como "Approved", "Declined" ou "Resubmitted".

Transições de estado

Diagrama do ciclo de vida


Terminal vs. não terminal


Tratamento dos estados no seu código

Use webhooks ou a API de obtenção de sessão para reagir às alterações de estado.
Os estados são cadeias de caracteres exatas, sensíveis a maiúsculas e minúsculas, com espaços. Por exemplo, "In Review" (e não "in_review" ou "IN_REVIEW"). Use sempre a igualdade estrita (===) ao comparar.

Reenvio

O estado Resubmitted permite à sua equipa de conformidade dar uma segunda oportunidade aos utilizadores sem criar uma nova sessão.
1

O revisor inicia o reenvio

Na Consola, abra uma sessão In Review ou Declined e clique em Solicitar Reenvio. Selecione os passos que devem ser refeitos.
2

Os dados anteriores são arquivados

O sistema repõe as funcionalidades selecionadas e marca os dados anteriores como previous_attempt, preservando o registo de auditoria completo.
3

O utilizador é notificado

Se existir um e-mail, o utilizador recebe um e-mail localizado com uma ligação direta para retomar.
4

O utilizador refaz passos específicos

O utilizador repete apenas os passos assinalados, e não toda a verificação.
5

O sistema reavalia

Quando concluir, a sessão transita automaticamente para "Approved", "Declined" ou "In Review".

Payload do webhook de reenvio

reasons associa cada node_id reenviado ao código de aviso do registo mais relevante desse passo (os mesmos códigos que a decisão apresenta), para que possa mapeá-lo para o seu próprio texto. É também o código que o ecrã de reenvio do fluxo alojado e o e-mail de reenvio localizam para o utilizador, exceto nos avisos que revelariam um sinal de triagem ou de fraude (duplicados, AML, lista de bloqueio, verificações entre organizações, integridade da localização e similares): nesses casos, a pessoa vê um motivo genérico, e resubmit_info.reasons no seu webhook contém sempre o código real. Um passo sem aviso registado não tem entrada.

Que funcionalidades podem ser reenviadas

Qualquer funcionalidade com um estado não aprovado: Declined, In Review, Not Finished, Not Started ou Expired.
Pode solicitar o reenvio várias vezes na mesma sessão. Cada ciclo arquiva os dados da tentativa anterior, dando-lhe visibilidade completa do histórico de verificação do utilizador.

Melhores práticas

Monitorizar sessões em análise

Configure alertas (e-mail ou Slack) na sua Didit Console para ser notificado quando as sessões precisarem de revisão manual.

Preferir o reenvio

Se o problema puder ser corrigido (foto desfocada, lado errado do documento), peça um reenvio em vez de recusar. Isto melhora a taxa de conversão.

Acompanhar os abandonos

Taxas elevadas de sessões abandonadas ou expiradas podem indicar atrito na experiência do utilizador. Considere ajustar o TTL da sessão ou melhorar as instruções ao utilizador.

Processadores idempotentes

Os webhooks podem ser reenviados. Use session_id como chave única para garantir que processa cada alteração de estado apenas uma vez.
Valide sempre as assinaturas dos webhooks antes de processar os payloads. A Didit disponibiliza três métodos: X-Signature, X-Signature-V2 (recomendado) e o X-Signature-Simple, descontinuado, que autentica apenas o envelope e nunca o corpo decision. Consulte Webhooks para mais detalhes.
Última modificação em 7 de novembro de 2026