---
Source: https://docs.microblink.com/verify/response
Title: Interpret the response
Description: How to interpret and act on BlinkID Verify API responses
---

# Interpret the response

The first two fields in the response are `processingStatus` and `verification`, and they give you the primary actionable insight.

```json
{
  "processingStatus": "Completed",
  "verification": {
    "recommendedOutcome": "Accept",
    "result": "Pass",
    "certaintyLevel": "High",
    "performedChecks": 34,
    "type": "DetailedCheck"
  },
  // ...
```

## Check if processing is complete

Before reading the verification result, check `processingStatus`.
It tells you whether processing completed and, if not, what stopped it.

Only a `Completed` status means that the full verification pipeline ran.

You can see the full list of possible processing statuses [in the API reference](/verify/api/ref/v2#model/ProcessingStatus).

## Pass or fail a document

The `verification` group contains the overall fraud verdict for the document.
Its primary field is `recommendedOutcome`.

### Check the recommended outcome

```json
{
  "recommendedOutcome": "Accept",
  "result": "Pass",
  "certaintyLevel": "High",
  "performedChecks": 34,
  "type": "DetailedCheck"
}
```

`verification.recommendedOutcome` is the field your integration should branch on.
It accounts for the fraud verdict, image quality, document support, and your configured [use case](./configuration.md#use-cases).

- `Accept`: the document is genuine and live—let the user proceed.
- `Reject`: the document is not genuine or not live—block or flag the user.
- `Retry`: the document was found but image conditions weren't good enough to reach a verdict—prompt the user to recapture.
- `ManuallyReview`: the result is ambiguous—route to a human reviewer. 
  You still receive a full verdict and detailed check results to assist the review. 
  Requires manual review to be enabled in your [use case](./configuration.md#use-cases).
- `Undeterminable`: the system could not find a supported document in the images at all—the document type may be unsupported, or image quality was too poor to detect any document. 
  Do not automatically retry.

## See what was checked on the document

The root-level `checks` array provides a structured breakdown of each individual verification check.
This is useful when `recommendedOutcome` is `Reject` and you need to understand why, or when building a manual review interface.

The top-level checks are:

- `VisualCheck`
- `DataCheck`
- `DocumentLivenessCheck`
- `DocumentValidityCheck`
- `ImageQualityCheck`
- `OverallFraudCheck`

Each check resolves to `Pass`, `Fail`, or `NotPerformed`.
Checks are hierarchical: each top-level check groups lower-level checks, which in turn group the underlying models and heuristics.

For pass/fail decision branching, `verification.recommendedOutcome` is sufficient.
`checks` is primarily useful for logging, debugging, and manual review workflows.

For more details about checks, see [Checks](./check.md).

## Other response groups

- `processIndicators`: an array of indicators about image and capture conditions; blur, crop, clarity, and similar factors that affected the result without being direct fraud signals.
- `extraction`: personal data extracted from the document.
- `messages`: human-readable explanations for integrators, present when the verification behaved unexpectedly. 
  See [Response messages](./messages.md).
- `optionsUsed` and `useCaseUsed`: the configuration used with the request.
- `runtime`: timing, version, and trace ID.


Last updated on Jun 18, 2026