Platform · Developers

The KYB API: counterparty screening in your stack.

The KYCK KYB API exposes everything the platform does through the interface over REST: create counterparties, run screenings, receive webhooks on status changes, and pull audit-ready evidence. Use the platform for the workflow and the API for the plumbing, or drive it all from code.

LAST UPDATED AUG 2026

What the API covers

The KYCK KYB API covers four surfaces: counterparties, creating and updating corporate entities and their people; screenings, running sanctions, PEP and adverse media checks with structured match data; evidence, fetching the timestamped package behind any decision; and webhooks, notifying your systems on completed screenings and status changes.

What a call looks like

A KYCK screening call is a single REST request: POST /v1/screenings with the counterparty's name, jurisdiction and registration number, plus the checks to run, sanctions, PEP and adverse media. The response returns the result, structured match data, a screening timestamp and a URL for the evidence package behind the decision.

POST /v1/screenings
{
  "counterparty": {
    "name": "Atlas Commodities FZE",
    "jurisdiction": "AE",
    "registration_number": "123456"
  },
  "checks": ["sanctions", "pep", "adverse_media"]
}

200 OK
{
  "id": "scr_8f2c41",
  "result": "clear",
  "matches": [],
  "evidence_url": "/v1/screenings/scr_8f2c41/evidence",
  "screened_at": "2026-08-25T09:41:07Z"
}

Responses carry the same evidence objects the platform shows reviewers, so an API-driven clear is exactly as defensible as one clicked in the interface. Match data includes the list, the score and the reasoning, because a score without reasoning is not evidence.

Webhooks: screening as an event

Webhooks treat screening as an event: long-running checks and re-screenings resolve asynchronously, so you register an endpoint and KYCK posts the outcome the moment it lands. Each webhook carries the event type, the screening and counterparty ids, the result and structured match data with list, score and reasoning.

POST https://your.endpoint/kyck  (webhook)
{
  "event": "screening.completed",
  "screening_id": "scr_8f2c41",
  "counterparty_id": "cp_1d94aa",
  "result": "review",
  "matches": [
    {
      "list": "OFAC_SDN",
      "score": 0.87,
      "reasoning": "name and jurisdiction alignment"
    }
  ]
}

A result of review routes the case to your compliance queue inside KYCK, where a human decides with the evidence in front of them. The API never auto-approves what your policy says a person should see.

Authentication and environments

Authentication uses per-environment API keys over HTTPS, and sandbox and production are fully separated environments. Sandbox keys are issued at onboarding, so integration is built and tested against non-production data; nothing touches your live counterparty book until the work moves to production keys.

Integration patterns that work

Four integration patterns work reliably with the KYB API: screening at deal capture, where your trade or order system calls the API before a counterparty goes live; batch re-screening across the book on your schedule; back-office sync into ERPs such as Microsoft Dynamics 365 Business Central; and pulling evidence on demand.

Access

API access is included on Professional and Enterprise plans, which carry the full REST API and webhooks; see pricing for tiers. Lower tiers run the same screening through the platform interface, and full reference documentation plus sandbox keys are provided on onboarding so integration starts against non-production data.

Frequently asked questions

Related reading