Revisión Manual

in_review significa que una persona en Inyo decide el resultado. No es una falla y no es una respuesta final, y puede llegarle por cualquiera de los dos puntos de entrada — incluso en la respuesta síncrona de POST /v1/verifications y en una redirección a la que llega su cliente.

Por Qué una Verificación Está in_review

auto_status le indica qué decidió el pipeline antes de cualquier enrutamiento o decisión humana, de modo que in_review nunca es ambiguo:

Lea auto_status antes de decidir cómo tratar una sesión retenida en su propio producto. Una aprobación límite y un rechazo retenido son señales muy distintas, aunque ambas lleguen como in_review.

Enrutamiento de una Aprobación Límite

Un umbral de revisión configurado captura las autoaprobaciones cuya confianza cae por debajo de su barrera y las enruta a revisión en su lugar. Se aplica de forma idéntica a las sesiones del widget y a las verificaciones server-to-server — una sola configuración, una sola decisión de enrutamiento, sin importar por qué punto de entrada llegó la verificación.

La confianza es la puntuación más débil entre las verificaciones que llevan una medida calibrada por captura, lo cual depende de cómo se obtuvo el resultado de liveness:

Ambas verificaciones contabilizadas son verificaciones duras que ya deben superar sus propios umbrales para que una verificación sea aprobada. Por lo tanto, un umbral de revisión igual o inferior a ese piso nunca puede activarse — configurar uno se rechaza con un mensaje que indica el piso calculado. Y como el piso se mueve con sus propios umbrales, lea los valores actuales del detail de cada verificación en lugar de asumir los valores por defecto de la plataforma.

liveness se excluye deliberadamente en el modo selfie: allí su puntuación es una heurística de calidad de imagen sobre la confianza del rostro, la nitidez y el brillo, así que enrutar con base en ella convertiría esto en una barrera de calidad fotográfica en lugar de una barrera de confianza. Sigue siendo una verificación dura en cualquier caso — una captura deficiente igual se rechaza; simplemente no impulsa el enrutamiento a revisión.

Una verificación sin selfie no lleva ninguna puntuación biométrica. Eso cuenta como no medida, no como confiable, así que con un umbral configurado se enruta a revisión en lugar de autoaprobarse. Envíe una selfie, o deje el umbral sin configurar, si necesita que las verificaciones de solo documento se decidan de forma síncrona.

Retener un Rechazo para un Humano

El umbral de revisión captura las aprobaciones límite. Una configuración separada — desactivada por defecto — captura los rechazos: una verificación que las verificaciones rechazaron se enruta a in_review en lugar de declined, de modo que un analista la confirme antes de que sea definitiva. Un falso rechazo pierde a un cliente real en silencio, y ese es el caso para el que esto existe.

Lo que cubre es todo aquello que un humano podría completar. Un rechazo se retiene cuando el documento era legible — vencido, discrepancia de rostro, liveness, jurisdicción rechazada, autenticidad fallida, recaptura de pantalla. No se retiene cuando los campos centrales de identidad nunca salieron del documento, porque aprobar tal sesión entregaría una identidad verificada sin nada dentro; esas siguen autorechazándose, y un analista tampoco puede aprobar una.

Esto se comporta igual en ambos puntos de entrada. El widget ofrece una nueva toma ante problemas de captura recuperables y server-to-server no, pero esa diferencia tiene que ver con guiar a un cliente en vivo — no cambia lo que significa su configuración.

La carga no tiene límite. Cada rechazo retenido se convierte en una tarea de analista y nada regula esa cola, así que con esta configuración activada, el volumen de revisión escala con la cantidad de fraude que usted atraiga.

Cómo le Llega la Decisión

Cuando un analista decide, el resultado almacenado se actualiza en el mismo lugar y se reenvía.

El resultado entregado lleva un 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 y auto_status en el nivel superior cuentan la misma historia: después de una decisión, status es el resultado humano y auto_status sigue mostrando lo que concluyó la automatización.

Los Resultados Completados Pueden Cambiar

Una verificación que ya alcanzó approved o declined puede revertirse más tarde mediante un override de control de calidad. Llega por el mismo canal, con manual_review.action establecido en override.

Por eso importa el orden: aplique el notified_at más alto e ignore cualquier cosa anterior (vea Recepción de Resultados). Una sesión puede tener dos entregas en curso a la vez — una todavía reintentándose mientras se despacha una decisión más reciente.

Qué Construir

Si ni el umbral de revisión ni los rechazos retenidos están configurados para su tenant, in_review igual ocurre — una verificación blanda fallida lo produce — así que maneje el estado de todos modos.

Próximos Pasos

• Verificaciones y Decisiones — qué verificaciones son blandas y se enrutan aquí
• Configuración del Tenant — configurar el umbral de revisión y los rechazos retenidos
• Recepción de Resultados — entrega, firmas y ordenamiento