Public API docs

Sanctions screening docs that read like a product, not a control panel.

Integrate sanctions, PEP, and entity-risk checks with a single API. This public reference covers the core endpoints, SDKs, matching model, and operational details buyers and engineers usually need before they trust a screening vendor.

Create free API key OpenAPI / Swagger Download Postman

Base URL

https://api.verifex.dev

Auth

Bearer token

Format

JSON over HTTPS

Published benchmark

122-case published benchmark: 95.5% F1, 100% recall, 91.4% precision.

Quickstart

First request in under a minute

1. Create a free account and generate a live test key.
2. Send a screening request with a name, type, and optional country or date of birth.
3. Read the returned confidence, risk level, source list, and request ID.
4. Move to batch, entity, or audit workflows once the basic call is wired in.

bashexample

curl -X POST https://api.verifex.dev/v1/screen \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Vladimir Putin",
    "type": "person",
    "mode": "broad"
  }'

Quickstart Core endpoints SDKs Coverage Operations Next steps

Quickstart

Start with one clean screening request

The public docs should answer the first commercial and technical questions quickly: how you authenticate, what you send, what comes back, and what proof you get for an analyst or auditor.

Request shape

name

Required. Person or entity name to screen.

type

Optional. Narrow results to person or entity.

mode

exact for strict matches, broad for fuzzy and phonetic matching.

country / date_of_birth

Optional context fields that help reduce false positives and support adjudication.

What you get back

Confidence score and risk level for triage.

Matched source lists, aliases, and identifying fields.

Structured response IDs for downstream audit evidence.

Published benchmark context: 122-case published benchmark: 95.5% F1, 100% recall, 91.4% precision..

jsonexample

{
  "query": { "name": "Vladimir Putin", "type": "person", "mode": "broad" },
  "matches": [{
    "id": "cuid_...",
    "name": "PUTIN, Vladimir Vladimirovich",
    "source": "OFAC",
    "confidence": 100,
    "risk_level": "critical",
    "match_type": "EXACT",
    "aliases": ["PUTIN, Vladimir"]
  }],
  "total_matches": 1,
  "risk_level": "critical",
  "screened_at": "2026-04-25T10:00:00.000Z",
  "request_id": "abc123"
}

Core endpoints

Document the workflows buyers actually compare

Public docs should not lead with internal dashboard utilities. They should make the screening workflows, entity model, and operational surface area legible in one scan.

POST/v1/screen

Screen a person or entity

Single-request sanctions and PEP screening with confidence, risk level, aliases, source attribution, and request IDs.

Use for onboarding, payouts, or manual case review
Supports person/entity filtering, country hints, date of birth, and exact vs broad mode
Returns normalized matches with confidence and source list metadata

POST/v1/screen/entity

Entity + UBO screening

Corporate sanctions screening plus OFAC 50% Rule ownership-chain analysis in a single workflow.

Traverse ownership chains up to configured depth
Returns both name-match results and constructive ownership blocking analysis
Useful for KYB, treasury, payments, and marketplace risk reviews

POST/v1/screen/batch

Batch screening

Submit multiple names in one request when you need throughput without building your own job orchestration.

Same matching options as single screening
Plan-gated batch size limits
Best for nightly reviews, list refreshes, and case queues

GET/v1/entities/search

Canonical entity search

Search the normalized entity graph for transliterations, variants, and canonical IDs before or after a screening call.

Useful for analyst tooling and drill-down workflows
Returns canonical IDs, sanctions status, and similarity
Pairs with entity retrieval and audit evidence flows

SDKs

Keep the installation path obvious

The current public page buries useful SDK information inside a long internal nav. The public version should expose install commands and one minimal usage example per language.

Python

SDK

pip install verifex

pythonexample

from verifex import VerifexClient

client = VerifexClient("vfx_your_api_key")
result = client.screen("Vladimir Putin", type="person")
print(result.risk_level)

Node.js / TypeScript

SDK

npm install verifex

javascriptexample

import { Verifex } from "verifex";

const client = new Verifex("vfx_your_api_key");
const result = await client.screen({
  name: "Vladimir Putin",
  type: "person",
});

Go

SDK

go get github.com/Verifex-dev/verifex-go-sdk

goexample

client := verifex.New("vfx_your_api_key")
result, err := client.Screen(ctx, verifex.ScreenRequest{
    Name: "Vladimir Putin",
    Type: "person",
})

Rust

SDK

cargo add verifex

rustexample

let client = Verifex::new("vfx_your_api_key");
let result = client.screen(ScreenRequest {
    name: "Vladimir Putin".into(),
    type_: Some("person".into()),
    ..Default::default()
}).await?;

Coverage

Explain matching quality and source coverage in plain English

This section exists to answer the commercial trust questions behind technical integration. A good public docs page should make the matching model, transliteration handling, and evidence posture easy to verify.

Coverage

Verifex screens across sanctions and PEP sources with published source attribution and recurring sync schedules. High-value lists like OFAC, EU, UK, UN, DFAT, SECO, and BIS are part of the commercial story, not hidden implementation detail.

Matching

Broad mode includes fuzzy and phonetic matching so transliterations, alias variants, and spelling drift are still caught. Exact mode is available when a customer needs deterministic direct-name behavior for narrow review flows.

Evidence

Responses include structured IDs and match metadata, and the platform layers that into historical queries, audit evidence, and benchmark disclosure. See the published benchmark for the exact false-positive and false-negative profile.

Operations

Surface the non-marketing details teams still need

Rate limits, status checks, and error formats are part of the buying decision for API infrastructure. The public page should expose them cleanly instead of scattering them deep in a long nav.

GET/v1/health

Public health endpoint for service status, connectivity, and source freshness.

bashexample

curl https://api.verifex.dev/v1/health

Error shape

jsonexample

{
  "error": "Description of the error",
  "code": "ERROR_CODE",
  "request_id": "abc123"
}

Operational notes

Authentication: Bearer token on every endpoint except health.

Rate limits: plan-specific. Usage and quota information is available after sign-in.

Bulk workflows: dashboard CSV upload and API batch endpoints both exist, but the API remains the primary product surface.

Full schema: use Swagger or the Postman collection if you need every response field and enum.

Next steps

Move buyers from docs into trust pages

The public docs page should behave like a commercial technical trust page. It needs clean exits into pricing, benchmark evidence, and signup instead of stranding users in documentation chrome.