API documentation

Endpoints

• Name screening

  Screen one name against every list at once. Returns matches from the aggregated list, so every match has the same shape.

  POST /api/v2/search

• Bulk name screening

  Screen many names in one request. Results interleave a summary row per name with its matches.

  POST /api/v2/bulk-search

• Cryptocurrency wallet screening

  Check one address or many against sanctioned and flagged cryptocurrency wallets, with the entity behind a listing where there is one.

  POST /api/v2/wallet-search · POST /api/v2/bulk-wallet-search

• Adverse media screening

  Search news and web sources for negative coverage of a name, scored by what the subject actually did rather than by what the article is about.

  POST /api/v2/adverse-media-search · POST /api/v2/adverse-media-search-raw

• Entry details

  The full published record for an exact name. The response is keyed by source list, and each list has its own fields.

  POST /api/entry-details

• Legacy v1Deprecated

  The original endpoints. Still served, but they cannot see the eleven lists added since, so a v1 search can report a party clear that v2 finds.

  POST /api/v1/search · POST /api/v1/bulk-search

Authentication

Send your API key in the x-api-key header on every request. Keys are created in the dashboard.

x-api-key: YOUR_API_KEY

Bulk name screening, bulk wallet screening, scored adverse media screening and entry details also accept a signed-in user’s bearer token, which is how the dashboard calls them. Unscored adverse media search takes a key only. For an integration, use an API key either way.

Search types

Name screening takes an optional search_type that sets how tolerant matching is. Anything else is rejected with a 400.

Rate limits

Each key has its own per-minute limit, 60 requests a minute unless yours says otherwise. Going over returns 429 with a Retry-After header giving the seconds to wait.

Errors

Errors return the matching status code and a body of { "error": "..." }. A failed request is still recorded against your key.

Usage tracking

Every v2 response carries an api_usage_id, the identifier of the usage record written for that call. Keep it if you need to tie a screening decision back to the exact request and response we hold.

You can also send an additional_call_info object on any v2 request. It is stored alongside the usage record and returned in your screening history, which is the place to put your own reference for the check.

{
  "prompt": "John Smith",
  "additional_call_info": {
    "customer_id": "CUS-4192",
    "reviewed_by": "onboarding-team"
  }
}