> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.idenfy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Status Handling

> How to branch your integration logic on iDenfy verification statuses, including when to trust a result and how to handle SUSPECTED.

Every verification resolves to an overall status, delivered via [webhook](/kyc/webhooks) or fetched via [Data Retrieval](/kyc/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](/guides/dashboard/kyc/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](/kyc/webhooks#webhook-events-and-timing) for exactly which events carry which `final` value and when they fire.

## What To Do With Each Status

| Status                                     | Your action                                                                                                                                                                                                                                                                                                                     |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `APPROVED`                                 | Onboard the user.                                                                                                                                                                                                                                                                                                               |
| `DENIED`                                   | Reject, or have the user start a new verification session to retry. A tag-driven denial may be clearable from the dashboard instead — see [Resolving a SUSPECTED or DENIED Result](#resolving-a-suspected-or-denied-result) below. [Request Update](/kyc/request-update) does not apply to `DENIED` — see that section for why. |
| `SUSPECTED`                                | Not a failure — see [Suspected Status](/kyc/suspected-status) for why this happens and how to evaluate it.                                                                                                                                                                                                                      |
| `REVIEWING`                                | Wait. A human reviewer is still working the case; no action needed until a final webhook arrives.                                                                                                                                                                                                                               |
| `EXPIRED` / `ACTIVE`                       | The token was never completed. Generate a new session if the user still needs to verify.                                                                                                                                                                                                                                        |
| `DELETED` / `EXPIRED-DELETED` / `ARCHIVED` | Verification data is no longer available — treat as out of scope for further checks.                                                                                                                                                                                                                                            |

## 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:

| Field                             | What to check                                                                                      |
| --------------------------------- | -------------------------------------------------------------------------------------------------- |
| `fraudTags`                       | Fraud indicators detected (e.g. `AML_SUSPECTION`, `DUPLICATE_FACE`, `FACE_IN_BLACKLIST`).          |
| `mismatchTags`                    | Data submitted at session creation that doesn't match the document (e.g. `NAME`, `DATE_OF_BIRTH`). |
| `autoDocument` / `manualDocument` | Automated and (if reviewed) manual document validation results.                                    |
| `autoFace` / `manualFace`         | Automated and (if reviewed) manual face-match results.                                             |

For the full list of every possible value these fields can take, see [Verification Statuses](/guides/dashboard/kyc/verification-statuses) — Face Status, Document Status, Fraud Tag, and Mismatch Tag values.

<Tip>
  iDenfy surfaces these tags but does not decide whether they're disqualifying — that's your call. See [Suspected Status](/kyc/suspected-status) for worked examples of how tags produce `SUSPECTED`, and for how to build your own evaluation procedure.
</Tip>

## 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](/guides/dashboard/kyc/resolving-false-positives-removing-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 integration** — [Request Update](/kyc/request-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.


## Related topics

- [Suspected Status](/kyc/suspected-status.md)
- [KYC Webhooks](/kyc/webhooks.md)
- [ID Verification (KYC)](/kyc/overview.md)
- [List identifications](/api-reference/kyc-verifications/list-identifications.md)
- [KYB iFrame](/kyb/iframe.md)