Revisão Manual
Uma decision igual a in_review significa que uma pessoa na Inyo decide o desfecho. Não é uma falha e não é uma resposta final, e pode chegar por qualquer ponto de entrada — inclusive numa verificação server-to-server, cuja avaliação pode terminar nele como qualquer outra.
A revisão manual existe somente no decisionamento gerenciado. Sob decisionamento não gerenciado não há campo decision, nada é enfileirado, e esta página não se aplica a você.
Por Que uma Verificação Fica in_review
Sua conta define quais faixas de pontuação vão para um revisor. Nada é enfileirado sem que você peça — por padrão a verificação é final como foi pontuada.
O status da sessão é completed o tempo todo: ela terminou, e só a decision está pendente.
decision | O que aconteceu |
|---|---|
in_review | A sessão caiu numa faixa que você pediu para revisar. Uma pessoa está decidindo |
approved / declined / inconclusive | Ou a pontuação resolveu, ou um revisor resolveu — o campo se lê igual nos dois casos |
Quais faixas vão para revisão é definido para a sua conta — fale com seu contato na Inyo para mudar.
O Índice de Confiança
Todo resultado carrega trustIndex, a pontuação da verificação de 0 a 100. Os limites contra os quais ela é pontuada são configuração da sua conta e não são publicados no resultado.
O severity em cada linha de checagem — critical, high, medium ou low, da mais pesada para a mais leve — nomeia o quanto aquela checagem pesa. Tanto os pesos quanto os limites são definidos para a sua conta e podem mudar, então leia decision para o desfecho em vez de derivá-lo da pontuação.
Como a Decisão Chega Até Você
Quando um analista decide, o resultado armazenado é atualizado no lugar e reentregue.
| Canal | Comportamento |
|---|---|
| Webhook | Com um webhookUrl configurado, o resultado decidido é enviado via POST para ele — assinado exatamente como qualquer outra entrega. Isso cobre também sessões em modo redirect e verificações server-to-server, via notificações de resultado |
| Leitura | GET /v1/sessions/{sessionId} para uma sessão de widget, GET /v1/verifications/{verificationId} para uma verificação, cada um retornando o status e o result atuais. É o que você tem se não tem webhookUrl |
A decision muda de in_review para o desfecho do revisor. Nada mais no payload muda de forma:
{
"sessionId": "9f1c8e42-7c3e-4f2b-9d7a-2b1e5c8f4a10",
"status": "completed",
"decision": "approved",
"notifiedAt": "2026-07-31T14:41:09.882Z"
}
O resultado não diz quem decidiu nem por quê. Esse registro é mantido e fica disponível para a equipe da Inyo que atende uma dúvida sobre a sessão — não faz parte do payload entregue ao tenant.
Desfechos Concluídos Podem Mudar
Uma verificação cuja decision já diz approved ou declined pode ser revertida depois por um override de controle de qualidade. Ela chega pelo mesmo canal, como uma nova decision na mesma sessão.
É por isso que a ordenação importa: aplique o maior notifiedAt 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
| Requisito | Por quê |
|---|---|
| Um estado pendente no seu próprio modelo, distinto de aprovado e rejeitado | in_review não é nenhum dos dois, e seu cliente pode estar esperando em uma landing page que o recebeu |
Um handler de resultado idempotente chaveado por sessionId, resolvendo por notifiedAt | O resultado da mesma sessão legitimamente chega mais de uma vez |
| A capacidade de reverter uma decisão sobre a qual você já agiu | Um override de controle de qualidade pode inverter um desfecho concluído |
Implemente o estado pendente mesmo que não envie nada para revisão: uma verificação concluída ainda pode ser reaberta por uma correção de qualidade, que chega como in_review.
Próximos Passos
- Verificações e Decisões — cada verificação e quanto custa uma falha de cada uma
- Recebendo Resultados — entrega, assinaturas e ordenação