Skip to main content
Version: v2

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​

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "useCase": {
    "captureConditions": "Basic",
    "verificationContext": "Remote",
    "documentVerificationPolicy": "Permissive",
    "manualReviewStrategy": "RejectedAndAccepted",
    "manualReviewSensitivity": "Default"
  }
}
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.

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

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "useCase": {
    "captureConditions": "Basic"
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

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.

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "useCase": {
    "verificationContext": "InPerson"
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

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

verificationContext
Options affected
Fraud detection
screenMatchLevelLevel5
photocopyMatchLevelLevel5
Response
{
"useCaseUsed": {
"verificationContext": "Remote"
},
"optionsUsed": {
"screenMatchLevel": "Level5",
"photocopyMatchLevel": "Level5"
}
}

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.

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "useCase": {
    "documentVerificationPolicy": "Standard"
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

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

documentVerificationPolicy
Options affected
Verification checks
screenMatchLevelLevel5
photocopyMatchLevelLevel5
photoForgeryMatchLevelLevel2
barcodeAnomalyMatchLevelLevel7
generativeAiMatchLevelLevel5
dataMatchMatchLevelLevel5
staticSecurityFeaturesMatchLevelLevel6
Image quality
blurMatchLevelLevel5
glareMatchLevelLevel5
lightingMatchLevelLevel5
sharpnessMatchLevelLevel3
handOcclusionMatchLevelLevel5
dpiMatchLevelLevel5
tiltMatchLevelLevel5
imageQualityInterpretationHighConversion
Response
{
"useCaseUsed": {
"documentVerificationPolicy": "Standard"
},
"optionsUsed": {
"screenMatchLevel": "Level5",
"photocopyMatchLevel": "Level5",
"photoForgeryMatchLevel": "Level2",
"barcodeAnomalyMatchLevel": "Level7",
"generativeAiMatchLevel": "Level5",
"dataMatchMatchLevel": "Level5",
"staticSecurityFeaturesMatchLevel": "Level6",
"blurMatchLevel": "Level5",
"glareMatchLevel": "Level5",
"lightingMatchLevel": "Level5",
"sharpnessMatchLevel": "Level3",
"handOcclusionMatchLevel": "Level5",
"dpiMatchLevel": "Level5",
"tiltMatchLevel": "Level5",
"imageQualityInterpretation": "HighConversion"
}
}

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

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "useCase": {
    "manualReviewStrategy": "RejectedAndAccepted",
    "manualReviewSensitivity": "Default"
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

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​

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "options": {
    "anonymizationMode": "ImageOnly",
    "barcodeAnomalyMatchLevel": "Level1",
    "returnSignatureImage": true
  }
}
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.

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.

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "options": {
    "photocopyMatchLevel": "Level10"
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

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:

Return only face image as PNG

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "options": {
    "returnFaceImage": true,
    "returnImageFormat": "Png"
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

Return signature image as JPG

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "options": {
    "returnSignatureImage": true,
    "returnImageFormat": "Jpg"
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

Image quality interpretation​

When document images don't fully meet image requirements, 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.
Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "options": {
    "imageQualityInterpretation": "HighConversion"
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

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.

Expiration​

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

This will Fail all documents which have expired.

Request body
{
  "imageFront": {
    "url": "https://example.com/id-front.jpg"
  },
  "imageBack": {
    "url": "https://example.com/id-back.jpg"
  },
  "options": {
    "treatExpirationAsFraud": true
  }
}
curl https://us-east.verify.microblink.com/api/v2/docver --user foo:bar --json @request.json

See also​

Footnotes​

  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