Pular para o conteúdo principal
Toda sessão de verificação passa por uma série de status. Entendê-los ajuda você a acompanhar o progresso do usuário, automatizar decisões de conformidade e otimizar a conversão. Este enum é a única fonte de verdade para as strings retornadas por GET /v3/session/<id>/decision/ e por todos os webhooks da Didit.

Todos os valores de status

Cada status é uma string exata retornada pela API e pelos webhooks da Didit. Sempre use comparação estrita de strings (por exemplo, === "In Review") no seu código: esses valores diferenciam maiúsculas de minúsculas e incluem espaços. O valor Kyc Expired também usa apenas o K maiúsculo (não KYC).

Status de sessão

Valor na API: "Not Started"A sessão foi criada pela API, mas o usuário ainda não abriu o link de verificação.
  • O que fazer: aguarde o usuário começar ou envie um lembrete se passar muito tempo.
  • Muda para: "In Progress", "Expired"
Valor na API: "In Progress"O usuário abriu o link e está concluindo ativamente as etapas de verificação (captura do documento, prova de vida etc.).
  • O que fazer: nenhuma ação é necessária — o usuário está percorrendo o fluxo.
  • Muda para: "Approved", "Declined", "In Review", "Abandoned"
Valor na API: "Approved"Todas as verificações foram aprovadas com sucesso. A identidade do usuário foi verificada.
  • O que fazer: libere o acesso do usuário, atualize o perfil dele e armazene os dados da decisão.
  • O webhook inclui: o objeto decision completo, com os resultados de todos os recursos.
  • Muda para: "Kyc Expired" (quando passa a data de validade do documento verificado — o comportamento padrão, a menos que o Expiration mode seja Allow expired para aquele país e tipo de documento). Um revisor ou o endpoint update-status também pode alterá-la para "Declined" ou "Resubmitted".
Valor na API: "Declined"Pelo menos uma das verificações falhou. O usuário não foi aprovado na verificação.
  • O que fazer: notifique o usuário. Se o problema puder ser corrigido, você pode solicitar um reenvio.
  • O webhook inclui: o objeto decision completo, com avisos que explicam a falha.
  • Muda para: "Resubmitted" (se um revisor solicitar). Um revisor ou o endpoint update-status também pode alterá-la para "Approved".
Valor na API: "In Review"As verificações automáticas sinalizaram avisos que precisam de revisão humana. Um revisor de conformidade deve tomar a decisão final.
  • O que fazer: um revisor deve abrir a sessão no Console e aprovar, recusar ou solicitar o reenvio.
  • O webhook inclui: o objeto decision completo, com os avisos.
  • Muda para: "Approved", "Declined", "Resubmitted"
Valor na API: "Awaiting User"Usado em sessões de KYB (verificação de empresas) quando a etapa de pessoas-chave (Key People) já enviou a lista de partes e gerou sessões filhas de KYC / KYB. A sessão principal aguarda até que todas as partes obrigatórias concluam sua verificação individual.
  • O que fazer: acompanhe os status das sessões filhas de KYC. Quando todas as partes obrigatórias terminarem (aprovadas, recusadas ou expiradas), a sessão principal recalcula automaticamente seu status final.
  • O webhook inclui: a lista atual de partes e os status de suas sessões filhas.
  • Muda para: "Approved", "Declined", "In Review" (quando todas as sessões filhas estiverem em um status final)
  • Vem de: "In Progress" (depois que a etapa de pessoas-chave é enviada)
  • Observação: se uma sessão filha de KYC for reenviada, a sessão principal volta para "Awaiting User" até que a sessão reenviada seja concluída. Uma verificação de registro KYB (KYB Registry Check) com status "Declined" tem prioridade sobre "Awaiting User".
Valor na API: "Resubmitted"Um revisor solicitou que o usuário refaça etapas específicas da verificação (por exemplo, tirar novamente uma foto desfocada do documento).
  • O que fazer: aguarde o usuário concluir as etapas reenviadas. O sistema fará uma nova avaliação automaticamente.
  • O webhook inclui: o objeto resubmit_info, com a lista de recursos a refazer e os motivos.
  • Muda para: "Approved", "Declined", "In Review" ou "Abandoned", quando o prazo da sessão termina antes que a pessoa refaça as etapas.
Valor na API: "Expired"O tempo da sessão se esgotou antes de o usuário abrir o link de verificação.
  • O que fazer: crie uma nova sessão e envie um novo link ao usuário.
  • Status final — não há outras transições.
