Skip to main content

Updates / Deltas

To ensure that your local copies of both the Records and References data are fresh, frequent retrievals of new, updated, and deleted records should be performed by your application.

Request Date​

World-Check On Demand is designed with deterministic responses, even across multiple pages. This means that all pages in a response are based on the state of the records when the first request was made (i.e., the request that generated page #1). This timestamp is returned as the meta.requestDate.

This value from page #1 must be safely stored by your application as this is the maximum starting point for subsequent delta retrievals, ensuring that no publications are missed. You should store and use the request dates for different request types separately.

A sample API response for page #1 showing the meta object details, which includes the requestDate.
"meta": {
        "legalNotices": "https://developers.lseg.com/content/dam/devportal/en_us/product-docs/wcod/legal",
        "requestingUser": "XXXXXXXXXXXXXXXXXX",
        "requestDate": "2025-08-29T02:56:50.763Z",
        "cursors": {
            "previous": "0",
            "next": "gAAAAABosRbzlx0X4nZ79VRXmnTas01HitkS_S98jkExd_LkJjPxenGYKmmftyxBErIAR6I6lnThBzY9us7iCwfztgM6xd_xA-jEVCzyU5nwKCXQ8wlUQys="
        },
        "queryHash": "0803c3f725f67be965edcf4b0c223d9328db29a0926593f6c38b96ceea962e70-MjAyNS0wOC0yOVQwMjo1Njo1MC43NjNa"
    },

Delta Request (New and Updated Records / References)​

BEST PRACTICE

With World-Check On Demand, it is highly recommended to design your application and ingestion to do a delta run for new, updated, and deleted records and references on the highest frequency as possible, such as every 1 minute. This provides two benefits: (a) data freshness at par with LSEG, and (b) fast delta performance as only a small number of records are new/updated/deleted in the past 1 minute.

Every new record or updates to an existing record will have a value in their respective lastPublishedDate indicating when the record or most recent record update was made publicly available by World-Check On Demand. Hence, when requesting for both new and updated records, the lastPublishedDate filter must used in the request payload.

A sample delta request for new and updated records published after the given timestamp.
{
    "criteria": {
        "field": "lastPublishedDate",
        "operator": "gt",
        "value": "2025-08-25T03:00:00.000Z"
    }
}
A sample delta request for new and updated records, but only those with Sanctions keywords.
{
    "query": {
        "queryOperator": "and",
        "criteria": [
            {
                "field": "lastPublishedDate",
                "operator": "gt",
                "value": "2025-08-25T03:05:00.000Z"
            },
            {
                "field": "keywordType",
                "operator": "includes",
                "value": [
                    "wcKeywordType:SANCTIONS"
                ]
            }
        ]
    }
}

The value in the above examples should be the previous requestDate from page #1 of the previous data retrieval session. This approach will ensure that no record published since will be missed. It is possible to have a slightly earlier value than the captured requestDate to create a slight overlap, but your application must ensure that it handles duplicate records gracefully.

Depending on your risk appetite, you can design your application to have multiple deltas for different types of data. For example:

  • A delta every 12 hours for Politically Exposed Persons
  • A delta every 5 minutes for records with Sanctions keywords
  • A daily delta for everything else
  • A weekly delta for everything else again for peace of mind

Once you get page #1 of the new delta, save the requestDate value for the subsequent delta session. This gives you flexibility on your delta schedules.

BEST PRACTICE

Recommended delta retrieval sequence:

  1. Retrieve new schemes using the /newSince parameter with the value of the previous requestDate for the same "new schemes" query in the previous delta run. Save the new requestDate value from page #1 of the response.
  2. Retrieve updated schemes using the /changedSince parameter with the value of the previous requestDate value for the same "updated schemes" query in the previous delta run. Save the new requestDate value from page #1 of the response.
  3. Retrieve new concepts using the /newSince parameter with the value of the previous requestDate value for the same "new concepts" query in the previous delta run. Save the new requestDate value from page #1 of the response.
  4. Retrieve updated concepts using the /changedSince parameter with the value of the previous requestDate value for the same "updated concepts" query in the previous delta run. Save the new requestDate value from page #1 of the response.
  5. Retrieve updated and changed records using the lastPublishedDate filter with the gt operator. Use the previous requestDate value for the same "new/updated records" query in the previous delta run. Save the new requestDate value from page #1 of the response.
  6. Retrieve deleted records using the lastPublishedDate filter with the gt operator and a second filter using the recordStatus field. Use the previous requestDate value for the same "deleted records" query in the previous delta run. Save the new requestDate value from page #1 of the response.

At the end of each run, you should have a new set of six requestDate values from the different queries above.

If you are specifically after new records only, use the initialPublishedDate in the query payload instead. Note that records without any update since initial publication will have a lastPublishedDate value that is equal to the initialPublishedDate.

BEST PRACTICE

Design your application to handle duplicate records gracefully. Duplicate records may appear if you have multiple overlapping deltas across different data types, like the example above. Duplicates are also expected if you are purposely overlapping delta starting points. Duplicates are records with the same UID and lastPublishedDate values.