Skip to main content
POST
Audit a photo for AI generation in one call

Authorizations

Authorization
string
header
required

Secret API key, created in the dashboard under Settings → API. Send it as Authorization: Bearer rk_secret_… from your server only. Publishable keys (pk_live_…) are for the native SDKs and reach the capture endpoints alone. An unknown key returns 401.

Body

multipart/form-data
image
file
required

The photo: image/jpeg, image/png, image/webp, image/heic or image/heif. Up to 4 MB; larger photos go through the regular audit flow.

checks
enum<string>

Which checks to run. Only ai (AI-generated) is answered in one call. Default ai.

Available options:
ai
metadata
string

Your own keys as a JSON object, sent as a string field; returned with the result and in webhooks. Same rules as metadata on POST /v1/verifications.

Example:

"{\"orderId\":\"ORD-4471\"}"

webhook_url
string<uri>

HTTPS URL that receives the result. Same rules as on POST /v1/verifications.

Response

The analysis finished. verdict is set.

An audit as your API key sees it: the verification body with the audit verdict (rial plus the checks that tripped, each with its confidence).

id
string
required
Pattern: ^vfy_[0-9A-HJKMNP-TV-Z]{26}$
status
enum<string>
required

Lifecycle state. pending → first capture flips to partially_captured → analysis sets the verdict and transitions to completed. Terminal: completed, expired, failed. abandoned is a side-branch off pending/partially_captured, reported by the capture screen via POST /v1/verifications/:token/progress when the end user leaves before finishing — NOT terminal: a later capture resurrects the row to partially_captured like any other.

Available options:
pending,
partially_captured,
completed,
expired,
failed,
abandoned
capture_url
string<uri>
required
created_at
string<date-time>
required
expires_at
string<date-time>
required
captures_count
integer
required
Required range: x >= 0
verdict
object

Verdict of an audit (mode: "audit", a file that already existed). Includes the Rial/no Rial result and the checks that tripped. This is an analysis result, not proof of live capture.

location
object

Where the photo was taken, from the device. Absent for uploaded files and when the device reported no fix.

location_match
object

Whether the photo was taken at expected_location. verified within GPS tolerance; no_match somewhere else; ungeocoded when the address or the fix could not be resolved; rejected when the device reported a mock location.

object_match
object

Object-check result. Present when an object check was requested globally or on an image step. With step-only configuration the status is the worst step result and expected_object is omitted. Independent of the fraud verdict.

object_matches
object

Object-check results keyed by image step. Missing capture verdicts yield inconclusive; otherwise each value is the worst context result for the step, ignoring not_applicable when live evidence exists.

condition
object

Condition assessment. Present only when the verification was created with condition_aspects — the free-form tenant-defined aspect names (any language, any domain). score is the one-decimal average of aspect scores; label buckets it (>=7.5 good, >=5 fair, else poor). Independent of the fraud verdict.

video_analysis
object

Analysis of a video-step clip, sampled at one frame per second and run through the same checks a photo gets. Written asynchronously after capture — poll or use webhooks; absent until the worker has run.

ocr_primary
string
similar_photo
object

An earlier verification of yours whose photo matches this one. method: "phash": the perceptual hashes are within threshold (Hamming distance 0–64; 0 is bit-identical) — a re-upload. method: "embedding": the hashes differ but the photos are the same scene by embedding (cosine) and a geometric check confirmed it (inliers) — a screenshot or a crop. Present only when a match was found. It does not change rial: a legitimate re-submission and a recycled photo look the same — your reviewer decides.

answers
object
record_seal
object

Integrity seal over the verification record including answers. Present only when answers exist and sealing is on (seal !== false). The hash proves the stored answers have not changed — it does NOT claim they are true or sensor-attested; answers_provenance carries that distinction explicitly.