Get Verify Run
Retrieve the status and result of a verify run.
Use this endpoint to poll a run created with POST /verify_runs. When status is PROCESSED, output contains the document-level riskLevel, summary, and detected signals. When status is FAILED, read failureReason and failureMessage.
For a zero-retention run, the first GET that returns the result also schedules its purge, so store what you need from that response.
Authentication
Bearer authentication of the form Bearer <token>, where token is your auth token.
Path parameters
The unique identifier for the verify run.
Example: "vr_xK9mLPqRtN3vS8wF5hB2cQ"
Headers
API version to use for the request. If you’re using an SDK, you can ignore this parameter. If you are not using an SDK and do not specify a version, you will either receive a 400 Bad Request or be set to a previous legacy version. See API Versioning for more details.
The workspace ID to target. Required when using an organization-scoped API key; optional for workspace-scoped keys (the key is already tied to a workspace). See Authentication for details on API key scopes.
Response
The type of object. Will always be "verify_run".
A unique identifier for the verify run.
Example: "vr_xK9mLPqRtN3vS8wF5hB2cQ"
The file that was verified. null once the input file has been deleted.
The status of the verify run:
"PROCESSING"- The document is still being checked"PROCESSED"- Verification completed successfully; readoutput"FAILED"- Verification failed (seefailureReasonfor details)"CANCELLED"- The run was cancelled before it completed
The verification result.
Availability: Present when status is "PROCESSED". For a zero-retention run the result is delivered once, in the synchronous response or the first GET, and purged afterwards; it is purged in any case one hour after the run reaches a terminal status.
The reason for failure.
Availability: Present when status is "FAILED".
Possible values include:
FILE_TYPE_NOT_SUPPORTEDNO_APPLICABLE_SIGNALSPARSE_FAILEDREQUEST_ABORTEDINTERNAL_ERROR
Note: Additional failure reasons may be added in the future. Your integration should handle unknown values gracefully.
A human-readable description of the failure.
Availability: Present when status is "FAILED".
Any metadata that was provided when creating the verify run.
Availability: Present when metadata was provided during creation.
Metrics about the verification process.
Availability: Present when status is "PROCESSED".
The configuration that ran, with defaults applied: the engine, the concrete engineVersion that "latest" resolved to, and advancedOptions.requireParsing as it applied to this run.
Usage credits consumed by this verify run. Always null in the current release: verify runs are not metered during the beta.
An identifier for the request that created the run. For API-created runs this is the request ID, the same value returned as requestId on errors, which you can quote to support.
The time (in UTC) at which the object was created. Will follow the RFC 3339 format.
Example: "2024-03-21T16:45:00Z"
The time (in UTC) at which the object was last updated. Will follow the RFC 3339 format.
Example: "2024-03-21T16:45:00Z"

