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

## Pass or fail a document

The main field in the response is `verification.verdict`, which tells you if the document is genuine or fraudulent.

```json
{
  "verification": {
    "verdict": "Accept"
  }
}
```

The value of this field can also be `Reject`, which happens when the processed document is fraudulent.

It can also be one of the following:

- `Unverifiable`, where Verify can't make an assessment based on the image.
- `Retry`, where a different image of the same document could resolve an issue.
- `Review`, where the result is borderline, and a human should take a look.

## See which checks failed

The `verification.failedChecks` array lists all the checks that were performed, and that failed, so that you can quickly find the root cause of a verification failure.

The entries are "flattened", like so:

```json
{
  "verification": {
    "failedChecks": [
      "checks.extractedDataCheck.matchCheck.dateOfBirthCheck"
    ]
  }
}
```

## See what was checked on the document

The `verification.checks` object provides a structured breakdown of each individual verification check.

```json
{
  "verification": {
    "checks": {
      "extractedDataCheck": {},
      "documentLivenessCheck": {},
      "visualCheck": {},
      "documentValidityCheck": {}
    }
  }
}
```

Each of these is composed of sub-checks (for the full response schema, see the [API reference](/verify/api/ref/v3-cloud)), and each check resolves to `Pass`, `Fail`, or `NotPerformed`.

```json
{
  "verification": {
    "checks": {
      "extractedDataCheck": {
        "result": "Fail"
      }
    }
  }
}
```

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

## Assess the image

`imageAssessment` reports what the images themselves looked like, separately from the fraud verdict.
It holds three checks: `imageQualityCheck`, `croppedDocumentCheck`, and `handPresenceCheck`.

```json
{
  "imageAssessment": {
    "imageQualityCheck": { "result": "Pass" },
    "croppedDocumentCheck": {
      "result": "Pass",
      "firstSide": { "result": "Pass" },
      "secondSide": { "result": "Pass" }
    },
    "handPresenceCheck": { "result": "Pass" }
  }
}
```

`croppedDocumentCheck` and `handPresenceCheck` also break their result down per side.
This is the object to look at when a verdict is `Retry`: it usually explains why a new image would help.

## Get extracted data

To obtain the extracted data, look in `extraction.result`.

Text fields are keyed by script, so a Latin-script first name is at `extraction.result.firstName.latin`.
Only the scripts actually detected on the document are present.

```json
{
  "extraction": {
    "processingStatus": "Success",
    "result": {
      "firstName": { "latin": "JOHN" },
      "dateOfBirth": { "day": 1, "month": 2, "year": 1990 },
      "documentClassInfo": { "countryName": "Croatia" }
    }
  }
}
```

`extraction.processingStatus` tells you how extraction itself went, independently of the verdict.
`Success` means everything expected was read; other values name what went wrong, such as `MandatoryFieldMissing` or `MrzDetectionFailed`.

For per-side and per-module detail, read `extraction.result.subResults.{side}.{viz,mrz,barcode}`.

For the full schema of possible extraction fields, see the [API reference](/verify/api/ref/v3-cloud).

## Get the images

Any images you enabled in the [configuration](./configuration.md#returning-images) come back in the top-level `images` object, keyed by name, each a base64-encoded JPG:

```json
{
  "images": {
    "face": "/9j/4AAQSkZJRg...",
    "firstSideCropped": "/9j/4AAQSkZJRg..."
  }
}
```

The available keys are `face`, `signature`, `firstSideCropped`, `secondSideCropped`, and `barcode`.

## Confirm what configuration ran

`configurationUsed` echoes the configuration the request actually ran with, resolved from what you sent plus the defaults for everything you left out.
It mirrors the request structure, so a setting's effective value sits at the same path you would use to set it.

Because the schema doesn't declare defaults, this is the reliable way to find out what a default resolves to: send no configuration and read what comes back.


Last updated on Aug 3, 2026