Skip to main content
Every verification resolves to an overall status, delivered via webhook or fetched via Data Retrieval. This page is about what your integration should do with that status. For what each status and tag value means, see Verification Statuses.

Wait for a Final Result

A webhook or API response can represent a preliminary or a definitive result. Only act on a result once it is final:
  • From the API, check the top-level final boolean.
  • From a webhook, final: true means no further review will follow; final: false means a IDENTIFICATION_MANUAL_FINISHED webhook is still coming.
See Webhook Events and Timing for exactly which events carry which final value and when they fire.

What To Do With Each Status

Handling SUSPECTED

SUSPECTED means the checks may have already passed, but the system found something worth a second look. Before treating it as a rejection, check manualDocument and manualFace — if they read DOC_VALIDATED and FACE_MATCH, the underlying document and face checks succeeded and only the flags below are in question. Inspect these fields to understand why: For the full list of every possible value these fields can take, see Verification Statuses — Face Status, Document Status, Fraud Tag, and Mismatch Tag values.
iDenfy surfaces these tags but does not decide whether they’re disqualifying — that’s your call. See Suspected Status for worked examples of how tags produce SUSPECTED, and for how to build your own evaluation procedure.

Resolving a SUSPECTED or DENIED Result

  • From the dashboard — a reviewer can clear the specific tag that caused the flag. See Resolving False Positives and Mismatch Tags. Removing the tag automatically re-evaluates the status; if it was the only reason for the flag, the status updates to APPROVED without any further API call. This works for both SUSPECTED and DENIED.
  • From your integrationRequest Update reactivates the token, but only for three specific cases: uploading a POA document, completing a Risk Assessment, or answering a Questionnaire. None of those three can produce a DENIED result, so Request Update only ever applies to a SUSPECTED case caused by one of them — never to DENIED, and never to resubmitting the primary ID document or selfie. For anything outside that scope, resolve it from the dashboard, or have the user start an entirely new verification session.