Valor na API: "Abandoned"O usuário começou, mas não concluiu a verificação dentro do prazo permitido.
  • O que fazer: envie um lembrete ou crie uma nova sessão.
  • Sem transições automáticas. Um revisor, ou PATCH /v3/session/{sessionId}/update-status/, ainda pode alterá-la para "Approved", "Declined" ou "Resubmitted".
Valor na API: "Kyc Expired"O documento verificado durante a sessão ultrapassou a própria data de validade. O gatilho é essa data, e não um prazo contado a partir da aprovação, e nenhum aviso é enviado antes.
  • O que fazer: peça ao usuário que faça a reverificação em uma nova sessão. O evento status.updated informa a transição, e o resultado da verificação de identidade traz um aviso DOCUMENT_EXPIRED.
  • Controlado por: o Expiration mode daquele país e tipo de documento em ID verification → Additional settings by country & document type — Reject expired (o padrão) monitora o documento; com Allow expired, a sessão nunca chega a este status.
  • Sem transições automáticas. Um revisor, ou PATCH /v3/session/{sessionId}/update-status/, ainda pode alterá-la para "Approved", "Declined" ou "Resubmitted".

Transições de status

Diagrama do ciclo de vida


Terminais e não terminais


Tratamento de status no seu código

Use webhooks ou a API Retrieve Session para reagir a mudanças de status.
Os status são strings exatas, que diferenciam maiúsculas de minúsculas e contêm espaços. Por exemplo, "In Review" (e não "in_review" ou "IN_REVIEW"). Sempre use igualdade estrita (===) ao compará-los.

Reenvio

O status Resubmitted permite que sua equipe de conformidade dê aos usuários uma segunda chance sem criar uma nova sessão.
1

O revisor inicia o reenvio

No Console, abra uma sessão In Review ou Declined e clique em Solicitar Reenvio. Selecione quais etapas precisam ser refeitas.
2

Os dados anteriores são arquivados

O sistema redefine os recursos selecionados e marca os dados anteriores como previous_attempt, preservando a trilha de auditoria completa.
3

O usuário é notificado

Se houver um e-mail disponível, o usuário recebe um e-mail localizado com um link direto para retomar.
4

O usuário refaz etapas específicas

O usuário repete apenas as etapas que foram sinalizadas, e não a verificação inteira.
5

O sistema reavalia

Após a conclusão, a sessão passa automaticamente para "Approved", "Declined" ou "In Review".

Payload do webhook de reenvio

reasons associa cada node_id reenviado ao código de aviso do registro mais relevante daquela etapa (os mesmos códigos que a decisão informa), para que você possa associá-lo aos seus próprios textos. Também é o código que a tela de reenvio do fluxo hospedado e o e-mail de reenvio usam para exibir ao usuário uma mensagem no idioma dele, exceto nos avisos que revelariam um sinal de triagem ou de fraude (duplicatas, AML, lista de bloqueio, verificações entre organizações, integridade de localização e similares): nesses casos, a pessoa vê um motivo genérico, e resubmit_info.reasons no seu webhook sempre traz o código real. Uma etapa sem aviso registrado não tem entrada.

Quais recursos podem ser reenviados?

Qualquer recurso com status diferente de aprovado: Declined, In Review, Not Finished, Not Started ou Expired.
Você pode solicitar o reenvio várias vezes na mesma sessão. Cada ciclo arquiva os dados da tentativa anterior, dando a você visibilidade completa do histórico de verificação do usuário.

Boas práticas

Monitore sessões em revisão

Configure alertas (e-mail ou Slack) no seu Didit Console para ser notificado quando houver sessões que precisam de revisão manual.

Prefira o reenvio

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

Acompanhe os abandonos

Taxas altas de sessões abandonadas ou expiradas podem indicar atrito na experiência do usuário. Considere ajustar o TTL da sessão ou melhorar as orientações ao usuário.

Handlers idempotentes

Os webhooks podem ser reenviados. Use session_id como chave única para garantir que cada mudança de status seja processada apenas uma vez.
Sempre verifique as assinaturas dos webhooks antes de processar os payloads. A Didit oferece três métodos: X-Signature, X-Signature-V2 (recomendado) e o descontinuado X-Signature-Simple, que autentica apenas o envelope e nunca o corpo de decision. Veja Webhooks para mais detalhes.
Última modificação em 1 de novembro de 2026