Verify File (Sync)
Check a single document for evidence of tampering, forgery, or AI generation and wait for the result. This endpoint has a timeout of 5 minutes on both engines. If processing takes longer, the request usually fails with 504 Gateway Timeout, and the response has no runId. Less often it fails with 500 INTERNAL_ERROR and retryable: false, and that error body includes the runId. Either way the run keeps processing in the background, so don’t resubmit the file. verify_agentic runs often take longer than 5 minutes, so use POST /verify_runs for them.
Note: For production workloads, use POST /verify_runs and poll GET /verify_runs/{id} instead. The asynchronous API is more reliable for large files and avoids request timeout issues.
The response is a completed verify_run. Read output.riskLevel for the document-level risk, output.summary for a plain-language explanation, and output.signals for each detected Public Signal with its supporting evidence. An empty signals array means no Public Signals were detected; it is not a claim that the document is authentic.
Beta: Verify is available to organizations enrolled in the beta. Requests from other organizations return 404 NOT_FOUND. Contact support@extend.ai to request access.
For more details, see the Verify guide. See Verify Error Handling for HTTP errors and run failure reasons.
Authentication
Bearer authentication of the form Bearer <token>, where token is your auth token.
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.
Request
The file to verify, as a public URL or an Extend file ID. Verify runs against the exact submitted bytes, so text and base64 inputs are not accepted. Supported inputs are PDF, JPEG, PNG, and WebP files; other types fail with FILE_TYPE_NOT_SUPPORTED.
Configuration for a verify run. Every field is optional on a request, and unknown keys are rejected with 400. Runs echo the resolved configuration, with defaults applied, in config.
An optional object that can be passed in to identify the run. It will be returned back to you in the response and webhooks. Maximum size is 10KB.
To categorize runs for billing and usage tracking, include extend:usage_tags with an array of string values (e.g., {"extend:usage_tags": ["production", "team-eng", "customer-123"]}). Tags must contain only alphanumeric characters, hyphens, and underscores; any special characters will be automatically removed.
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.
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"

