---
Source: https://docs.microblink.com/verify/configuration
Title: Configuration
Description: Explanation of the Verify API configuration options
---

# Configuration

You configure each verification by passing a configuration object in the request body.

The configuration object has two main components: use cases and options. Use cases are presets of options. 

Start with use cases for high-level behavior, and use options for fine-grained tuning when you need it.

## Use cases

```json title="Request body"
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  // highlight-start
  "useCase": {
    "captureConditions": "Basic",
    "verificationContext": "Remote",
    "documentVerificationPolicy": "Permissive",
    "manualReviewStrategy": "RejectedAndAccepted",
    "manualReviewSensitivity": "Default"
  }
  // highlight-end
}
```

```bash
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
```

Use cases are the highest-level way to configure Verify.

Rather than exposing every setting individually, `useCase` asks high-level questions about your integration—how documents are captured, how you balance fraud prevention against user conversion, whether you can perform manual review—and adjusts Verify's behavior accordingly.

### Use case parameters

- Capture conditions: how much control you have over the end user's capture process.
- Verification context: whether verification happens remotely or in-person.
- Document verification policy: whether you prioritize conversions or fraud prevention.
- Manual review strategy: whether manual review is enabled, and under what conditions.
- Manual review sensitivity: how aggressively the system routes documents to manual review.

