Import counterparties and link customer screening records

Counterparties are saved records for customers, vendors, or other business relationships. Use a stable external reference to connect a saved record with your own system. Two records with the same name are not merged automatically.

During a dashboard import, choose screening only, create saved records, link existing records, or create or link by external reference. Preview the rows and resolve conflicting references before starting the import.

Use results:read for GET /counterparties and GET /counterparties/{id}. The list accepts query, status=active or archived, limit, and cursor. The limit defaults to 25 and can be at most 100. Read the records from data.items and follow nextCursor for more.

A detail response contains data.counterparty and arrays for screenings, monitors, and cases. These arrays preview up to 100 rows each. Use the history endpoint below when you need all the records.

To screen a saved record, send its exact current subject and counterpartyId to POST /screenings, along with coverage and any policy. Use reference for your own operation ID. counterpartyId links the saved relationship; it does not replace subject or allow links across environments.

Only an authorized human reviewer can create, edit, or import counterparties. API clients can read and link them; adding cases:write does not permit edits. If the record is archived or the identity has changed, resolve the conflict in the dashboard before screening or monitoring it.

curl --fail-with-body "https://www.sanctionskit.com/api/v1/counterparties?status=active&limit=100" \
  -H "Authorization: Bearer $SANCTIONSKIT_API_KEY"

Call /counterparties/{id}/history with results:read. Choose kind=screenings, cases, or monitors. Set limit from 1 to 100 and pass each returned cursor until nextCursor is null. Repeat for the other categories if needed. The response shape is {data:{items,total,nextCursor}}. total counts the whole category, not just the current page. All reads stay within your organization and environment.

Keep expired screening states visible. The saved counterparty's current details cannot stand in for earlier evidence. Edits and corrected screenings have their own revisions. If an identity edit pauses a linked monitor, check and update its saved request before resuming it.

curl --fail-with-body "https://www.sanctionskit.com/api/v1/counterparties/$COUNTERPARTY_ID/history?kind=screenings&limit=100" \
  -H "Authorization: Bearer $SANCTIONSKIT_API_KEY"

POST /api/v1/counterparties/intake requires an authorized human reviewer. API keys cannot call it. Send action as create_only, link_existing, or create_or_link, with up to 100 rows. Each row has externalId and subject, with optional label, relationship, and expectedRevision. The idempotent receipt returns its ID and each row's externalId, counterpartyId, and revision. Conflicting identities and archived or changed saved records are rejected.

Quick screening, counterparties, monitoring and bulk intake accept the supported subject fields: name, subject type, country, partial birth date and typed identifiers with optional issuers. The API subject object does not accept an aliases property. Do not invent a day for an uncertain date. Vessel IMO numbers, organization LEIs and aircraft registrations have different formats and comparison rules.

Updating a saved subject does not rewrite historical evidence. Linked monitors pause so their saved request can be reconciled. Match the saved subject and current revision when linking future screens; inspect the original retained request when reviewing an earlier result.

Request and response reference

Frequently asked questions