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
Não iniciada — "Not Started"
Não iniciada — "Not Started"
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"
Em curso — "In Progress"
Em curso — "In Progress"
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"
Aprovada — "Approved"
Aprovada — "Approved"
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
decisioncompleto 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".
Recusada — "Declined"
Recusada — "Declined"
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
decisioncompleto 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".
Em análise — "In Review"
Em análise — "In Review"
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
decisioncompleto com os avisos. - Transita para:
"Approved","Declined","Resubmitted"
A aguardar utilizador — "Awaiting User"
A aguardar utilizador — "Awaiting User"
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".
Submetida novamente — "Resubmitted"
Submetida novamente — "Resubmitted"
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_infocom 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.
Expirada — "Expired"
Expirada — "Expired"
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.
Abandonada — "Abandoned"
Abandonada — "Abandoned"
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".
KYC expirado — "Kyc Expired"
KYC expirado — "Kyc Expired"
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.updatedtransmite a transição, e o resultado da verificação de identidade inclui um avisoDOCUMENT_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.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.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.