Using the entities API to query nested information

This is the primary way to retrieve a complete picture of a sanctioned person or company, including their sanctions, ownership structures, identification documents, and family connections. For what the nested format looks like and how it works, see our nested entities documentation.

Example#

A request for Alexander Zakharov:

GET /entities/NK-aU5ybkbRFJucf8YMwsJvDw

Returns a response like this (trimmed):

{
  "id": "NK-aU5ybkbRFJucf8YMwsJvDw",
  "schema": "Person",
  "properties": {
    "name": ["Alexander Vyacheslavovich ZAKHAROV"],
    "birthDate": ["1965-09-21"],
    "country": ["ru"],
    "position": ["Owner of LLC CST"],
    "ownershipOwner": [
      {
        "id": "ru-770bdf5f22537fa2a94176f53fa87fe28ecf94fa",
        "schema": "Ownership",
        "properties": {
          "owner": ["NK-aU5ybkbRFJucf8YMwsJvDw"],
          "percentage": ["50"],
          "asset": [
            {
              "id": "NK-abdzbEBkqyT29GyREbiURZ",
              "schema": "Company",
              "properties": {
                "name": ["LLC CST"],
                "country": ["ru"]
              }
            }
          ]
        }
      }
    ],
    "sanctions": [
      {
        "id": "ofac-927f7a4547f68cd05570180fed763dd2d5d8eca7",
        "schema": "Sanction",
        "properties": {
          "authority": ["Office of Foreign Assets Control"],
          "program": ["RUSSIA-EO14024"],
          "country": ["us"],
          "entity": ["NK-aU5ybkbRFJucf8YMwsJvDw"]
        }
      }
    ]
  },
  "datasets": ["gb_fcdo_sanctions", "us_ofac_sdn", "eu_fsf", "ua_nsdc_sanctions"],
  "referents": ["ofac-45937", "gb-fcdo-rus2051", "eu-fsf-eu-12789-10"],
  "target": true,
  "first_seen": "2023-11-02T16:38:16",
  "last_seen": "2026-03-23T12:10:26"
}

The response includes nested Ownership and Sanction entities, the datasets array showing which sources mention this entity, and the referents array listing all source-specific and old IDs that map to this canonical id.

To disable nesting and receive only flat properties with entity IDs, pass nested=false as a query parameter.

Keeping your stored IDs current#

If your system stores references to OpenSanctions entities, for example to keep track of false-positive decisions for screening alerts, those references can go stale when entities are merged during deduplication. (Very briefly: the old canonical id becomes one of the referents on the deduplicated entity.)

The /entities/<id> endpoint returns a 308 redirect to the new canonical ID for as long as the id you provide remains in the referents of the deduplicated entity (six months).

To keep your stored IDs current, periodically look up each stored ID against the /entities/ endpoint. If the response is a redirect, the entity was merged. Update your reference to the new canonical ID from the redirect target.

Old referent IDs are eventually cleaned up and removed from the published data. Once that happens, the API returns a 404 instead of a redirect, and you lose the link to the canonical entity. We recommend checking your stored IDs every three months to stay ahead of this. Avoid running these checks more often than necessary — checking every stored ID every week puts unnecessary load on the API.

Paginating adjacent entities#

Entities with many relationships can produce large nested responses. The /entities/<id>/adjacent endpoint returns the same related entities, grouped by property name, with pagination. Each property group includes a count and a paginated list of related entities.

To paginate a single property, use /entities/<id>/adjacent/<property>. For example, /entities/NK-aU5ybkbRFJucf8YMwsJvDw/adjacent/sanctions returns just the sanctions, paginated.