Skip to main content
The public API is versioned in the URL path: every endpoint lives under /api/v1. Integrate against that prefix and you can rely on the guarantees below.

​
What we may change without notice

Within v1, only backwards-compatible changes ship:
  • New endpoints, new optional query parameters, and new MCP tools.
  • New fields added to existing response objects (parse leniently — ignore fields you don’t recognize).
  • New entries in list-valued responses: new source lists in lists_checked and /screen/lists, new match metadata keys.
  • New response headers.

​
What we will not change within v1

  • Removing or renaming existing endpoints, parameters, or response fields.
  • Changing the meaning of sanctioned (a government sanctions-list hit) or flagged (any hit, including crime-intelligence and risk lists).
  • Changing status-code semantics (401 missing/invalid token, 402 payment challenge, 429 rate limit or quota).
Breaking changes ship only as a new version prefix (/api/v2), with v1 kept running through a published migration window.

​
How deprecations are signaled

If an endpoint or version is ever scheduled for removal:
  1. Its responses gain a Deprecation header as soon as the decision is made, and a Sunset header (RFC 8594) with the removal date at least 90 days in advance.
  2. The change is announced on this page and in the affected endpoint’s reference page.
  3. The OpenAPI spec (compliapi.com/openapi.json) marks the operation deprecated: true.
Nothing in the current API is deprecated. The legacy pre-launch /ofac/* routes were removed before the public launch and never had deployed clients; there are no other historical removals.

​
MCP tools

The MCP server follows the same policy: tool names and the sanctioned/flagged semantics are stable within v1, new tools may appear at any time, and any future tool removal would be announced here 90 days ahead.