New: our AI Agent is live — 140+ live registry connections, KYB without an integration. Try it →
On this page

What the KYB API does and does not do

This page sets expectations before you build. The Know Your Customer Limited Public API v2 gives you authoritative company data, resolved ownership, screening, and identity verification through one set of endpoints. Knowing where its scope ends is as useful as knowing what it returns, so this page is deliberately plain about both. For the concepts and the full contract, see the Guide and the API Reference.

Compliance decisions stay yours

The API gives you the verified facts: the company’s registry record, its ownership structure and UBOs, the documents, and the AML screening result. You decide what those facts mean for your obligations. The API does not make your compliance decision for you unless you have configured it to as part of a workflow you own, in which case the decisioning follows the rules you set.

You record your outcome on the case (for example accepting or rejecting it), and the case keeps an audit trail of who decided what and when. The judgement is yours; the API gives you a defensible, sourced basis for it.

Sandbox output is for evaluation

The sandbox is a full-fidelity replica of production: the same contract, the same response shapes, the same status progression. That makes it excellent for building and testing. It is not a source of compliance evidence. Sandbox cases, reports, and screening results are for evaluation only and cannot be used for production compliance decisions.

Not for production compliance

Do not rely on any sandbox case, report, or screening result to satisfy a real KYB or AML obligation. When you are ready for real customers, move to production (see Getting to production), where cases run against live registries and live screening lists and the report is the audit-ready record.

Jurisdiction data availability varies

Coverage spans 147 jurisdictions, and each one has its own registry with its own contents. What a registry publishes, and therefore what the API can return, differs from place to place. Some jurisdictions expose rich officer and ownership detail and a full set of documents; others publish less. A particular document or data point may simply be unavailable in a given jurisdiction because the registry does not hold it.

Build for this. Read the fields that are present, treat absent fields as absent rather than as errors, and consult Coverage for what to expect by jurisdiction. Processing time also varies by registry: some return in seconds, others take minutes.

Identity verification uses a specialist provider

When you verify an individual’s identity document, the verification is performed by a specialist third-party identity-verification provider (Au10tix) under the hood, and the verdict is surfaced back to you through the same API. You upload the identity document to the individual’s case and read the result; you do not integrate the provider separately.

Because the verdict comes from the provider, treat its fields (the triggered rule, the forgery tests, the identity report) as provider-supplied and read them defensively, rather than assuming a fixed internal shape. See the Data dictionary for those fields.

eKYC is plan-gated

eKYC is a feature that is enabled per plan. It is available where your plan includes it. In the sandbox it is intentionally not enabled: an eKYC call returns HTTP 409 so you can see and handle the gated path in your integration. Treat a 409 on eKYC as “not enabled for this environment or plan”, not as a transient error to retry. If your production plan includes eKYC, it is enabled there as part of commercial onboarding.

AML-only cases in the sandbox

An AML-only case runs screening without the full company build. In the sandbox, an AML-only case is a documented refusal rather than a simulated case: the sandbox declines it deliberately so the boundary is explicit, instead of returning a fabricated result. This keeps sandbox behaviour honest. AML-only handling is arranged as part of your production configuration where you need it.

Monitoring and alerts

After onboarding, the API can keep screening a customer and raise alerts when new sanctions, PEP, or adverse-media matches appear, and you can set a review date to schedule periodic re-review. Monitoring and alerts are available where enabled for your account. You list alerts, inspect one, and action it, with the outcome recorded for the audit trail. You can consume alerts by polling, or register a webhook so new matches and case events are pushed to your systems as they happen. See AML and ongoing monitoring in the Guide and the Webhooks page.

Getting to production

The sandbox is free and open for building. Production access is arranged through commercial onboarding: you receive production credentials, and you point your integration at the production base URL. The contract does not change between sandbox and production, so the code you build against the sandbox carries straight over. The differences are that production calls real registries and real screening lists, results are the audit-ready record, and registry calls carry the usual charges.

One more boundary worth naming: if something you need sits outside the scope described on this page, or outside what your own team can take on right now, Know Your Customer Limited’s delivery team builds client-specific work on the platform, from integration glue to hosted portals. See Delivery services.

Next step

Build and test for free in the sandbox, then request access to begin commercial onboarding when you are ready for real customers. Questions: help@knowyourcustomer.com.