Simplifying Identity Verification Using Less Infrastructure, More Flexibility & Enhanced Interpretability

Identity verification is becoming more sophisticated, but managing that complexity shouldn’t make it harder for developers and fraud teams to understand what their verification technology is doing or why it’s making a particular decision.

That’s something we’ve heard consistently from customers. Organizations want clearer, more interpretable verification results, more consistent APIs, and greater flexibility to configure verification around their own risk tolerance. They also need an identity stack that can evolve as new documents, fraud techniques, and business requirements emerge.

With the latest release of BlinkID Verify v4000 and the new Verify & Extract v3 APIs, we’re responding directly to those needs. The release introduces more standardized API structures, clearer insight into why verification checks fail, more flexible sensitivity settings, and an extensible architecture designed to make integrations easier to build, understand, and maintain.

For existing customers with self-hosted deployments, v4000 also brings BlinkID extraction and Verify together within a single infrastructure, reducing the operational complexity of running the two capabilities separately.

One Infrastructure for Extraction and Verification

Historically, customers using both BlinkID for document capture and data extraction, and Verify for identity document verification needed to deploy, scale, and maintain separate Docker images. The two products also used different API schemas, adding another layer of complexity for organizations integrating both products or moving from an extraction-only setup to using Extract & Verify together. 

Verify v4000 changes that. BlinkID extraction and Verify now ship within a single Docker container, providing one infrastructure for both capabilities. For engineering teams, that means fewer deployments to maintain and less infrastructure to manage. For the broader business, it creates a simpler path for expanding identity capabilities.

An organization might initially need to capture and extract information from an identity document, for example, but later require document authenticity checks or additional fraud detection as its business grows and the fraud industry evolves. With extraction and verification running on the same underlying infrastructure, adding those capabilities doesn’t require introducing and maintaining an entirely separate deployment. For existing BlinkID customers, it also creates a much faster path to testing Verify capabilities without first standing up separate infrastructure, making it easier to evaluate how document verification and fraud detection could fit into existing workflows. 

More Consistent APIs for Developers

We’re also introducing new Verify & Extract v3 APIs. The v3 API standardizes request and response structures and removes or consolidates a number of legacy fields. Terminology is also more consistent across the API. For example, recommendedOutcome from the Verify response is now expressed more directly as a verification verdict, while legacy match levels have been replaced by sensitivity settings that more clearly describe how verification checks are configured.

Image quality checks have similarly been consolidated across both /extract and /verify endpoints. Instead of managing separate blur, glare, lighting, sharpness, DPI, and tilt match levels, these signals now sit within a unified image quality assessment.

The schema has also been harmonized across the Extract and Verify endpoints, making it easier to work with both capabilities through a consistent structure. For example, imageFront and imageBack are now standardized as imageFirstSide and imageBackSide across both endpoints, while extracted fields use consistent StringResult and DateResult structures, with date results incorporating parsed day, month, and year components. 

These may sound like small changes individually, but consistency matters when identity verification is embedded within complex production environments. Cleaner schemas and standardized terminology make integrations easier to understand and maintain, while giving teams a more consistent framework as they add capabilities.

The goal is ultimately straightforward: developers should spend less time translating between different structures and more time building the identity experiences their businesses need.

More Explainable Verification Results

Simplifying an API isn’t only about making integration easier. It should also make the information coming back from a verification easier to understand and act upon.

This is something we’ve consistently heard from customers: a verification result is most useful when teams can understand not only whether a document passed or failed, but why. Verify v3 responds directly to that need by making verification outcomes more transparent and actionable. 

Verify v3 introduces a simplified top-level response structure with separate statuses for the extraction and verification stages. It also adds a failedChecks array that identifies the specific checks responsible for an unsuccessful verification.

Instead of receiving only a broad outcome, organizations can more easily understand what happened during the verification process.

For example, a verification might fail because of evidence associated with a portrait forgery check or a generative AI check. Surfacing those signals directly gives developers and fraud teams greater context around the decision and makes it easier to determine what should happen next.

That additional visibility becomes increasingly valuable as fraud attacks grow more sophisticated. A rejected document isn’t necessarily the end of the decision. Depending on the reason, an organization may want to request another image, introduce additional verification, send the interaction to manual review, or reject it outright.

Greater Control Over Fraud and Conversion

There is no universal verification threshold that works for every organization, market, or interaction. A financial institution opening a high-value account may have a very different risk tolerance than a retailer verifying an identity for a lower-risk interaction. Even within the same organization, verification requirements may change depending on geography, product, customer type, or risk level.

Verify v3 standardizes default model sensitivity settings to give businesses greater flexibility to tune verification checks around their specific risk tolerance. Where a model may previously have used a default sensitivity of level 2, for example, v3 moves the default to level 5, providing more room to adjust sensitivity both higher and lower depending on the use case. 

Making verification more restrictive isn’t automatically better. Excessively aggressive settings can create false rejections and unnecessary retries for legitimate customers. Settings that are too permissive can increase fraud exposure.

Greater control allows businesses to tune verification around their own risk profile rather than forcing every identity interaction through the same rigid decision process.

Better Feedback When Something Goes Wrong

Not every unsuccessful identity verification is fraud. Sometimes the problem is much simpler: an image is blurry, glare obscures the document, a barcode isn’t readable, or part of the document has been cropped out of the image.

Verify v3 introduces revised warning and informational messages designed to provide more consistent feedback about these situations. The system can identify issues such as poor image quality, missing document sides, unreadable barcodes, cropped documents, and expired IDs.

For developers and support teams, clearer feedback can make problems easier to diagnose. More importantly, it creates an opportunity to help legitimate users recover from avoidable verification problems rather than simply presenting them with a failed result.

That’s an important distinction. Improving fraud detection is only one side of identity verification. Helping legitimate customers successfully complete verification is the other.

An Architecture Designed to Keep Up With Changing Documents

Governments continually introduce new identity documents, redesign existing ones, and update security features. For businesses operating across multiple markets, maintaining support for those changes can create an ongoing engineering burden.

The v3 APIs have been designed to make that process easier. Enum constraints will be replaced with more extensible OpenEnum schemas, allowing additional document coverage to be introduced through template updates between regular BlinkID deployments without requiring a breaking schema change.

Document coverage is consistently one of the most important requirements for organizations operating across multiple markets. With this more extensible approach, Microblink can roll out support for additional documents in a matter of weeks rather than waiting months for a larger deployment cycle. 

The release also updates the underlying extraction engine of Verify to BlinkID v8001, expanding support for new documents and document versions while improving OCR accuracy.

For customers, the benefit is less disruption as document coverage evolves. Instead of treating every new document type as another integration project, the underlying platform can continue expanding while the core integration remains stable.