Manual Review

in_review means a person at Inyo decides the outcome. It is not a failure and not a final answer, and it can reach you on either entry point — including in the synchronous response from POST /v1/verifications and on a redirect your customer arrives on.

Why a Verification Is in_review

auto_status tells you what the pipeline decided before any routing or human decision, so in_review is never ambiguous:

Read auto_status before deciding how to treat a held session in your own product. A borderline pass and a held rejection are very different signals, even though both arrive as in_review.

Routing a Borderline Approval

A configured review threshold catches auto-approvals whose confidence falls below your bar and routes them to review instead. It applies identically to widget sessions and server-to-server verifications — one setting, one routing decision, whichever entry point the verification arrived through.

Confidence is the weakest score among the checks carrying a calibrated per-capture measure, which depends on how the liveness result was obtained:

Both counted checks are hard checks that must already clear their own thresholds for a verification to be approved. A review threshold at or below that floor can therefore never fire — configuring one is rejected with a message naming the computed floor. And because the floor moves with your own thresholds, read the current values from each check's detail rather than assuming the platform defaults.

liveness is deliberately excluded in selfie mode: there its score is an image-quality heuristic over face confidence, sharpness, and brightness, so routing on it would turn this into a photo-quality gate rather than a confidence gate. It remains a hard check either way — a poor capture still declines; it just does not drive review routing.

A verification with no selfie carries no biometric score at all. That counts as unmeasured, not confident, so with a threshold configured it routes to review rather than auto-approving. Send a selfie, or leave the threshold unset, if you need document-only verifications decided synchronously.

Holding a Rejection for a Human

The review threshold catches borderline approvals. A separate setting — off by default — catches rejections: a verification the checks rejected routes to in_review instead of declined, so an analyst confirms it before it is final. A false decline loses a real customer silently, and that is the case this exists for.

What it covers is whatever a human could complete. A rejection is held when the document was readable — expired, face mismatch, liveness, rejected jurisdiction, failed authenticity, screen recapture. It is not held when the core identity fields never came out of the document, because approving such a session would deliver a verified identity with nothing in it; those keep auto-declining, and an analyst cannot approve one either.

This behaves the same on both entry points. The widget offers a retake on recoverable capture problems and server-to-server does not, but that difference is about coaching a live customer — it does not change what your setting means.

The load is uncapped. Every held rejection becomes an analyst task and nothing throttles that queue, so with this setting on, review volume scales with however much fraud you attract.

How the Decision Reaches You

When an analyst decides, the stored result is updated in place and re-delivered.

The delivered result carries a manual_review object:

{
  "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 and auto_status at the top level tell you the same story: after a decision, status is the human outcome and auto_status still shows what the automation concluded.

Completed Outcomes Can Change

A verification that already reached approved or declined can be reversed later by a quality-control override. It arrives through the same channel, with manual_review.action set to override.

This is why ordering matters: apply the highest notified_at and ignore anything older (see Receiving Results). A session can have two deliveries in flight at once — one still retrying while a newer decision is dispatched.

What to Build

If neither the review threshold nor held rejections are configured for your tenant, in_review still occurs — a failed soft check produces it — so handle the state regardless.

Next Steps

• Checks & Decisions — which checks are soft and route here
• Tenant Configuration — configuring the review threshold and held rejections
• Receiving Results — delivery, signatures, and ordering