Developers

Start your integration with a clear scope.

Review the API structure, required data fields and responses. Define the control flow that fits your product.

Sample data

POST · name screening

// Sent server-side with the secret API key
{
  "subject": {
    "type": "person",
    "name": "Ali Örnek",
    "birth_year": 1978,
    "country": "TR"
  },
  "reference": "customer-2481"
}

200 · sample response

{
  "screening_id": "scr_example_7730",
  "status": "review_required",
  "matches": [
    {
      "candidate": "ALI ORNEK",
      "source": {
        "name": "Sanctions list (sample source)",
        "record_id": "SL-0419",
        "data_as_of": "2026-08-28"
      },
      "matched_fields": ["name", "birth_year"],
      "match_confidence": 0.72,
      "risk_indicator": "high",
      "recommendation": "review"
    }
  ],
  "decision": null
}

422 · validation error

{
  "error": {
    "type": "validation_error",
    "message": "subject.name is required",
    "retryable": false
  }
}
// Retry only errors with retryable=true,
// with the same reference and increasing back-off.

No live endpoint is called; a local sample response is shown.

Getting started

First integration steps.

In four steps, define the scope, set up access securely and implement not only the successful response but also the review and error states.

01
Choose the product.
Define the check you need and its scope.
02
Configure authentication.
Use the API credentials in a secure server environment.
03
Run the sample request.
Follow the usage terms of the test environment.
04
Implement error and review states.
Do not design only the successful response.

Resources

Resources.

API reference
Request fields, response schema and error codes.
Open the documentation
Python SDK
Public package and usage examples.
GitHub repository
System status
Current service information.
Status page

Before production

Check before going to production.

Assess authorisation, rate limits, retry behaviour, logging and sensitive-data handling together with your application's requirements. Features such as webhooks or idempotency should be used only within the scope documented for the relevant endpoint.

AuthorisationSecret key server-side only; never in client code.
Rate limitsImplement limit responses and back-off behaviour.
RetryOnly for retryable errors; with the same reference.
LoggingIdentity and wallet data are masked in logs.
Sensitive data handlingRetention and access consistent with the contract scope.
Review stateA team flow is defined for the "review_required" response.

Frequently asked questions

About integration.

Can I put the API key in a client application?

Do not place secret credentials in publicly accessible client code. Follow the authorisation model of the relevant integration.

Are the sample responses live data?

Documentation examples are labelled as samples. Live product responses and test data are kept separate.

Do you have a technical question?

Share your integration scenario. Let's clarify the required product and data scope together.

Request a technical call