Bring evidence into your workflow.

Submit a claim, handle the result, and keep the reasoning and sources beside the decision. Start with the same verification endpoint used by the Verity workspace.

Make a request

Set VERITY_API_URL to your API base URL and use an authenticated access token. Your account determines access and credit allowance. Keep credentials on your server, outside public page code.

Generate a unique REQUEST_ID for this operation and retain it. Reuse it with the same request body when recovering an interrupted request.

Example request · curl
curl "$VERITY_API_URL/v1/verify" \
  --request POST \
  --header "Authorization: Bearer $VERITY_ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: $REQUEST_ID" \
  --data '{
    "claim": "The study reports a 12% reduction compared with the control group.",
    "depth": "standard"
  }'

This is an example input, not a checked claim. Sending it to the API starts a verification and can use account credits.

Read more than the verdict.

Preserve the claim, analysis, sources, and any limitations in the response. Display an unavailable score as unavailable; never turn a missing value into zero.

verdict
The returned conclusion. Allow for an unresolved or unverifiable result.
veriscore
When present, the score belongs with its reasoning and evidence. It is not a guarantee of truth.
analysis
The written explanation. Keep qualifying language visible in your interface.
sources
The supplied source records. Preserve their URLs and distinguish discovery links from checked evidence.
Understand VeriScore →

Work with more than one claim.

POST /v1/batch

Submit a claims array with review options. Check each outcome individually, including partial results.

POST /v1/document/verify

Submit extracted document_text for claim review. Text extraction alone is not verification.

POST /v1/extract

Extract reviewable text from a URL or supported document input before deciding what to verify.

Make interruptions understandable.

Show authentication, access, input, and service errors as distinct states. Keep an interrupted request separate from a completed verification.

  • Ask the user to sign in again when their session is no longer valid.
  • Explain an access or credit limit before offering a retry.
  • Respect retry guidance and recover with the original request ID.
  • Never replace a failed request with an invented result or a cached result for a different claim.

Planning an integration?

Tell us about your inputs, volume, and review workflow.

Discuss API access →