For possible values, see the [UseCase reference](/verify/api/ref/v2#model/DocumentVerificationUseCaseOptions).

#### Capture conditions

The capture conditions tell Verify what the end user's capture process looks like and whether you use a client-side SDK.

You can pick between `Basic` and `Hybrid`.[^1]

The main difference is in how cropped images are treated: the basic mode will never allow a cropped image to [pass](./response.md#pass-or-fail-a-document) as cropping is a form of digital tampering.
However, if you have control over the cropping itself, and therefore want to allow cropped images, the hybrid mode will allow cropped images to be fully processed and to pass.

<Tabs queryString="requestFormat">
  <TabItem value="json" label="application/json" default>

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "useCase": {
      "captureConditions": "Basic"
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```

  </TabItem>
  <TabItem value="form-data" label="multipart/form-data">

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form CaptureConditions=Basic
  ```

  </TabItem>
</Tabs>


#### Verification context

The verification context tells Verify if the check is a remote one, or in person.

Some document checks only make sense if they are performed remotely.
If the end user is being verified in person (for example, physically providing their ID to a bank employee), then some checks are not needed because a human who is also checking the ID will spot irregularities.

For example, a human will immediately see a photocopy of an ID, and so Verify does not need to check if the ID is a photocopy.

Your verification context can be `Remote` or `InPerson`. [^2]

Depending on how you expect to use Verify (with a human agent in the loop, or without one), set up the context accordingly.

<Tabs queryString="requestFormat">
  <TabItem value="json" label="application/json" default>

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "useCase": {
      "verificationContext": "InPerson"
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```

  </TabItem>
  <TabItem value="form-data" label="multipart/form-data">

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form VerificationContext=InPerson
  ```

  </TabItem>
</Tabs>

Here's a visualization of how changing the verification context use case changes the underlying options:


<!-- interactive component omitted -->


#### Document verification policy

The document verification policy determines your overall preferences around how strict the checks should be.

You can choose between:

- `Permissive`
- `Standard`
- `Strict`
- `VeryStrict`

These are presets that determine the threshold of individual underlying checks overall.

The central trade-off is pass rate versus fraud detection.

The more permissive your environment, the more lax the checks can be; if it's highly permissive, you can set the policy to `Permissive`.

The more risk-averse the environment, the stricter the checks must be, at the cost of potentially flagging legitimate documents and slowing down the pass rate.
If you're optimizing for high accuracy instead, opt for `Strict` or `VeryStrict`.

`Standard` is a good balance and is the default value.

<Tabs queryString="requestFormat">
  <TabItem value="json" label="application/json" default>

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "useCase": {
      "documentVerificationPolicy": "Standard"
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```

  </TabItem>
  <TabItem value="form-data" label="multipart/form-data">

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form DocumentVerificationPolicy=Standard
  ```

  </TabItem>
</Tabs>

Here's a visualization of how changing the verification policy use case changes the underlying options:


<!-- interactive component omitted -->


#### Manual review strategy and sensitivity

BlinkID Verify is commonly used as a filtering system: you first pass all the IDs through the API, and then you route certain ones to manual review, where a human or other agent performs additional checks.

Verify supports such a workflow with the manual review strategy and manual review sensitivity use cases.

The outcome of this configuration is in the [recommended outcome](./response.md#check-the-recommended-outcome) field.

Your manual review strategy can be:

- `Never`: you don't have a manual review step, and therefore only use `Accept` or `Reject` values
- `RejectedAndAccepted`: documents which are on the verge of being either rejected or accepted can land in manual review
- `RejectedOnly`: only documents that are on the verge of being rejected can land in manual review
- `AcceptedOnly`: only documents that are on the verge of being accepted can land in manual review

With that, your manual review sensitivity can be `Low`, `Default`, or `High`.
For each document verification, we run a series of [checks](./check.md) which have a certainty score associated with them.
If you set your sensitivity to `High`, you catch more borderline results (documents with low and medium certainty).
Conversely, if you set the sensitivity to low, fewer documents will land in manual review (only those documents with low certainty on their checks).

By default, Verify uses the default sensitivity settings, and is triggered on both almost rejected and almost accepted documents.


<Tabs queryString="requestFormat">
  <TabItem value="json" label="application/json" default>

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "useCase": {
      "manualReviewStrategy": "RejectedAndAccepted",
      "manualReviewSensitivity": "Default"
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```

  </TabItem>
  <TabItem value="form-data" label="multipart/form-data">

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form ManualReviewStrategy=RejectedAndAccepted --form ManualReviewSensitivity=Default
  ```

  </TabItem>
</Tabs>

### Default use cases

Every request uses the default use cases, unless you override them. The default values are:

- Capture conditions: `Basic`
- Verification context: `Remote`
- Document verification policy: `Standard`
- Manual review strategy: `RejectedAndAccepted`
- Manual review sensitivity: `Default`

## Options

```json title="Request body"
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  // highlight-start
  "options": {
    "anonymizationMode": "ImageOnly",
    "barcodeAnomalyMatchLevel": "Level1",
    "returnSignatureImage": true
  }
  // highlight-end
}
```

```bash
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
```

Options give you more granular control than use cases.

Use options when you have specific requirements: accepting expired documents, changing image return formats, or tuning the sensitivity of individual checks.

All available options are listed in the [API reference](/verify/api/ref/v2#model/DocumentVerificationProcessingOptions).

Options can roughly be divided into match level options and other options.

### Match level options

Most options are **match level options**: 

- `screenMatchLevel`
- `photocopyMatchLevel`
- `barcodeAnomalyMatchLevel`
- `photoForgeryMatchLevel`
- `staticSecurityFeaturesMatchLevel`
- `dataMatchMatchLevel`
- `generativeAiMatchLevel`
- `blurMatchLevel`
- `glareMatchLevel`
- `lightingMatchLevel`
- `sharpnessMatchLevel`
- `handOcclusionMatchLevel`
- `dpiMatchLevel`
- `tiltMatchLevel`

A match level option controls how strictly individual checks are applied.
Levels range from `Level1` (least strict) to `Level10` (most strict).
They can also be set to `Disabled` to skip the check entirely.

For example, if you're particularly concerned about photocopies, set `photocopyMatchLevel` to `Level10`.

<Tabs queryString="requestFormat">
  <TabItem value="json" label="application/json" default>

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "options": {
      "photocopyMatchLevel": "Level10"
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```

  </TabItem>
  <TabItem value="form-data" label="multipart/form-data">

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form PhotocopyMatchLevel=Level10
  ```

  </TabItem>
</Tabs>

Higher strictness catches more sophisticated fraud, but also increases the chance of rejecting legitimate documents due to minor imperfections.

### Returning images in the response

You can return images in the response.
Note that this increases the size of the response.

You can return the image of the face, the full document image, or the image of the signature.
You can also control the image return format.
The relevant options are:

- `returnFullDocumentImage`
- `returnFaceImage`
- `returnSignatureImage`
- `returnImageFormat`

Some examples:

<Tabs queryString="requestFormat">
  <TabItem value="json" label="application/json" default>

  **Return only face image as PNG**

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "options": {
      "returnFaceImage": true,
      "returnImageFormat": "Png"
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```
  **Return signature image as JPG**

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "options": {
      "returnSignatureImage": true,
      "returnImageFormat": "Jpg"
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```

  </TabItem>
  <TabItem value="form-data" label="multipart/form-data">

  ```bash title="Return face image as PNG"
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form ReturnFaceImage=true --form ReturnImageFormat=Png
  ```

  ```bash title="Return signature image as JPG"
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form ReturnSignatureImage=true --form ReturnImageFormat=Jpg
  ```

  </TabItem>
</Tabs>

### Image quality interpretation

When document images don't fully meet [image requirements](./image-requirements.md), checks may fail not because of fraud but because of poor capture quality.
`ImageQualityInterpretation` controls how Verify handles this ambiguity.

For example, if a document number is obscured, data checks will fail—Verify cannot tell whether this is intentional or accidental.
Similarly, image artifacts may be visually indistinguishable from physical tampering.

Some checks are not affected: if a barcode can be read, barcode data checks run to completion regardless of image quality.

The possible values are:

- `Ignore`: always make a fraud verdict for supported documents, regardless of image quality issues.
- `Conservative` (default): don't make `Pass` or `Fail` verdicts when image quality issues are detected.
- `HighAssurance`: fail documents with image quality issues, but never pass them either.
- `HighConversion`: don't make `Fail` verdicts when image quality issues are detected.
- `VeryHighConversion`: tolerate even more issues before making explicit `Fail` verdicts.

<Tabs queryString="requestFormat">
  <TabItem value="json" label="application/json" default>

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "options": {
      "imageQualityInterpretation": "HighConversion"
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```

  </TabItem>
  <TabItem value="form-data" label="multipart/form-data">

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form ImageQualityInterpretation=HighConversion
  ```

  </TabItem>
</Tabs>

Verdicts are never inverted—a `Fail` verdict won't become `Pass`, and vice versa.
When Verify can't make a verdict, the overall fraud check becomes `NotPerformed`, which maps to a `Retry` [recommended outcome](./recommended-outcome.md).

### Expiration

You can treat expiration as fraud by setting `treatExpirationAsFraud` to true.

This will `Fail` all documents which have expired.

<Tabs queryString="requestFormat">
  <TabItem value="json" label="application/json" default>

  ```json title="Request body"
  {
    "imageFront": {
      "url": "https://example.com/id-front.jpg"
    },
    "imageBack": {
      "url": "https://example.com/id-back.jpg"
    },
    // highlight-start
    "options": {
      "treatExpirationAsFraud": true
    }
    // highlight-end
  }
  ```

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json
  ```

  </TabItem>
  <TabItem value="form-data" label="multipart/form-data">

  ```bash
  curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --form ImageFront=@front.jpg --form ImageBack=@back.jpg --form TreatExpirationAsFraud=true
  ```

  </TabItem>
</Tabs>

## See also

- [Scenario-based configuration](./example-configurations.md): worked examples showing how different constraint profiles map to specific configurations.

---

[^1]: For capture conditions, there are also `NoControl` and `Unknown`, but these are deprecated and shouldn't be used.
[^2]: And `Unknown`, but that's a deprecated parameter that will be removed and isn't used.


Last updated on Jun 18, 2026