Results and errors

The result

onComplete(result) fires once the server has reached its decision. That decision is authoritative.

type Decision =
  | "approved"
  | "rejected"
  | "new_capture_requested"
  | "manual_review"
  | "pending";

interface VerificationResult {
  decision: Decision;
  status?: string;
  reason?: string;
  caseId?: string;
}

Decision	What it means	What the SDK does
`approved`	The subject passed.	Renders a terminal success screen.
`rejected`	The subject did not pass.	Renders a terminal screen.
`new_capture_requested`	The server wants another attempt.	Shows a retry prompt and re-enters capture on confirmation.
`manual_review`	Queued for a human reviewer.	Renders a terminal screen.
`pending`	No decision yet.	Renders a terminal screen.

Only approved should unlock whatever the verification gates. Treat pending and manual_review as “not yet” — resolve them from your backend against the case, not from the browser.

Correlating with your own records

caseId identifies the verification case. Store it against your user so support requests and any later status change can be reconciled.

Confirm the final state from your backend before granting access. A browser callback tells you what the user saw; it is not a substitute for server-side confirmation, and a client can always be tampered with.

Errors

onError({ error, fatal }) and the error event surface failures. Two typed classes are exported for instanceof checks:

Class	When	Fatal
`TokenExpiredError`	The session token expired. `onExpire` also fires — re-mint and call `resume(newToken)`.	No
`GatewayError`	Any other non-2xx response. Carries `.status` and a best-effort `.body`.	Depends

import { GatewayError } from "idesify/verification";

callbacks: {
  onError: ({ error, fatal }) => {
    if (error instanceof GatewayError) {
      console.warn(error.status, error.body);
    }
    if (fatal) showYourOwnFallback();
  },
}

The fatal flag is what to branch on: a non-fatal error leaves the widget mounted and usable, while a fatal one means the flow cannot continue and you should present your own fallback.

Do not surface error.body to end users. It is diagnostic detail meant for your logs — show your own message instead, and keep the raw payload server-side.

A note on what you can observe

The SDK reports flow progress so you can build a responsive UI around it. It does not report intermediate assessments, and there is nothing in the browser that predicts the outcome. This is deliberate. Identity decisions are made server-side precisely because the browser is an environment your users control, so any signal exposed there could be manipulated. Build against onComplete and your backend, and the design works in your favor.

Getting started

Identity verification

Privacy widgets

Going to production

API reference

The result

Correlating with your own records

Errors

A note on what you can observe

​The result

​Correlating with your own records

​Errors

​A note on what you can observe

The result

Correlating with your own records

Errors

A note on what you can observe