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

> What each iDenfy verification status means and what to do about it, whether you check it via webhook/API or review it in the dashboard.

Every verification resolves to an overall status. If you have an integration, it's delivered via [webhook](/kyc/webhooks) or fetched via [Data Retrieval](/kyc/data-retrieval); if you work from the dashboard only, it's the status shown on the verification profile. This page is about what to do once you have that status. For what each status and tag value means, see [Verification Statuses](/guides/dashboard/kyc/verification-statuses).

## Wait for a Final Result

A status can be preliminary before it settles. Only act on it once it's final:

<Tabs>
  <Tab title="Dashboard">
    Open the verification profile and check **Final result** under the Partner Information card. While a human reviewer is still working the case, it shows as **Reviewing** — wait until it changes.
  </Tab>

  <Tab title="Webhook / API">
    * From the API, check the top-level `final` boolean.
    * From a webhook, `final: true` means no further review will follow; `final: false` means an `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.
  </Tab>
</Tabs>

## 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 [Handling Suspected](#handling-suspected) below for how to evaluate it.                                                                                                                                                               |
| **Reviewing**                                    | Wait. A human reviewer is still working the case; no action needed until a final status arrives.                                                                                                                                                                                                                              |
| **Expired** / **Active**                         | The verification 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 whether the document and face themselves came back clean — if so, only the tags below are actually in question.

<Tabs>
  <Tab title="Dashboard">
    Open the verification profile and check **Final result details** under the Partner Information card. If the document and face results both come back clean, the underlying checks succeeded and only the tags below caused the flag.
  </Tab>

  <Tab title="Webhook / API">
    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.
  </Tab>
</Tabs>

Inspect these to understand why:

| What            | Why it's there                                                                                                                                                                         |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fraud tags      | Fraud indicators detected — e.g. an AML/watchlist hit or a duplicate face. Shown as **Fraud tags** in the dashboard, or the `fraudTags` field via the API.                             |
| Mismatch tags   | Data submitted at session creation that doesn't match the document — e.g. name or date of birth. Shown as **Mismatch tags** in the dashboard, or the `mismatchTags` field via the API. |
| Document result | The automated, and (if reviewed) manual, document validation result. Part of **Final result details** in the dashboard, or the `autoDocument` / `manualDocument` fields via the API.   |
| Face result     | The automated, and (if reviewed) manual, face-match result. Part of **Final result details** in the dashboard, or the `autoFace` / `manualFace` fields via the API.                    |

For the full list of every possible value, 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 a Suspected result.
</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 action. 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.

## iDenfy Does Not Evaluate Suspected

For Approved and Denied, iDenfy's automated and manual review pipeline commits to a decision on your behalf. Suspected is different by design: iDenfy detects and reports the signal — the specific tag — but does not judge whether that signal disqualifies the user. Whether a name mismatch, an age flag, an AML hit, or a duplicate face should block someone depends on your risk appetite, your jurisdiction, and your product. Those are business decisions only you can make, so iDenfy leaves the result open rather than guessing on your behalf.

## Build Your Own Evaluation Procedure

Because iDenfy won't resolve Suspected for you, treat evaluating it as a required part of your process, not an edge case you'll handle manually the first time it comes up:

1. **Read every tag your configuration can produce** — [Fraud Tags](/guides/dashboard/kyc/verification-statuses#fraud-tags) and [Mismatch Tags](/guides/dashboard/kyc/verification-statuses#mismatch-tags) — and decide, per tag, whether it should auto-approve, auto-deny, or route to manual review.
2. **Write that decision down as an internal procedure** that your team (support, compliance, risk) actually follows, rather than leaving it to ad hoc judgment calls each time a case comes up.
3. **Decide who is authorized to override a Suspected result, and how** — see [Resolving a Suspected or Denied Result](#resolving-a-suspected-or-denied-result) above for the available mechanisms.
4. **Log the decision against the verification's Scan ref** for audit purposes, especially whenever a fraud tag is overridden.

<Warning>
  Treating every Suspected result as an automatic denial rejects legitimate users over cosmetic or explainable mismatches. Treating every Suspected result as an automatic approval defeats the purpose of the checks. Build the procedure — don't skip it.
</Warning>


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