OFAC API guide: sources, requests, review, and monitoring

On this page

Choose data access or a screening workflow

OFAC publishes official sanctions data through its Sanctions List Service. A commercial OFAC screening API adds a different layer: subject comparison, result handling, evidence, and an operational review workflow. Calling a commercial endpoint does not mean OFAC has approved the result or endorsed the provider.

Choose direct downloads when your team intends to own ingestion, normalization, matching, testing, freshness, and review integration. Choose a screening service when you need those comparisons and retained results behind an application contract. The build-versus-buy guide makes the responsibilities explicit.

Distinguish SDN from non-SDN coverage

The SDN List and non-SDN sources do not have identical implications. Preserve the authority and underlying list identity with a returned candidate, and assess the applicable restriction separately from identity.

SanctionsKit exposes explicit source selection and versioned packages. Confirm current availability through GET /api/v1/sources using an appropriately scoped key. Its documented identifiers include ofac-sdn and ofac-non-sdn. Do not assume a sandbox package searches production lists.

Start with one synthetic sandbox request

Keep the credential on a trusted backend. Save the request body and a persistent operation ID before calling POST /api/v1/screenings. The example below uses an invented subject and synthetic sandbox coverage. Set SANCTIONSKIT_API_KEY and SCREENING_OPERATION_ID in the trusted process environment; never commit a real key.

curl --fail-with-body --max-time 25 --request POST \
  https://www.sanctionskit.com/api/v1/screenings \
  --header "Authorization: Bearer $SANCTIONSKIT_API_KEY" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: $SCREENING_OPERATION_ID" \
  --data '{"subject":{"name":"Mira Calder","entityType":"person","birthDate":"1984"},"package":"sandbox@1","retention":"standard"}'

Model outcomes before automating downstream actions

A valid response has a screening ID, a supported status, and a matches collection. Route potential_match into the configured review process. Treat no_match as the completed selected-source result, not proof that every compliance check has passed.

Transport failures, unavailable coverage, malformed responses, and unknown statuses remain incomplete. Reuse an idempotency key only for the same operation and unchanged payload. Corrected content needs a new operation; do not accidentally reuse an old result for a different person.

Move retained evidence into the team workflow

Link the screening ID to the customer or supplier reference. Retained results can enter SanctionsKit’s shared history and review queue. Keep candidate decisions, independent approval requirements, and the separate business disposition visible.

For portfolios, use the documented batch workflow and inspect failed rows individually. For selected continuing relationships, monitoring retains the subject for scheduled and qualified source-triggered rescreening. Both affect the production allowance; opening an existing result is not a new screen.

Choose a language implementation

The developer guide directory includes Node.js, Python, PHP, Ruby, Go, Rust, Swift, Java, and C# clients, plus source-specific tutorials. They use HTTP directly rather than inventing an official SDK.

Validate the exact contract against the published OpenAPI document.
Test potential matches, no matches, malformed responses, and API errors.
Keep credentials, identity details, and raw evidence out of routine logs.
Verify required sources and subject-type compatibility before going live.
Retain identity and business decisions separately from the original screening outcome.