START HERE

Sanctions screening API quickstart: your first request

Create a sandbox API key, send one request, and follow the evidence into your dashboard.

Updated

1

Get your sandbox API key

Your key belongs on your server.

Dashboard → API keys → Sandbox → Create key

Open API keys

Open API keys in your dashboard and select Sandbox. Create a key with screenings:write and results:read. Add sources:read and usage:read when your integration needs source discovery and allowance checks.

Copy the key when it appears and keep it in server-side configuration. If you do not have an account yet, sign up and create your organization first. The sandbox uses invented records and never consumes paid production allowance.

  • Sign up and create your organization.
  • Open API keys, select Sandbox, and create a scoped key.
  • Copy the secret once. Keep it out of browser code and source control.
2

Make your first API call

Replace YOUR_SANDBOX_KEY with the secret you just copied, then run these commands in a trusted terminal. Alex Morgan is a fictional sandbox subject.

Keep REQUEST_KEY and the request body unchanged if you retry after a timeout. Create a new request key for a new screening.

Terminal · curl
export SANCTIONSKIT_API_KEY='YOUR_SANDBOX_KEY'
export REQUEST_KEY="quickstart-$(date +%s)"

curl --fail-with-body https://www.sanctionskit.com/api/v1/screenings \
  -H "Authorization: Bearer $SANCTIONSKIT_API_KEY" \
  -H 'Content-Type: application/json' \
  -H "Idempotency-Key: $REQUEST_KEY" \
  --data '{"subject":{"name":"Alex Morgan","entityType":"person","birthDate":"1984"},"package":"sandbox@1"}'
3

Read the result and open your history

The response wraps the result in data. Follow the screening response reference and save data.id with your own business record. Read data.status, data.matches, data.coverage, and data.versions before taking the next step.

A potential_match belongs in a human review workflow. A no_match means the request completed without a candidate meeting the policy in the selected coverage. An error is a separate outcome, never a no-match result.

  • potential_match: inspect evidence and conflicting fields.
  • no_match: retain the coverage, date, and versions with the result.
  • error: use the error code and request ID to resolve the request.
01Potential match

Compare the evidence and record a review decision.

02No match

Keep the result with its selected coverage and date.

03Request error

Resolve the error before treating the check as complete.

4

Take the next step

Open Screening history in the sandbox dashboard to inspect the retained result. Potential matches enter the shared review queue, where your team can record its decision.

For production, create a production key and choose source IDs or a versioned package. Review plans and allowances, retention, and error handling. Continue with the complete Node.js and TypeScript tutorial or Python tutorial.

Open sandbox history

KEEP BUILDING

Where to go next