Revisão Manual

in_review significa que uma pessoa na Inyo decide o desfecho. Não é uma falha e não é uma resposta final, e pode chegar até você por qualquer um dos pontos de entrada — inclusive na resposta síncrona de POST /v1/verifications e em um redirect no qual seu cliente chega.

Por Que uma Verificação Fica in_review

auto_status informa o que o pipeline decidiu antes de qualquer roteamento ou decisão humana, então in_review nunca é ambíguo:

Leia o auto_status antes de decidir como tratar uma sessão retida no seu próprio produto. Uma aprovação no limite e uma rejeição retida são sinais muito diferentes, mesmo que ambos cheguem como in_review.

Roteando uma Aprovação no Limite

Um limiar de revisão configurado captura auto-aprovações cuja confiança fica abaixo do seu critério e as roteia para revisão. Ele se aplica de forma idêntica a sessões do widget e a verificações server-to-server — uma configuração, uma decisão de roteamento, seja qual for o ponto de entrada pelo qual a verificação chegou.

A confiança é a pontuação mais fraca entre as verificações que carregam uma medida calibrada por captura, o que depende de como o resultado de liveness foi obtido:

Ambas as verificações contabilizadas são verificações rígidas (hard checks) que já precisam superar seus próprios limiares para que uma verificação seja aprovada. Um limiar de revisão igual ou abaixo desse piso, portanto, nunca pode disparar — configurar um é rejeitado com uma mensagem informando o piso calculado. E como o piso se move com os seus próprios limiares, leia os valores atuais no detail de cada verificação em vez de assumir os padrões da plataforma.

liveness é deliberadamente excluído no modo selfie: ali sua pontuação é uma heurística de qualidade de imagem sobre confiança do rosto, nitidez e brilho, então rotear com base nela transformaria isso em um portão de qualidade de foto em vez de um portão de confiança. Ele continua sendo uma verificação rígida de qualquer forma — uma captura ruim ainda é recusada; ela apenas não conduz o roteamento para revisão.

Uma verificação sem selfie não carrega nenhuma pontuação biométrica. Isso conta como não medida, não como confiante, então com um limiar configurado ela é roteada para revisão em vez de ser auto-aprovada. Envie uma selfie, ou deixe o limiar sem definir, se você precisa que verificações apenas de documento sejam decididas de forma síncrona.

Retendo uma Rejeição para um Humano

O limiar de revisão captura aprovações no limite. Uma configuração separada — desativada por padrão — captura rejeições: uma verificação que as checagens rejeitaram é roteada para in_review em vez de declined, para que um analista a confirme antes de se tornar final. Uma recusa falsa perde um cliente real silenciosamente, e esse é o caso para o qual isso existe.

O que ela cobre é tudo aquilo que um humano poderia concluir. Uma rejeição é retida quando o documento era legível — expirado, divergência de rosto, liveness, jurisdição rejeitada, falha de autenticidade, recaptura de tela. Ela não é retida quando os campos centrais de identidade nunca saíram do documento, porque aprovar tal sessão entregaria uma identidade verificada sem nada dentro; esses casos continuam sendo auto-recusados, e um analista tampouco pode aprová-los.

Isso se comporta da mesma forma nos dois pontos de entrada. O widget oferece uma nova captura em problemas de captura recuperáveis e o server-to-server não, mas essa diferença é sobre orientar um cliente ao vivo — ela não muda o que a sua configuração significa.

A carga não tem teto. Cada rejeição retida vira uma tarefa de analista e nada limita essa fila, então com essa configuração ativa, o volume de revisão escala com a quantidade de fraude que você atrai.

Como a Decisão Chega Até Você

Quando um analista decide, o resultado armazenado é atualizado no lugar e reentregue.

O resultado entregue carrega um objeto manual_review:

{
  "session_id": "9f1c8e42-7c3e-4f2b-9d7a-2b1e5c8f4a10",
  "status": "approved",
  "auto_status": "declined",
  "manual_review": {
    "action": "review",
    "reviewer": "analyst-7",
    "reason": "Expiry misread by OCR; document valid through 2029 on the physical card",
    "auto_status": "declined"
  },
  "notified_at": "2026-07-31T14:41:09.882Z"
}

status e auto_status no nível superior contam a mesma história: após uma decisão, status é o desfecho humano e auto_status ainda mostra o que a automação concluiu.

Desfechos Concluídos Podem Mudar

Uma verificação que já chegou a approved ou declined pode ser revertida depois por um override de controle de qualidade. Ela chega pelo mesmo canal, com manual_review.action definido como override.

É por isso que a ordenação importa: aplique o maior notified_at e ignore qualquer coisa mais antiga (veja Recebendo Resultados). Uma sessão pode ter duas entregas em trânsito ao mesmo tempo — uma ainda em retentativa enquanto uma decisão mais nova é despachada.

O Que Construir

Se nem o limiar de revisão nem as rejeições retidas estiverem configurados para o seu tenant, in_review ainda ocorre — uma verificação branda que falhou o produz — então trate o estado de qualquer forma.

Próximos Passos

• Verificações e Decisões — quais verificações são brandas e roteiam para cá
• Configuração do Tenant — configurando o limiar de revisão e rejeições retidas
• Recebendo Resultados — entrega, assinaturas e ordenação