Verifix

Authentication

Bearer API keys, scoped per environment. Sandbox and production keys are separate and never interchangeable. Client-side SDKs receive a short-lived session token, never the API key.

list referred sessions

curl "https://api.verifix.ae/v1/verifications?status=referred&limit=20" \
  -H "Authorization: Bearer $VERIFIX_API_KEY"

Sessions

Orchestrated verification: one call creates a session that runs a whole journey and returns one decision.

Sessions endpoints
Method	Endpoint	Description
POST	/v1/verifications	Create a session for a journey and get a hosted URL or SDK token.
GET	/v1/verifications/{id}	Retrieve the session with per-check results and current status.
GET	/v1/verifications/{id}/decision	Retrieve the final decision object, risk score, and reason codes.
GET	/v1/verifications	List and filter sessions by status, journey, decision, and date range.
PATCH	/v1/verifications/{id}	Correct extracted fields under review, with the edit recorded in the audit trail.
POST	/v1/verifications/{id}/decision	Record a manual decision from your own review tool.
GET	/v1/verifications/{id}/evidence	Download the evidence bundle: images, signals, timings, and decision trail.
GET	/v1/verifications/{id}/report	Generate a PDF compliance report for the session.
DELETE	/v1/verifications/{id}	Delete a session and its media under your retention policy.
POST	/v1/verifications/imports	Import historical verifications from a previous provider with their original evidence.

Standalone checks

Call one module server-to-server when you already have the data and do not need a hosted flow.

Standalone checks endpoints
Method	Endpoint	Description
POST	/v1/checks/document	Authenticate a document image and extract its fields.
POST	/v1/checks/liveness	Evaluate a selfie or short capture for presentation attacks.
POST	/v1/checks/face-match	1:1 compare a selfie against a document portrait.
POST	/v1/checks/face-search	1:N search a face against your verified population.
POST	/v1/checks/screening	Screen a name and date of birth against sanctions, PEP, and adverse media.
POST	/v1/checks/age-estimation	Estimate age from a live capture without collecting a document.
POST	/v1/checks/proof-of-address	Classify and validate an address document.
POST	/v1/checks/contact	Verify an email address or phone number with a one-time code.
POST	/v1/checks/document-ai	Extract custom fields from an arbitrary document and flag tampering.

Business verification

Registry truth, ownership chains, and screening on every human behind an entity.

Business verification endpoints
Method	Endpoint	Description
POST	/v1/businesses/search	Search a registry by name, license, or registration number.
POST	/v1/businesses	Create a business record from a selected registry result.
GET	/v1/businesses/{id}	Retrieve registry data, officers, and ownership graph.
GET	/v1/businesses/{id}/ubos	Resolve ownership to natural persons with percentages and paths.
POST	/v1/businesses/{id}/documents	Attach and classify corporate documents.

Transactions and wallets

Post-onboarding risk: rules, alerts, wallet exposure, and Travel Rule messages.

Transactions and wallets endpoints
Method	Endpoint	Description
POST	/v1/transactions	Submit a transaction for rule evaluation and scoring.
GET	/v1/transactions/{id}	Retrieve the evaluation, rules that fired, and any alerts raised.
POST	/v1/wallets/screen	Screen a wallet address for sanctions and exposure categories.
POST	/v1/wallets/monitor	Register a wallet for continuous re-screening.
POST	/v1/travel-rule/messages	Send or acknowledge originator and beneficiary data for a transfer.
GET	/v1/travel-rule/counterparties	Look up a counterparty VASP and its supported protocols.

Management

Everything the console configures is also addressable from the API.

Management endpoints
Method	Endpoint	Description
GET	/v1/journeys	List journeys and their published versions.
POST	/v1/journeys	Create or publish a journey definition.
GET	/v1/rules	Read the rule set with versions and authors.
GET	/v1/cases	List cases and alerts with owner, severity, and state.
POST	/v1/lists/{list}/entries	Add an entry to a blocklist or allowlist with a reason.
GET	/v1/audit-events	Stream audit log events for your own SIEM.
GET	/v1/webhooks	Manage webhook destinations and rotate signing secrets.
GET	/v1/usage	Per-module usage counts for the current billing period.

Eight states, no ambiguity

A session is always in exactly one of these. Referred is a first-class state, not a failure.

created

Session exists, nothing captured yet.

awaiting_subject

Hosted URL or SDK token issued, waiting on the person.

processing

Capture received, checks running.

referred

A signal needs a human. Sits in the review queue with a reason code.

approved

All checks passed within the journey's thresholds.

declined

A terminal check failed or a rule declined the subject.

abandoned

The subject did not finish before the session expired.

expired

Session lifetime elapsed. Create a new one to retry.

The boring guarantees that matter in production

Idempotency: Send an Idempotency-Key header on every POST. Replaying the same key returns the original response instead of creating a second session or double-billing a check.
Pagination: Cursor-based. List endpoints return data plus next_cursor; pass it as cursor to continue. Limits default to 50.
Errors: HTTP status plus a stable machine code and a human message: 400 invalid_request, 401 unauthenticated, 403 insufficient_scope, 404 not_found, 409 conflict, 422 check_unavailable, 429 rate_limited, 5xx internal_error. Retry only on 429 and 5xx, with exponential backoff.
Rate limits: Per-key limits returned on every response as X-RateLimit-Limit, -Remaining, and -Reset. Burst above the limit returns 429 with a Retry-After header.
Versioning: The version is in the path. Additive changes ship without a version bump; breaking changes get a new version with an overlap period announced on the changelog.

error shape

{
  "error": {
    "code": "invalid_request",
    "message": "journey 'uae_vara_retail' is not published in this environment",
    "field": "journey",
    "request_id": "req_01HZY9T4B2K"
  }
}

Published rate limits and per-check latency targets are set in your plan.

One REST surface for every pillar, documented in the open