Skip to main content
Version: v2

Interpret the response

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

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

Pass or fail a document​

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

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

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

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.
  • optionsUsed and useCaseUsed: the configuration used with the request.
  • runtime: timing, version, and trace ID.
Last updated on