Manual Review
A decision of in_review means a person at Inyo decides the outcome. It is not a failure and not a final answer, and it reaches you on either entry point — including on a server-to-server verification, whose assessment can land on it like any other.
Manual review exists only under managed decisioning. Under non-managed decisioning there is no decision field, nothing is queued, and this page does not apply to you.
Why a Verification Is in_review
Your account decides which score bands are sent to a reviewer. Nothing is queued unless you ask — by default a verification is final as scored.
The session's status is completed throughout: it is finished, and only the decision is outstanding.
decision | What happened |
|---|---|
in_review | The session landed in a band you asked to have reviewed. A person is deciding |
approved / declined / inconclusive | Either the score settled it, or a reviewer did — the field reads the same either way |
Which bands are sent for review is set for your account — talk to your Inyo contact to change it.
The Trust Index
Every result carries trustIndex, the verification's score from 0 to 100. The boundaries it is scored against are configuration for your account and are not published on the result.
severity on each check row — critical, high, medium or low, heaviest first — names how much that check weighs. Both the weights and the boundaries are set for your account and can change, so read decision for the outcome rather than deriving one from the score.
How the Decision Reaches You
When an analyst decides, the stored result is updated in place and re-delivered.
| Channel | Behavior |
|---|---|
| Webhook | With a webhookUrl configured, the decided result is POSTed to it — signed exactly like any other delivery. This covers redirect-mode sessions and server-to-server verifications too, via result notifications |
| Read | GET /v1/sessions/{sessionId} for a widget session, GET /v1/verifications/{verificationId} for a verification, each returning the live status and result. This is what you have if you have no webhookUrl |
The decision changes from in_review to the reviewer's outcome. Nothing else about the payload changes shape:
{
"sessionId": "9f1c8e42-7c3e-4f2b-9d7a-2b1e5c8f4a10",
"status": "completed",
"decision": "approved",
"notifiedAt": "2026-07-31T14:41:09.882Z"
}
The result does not say who decided or why. That record is kept, and is available to Inyo staff handling a query about the session — it is not part of the tenant-facing payload.
Completed Outcomes Can Change
A verification whose decision already reads approved or declined can be reversed later by a quality-control override. It arrives through the same channel, as a new decision on the same session.
This is why ordering matters: apply the highest notifiedAt 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
| Requirement | Why |
|---|---|
| A pending state in your own model, distinct from approved and rejected | An in_review decision is neither |
An idempotent result handler keyed on sessionId, resolving by notifiedAt | The same session's result legitimately arrives more than once |
| The ability to reverse a decision you already acted on | A quality-control override can flip a completed outcome |
Build the pending state even if you send nothing for review: a decided verification can still be reopened by a quality-control override, which arrives as in_review.
Next Steps
- Checks & Decisions — every check, and what a failure of each one costs
- Receiving Results — delivery, signatures, and ordering