Data freshness
How often the LinkinLegal sanctions data is loaded, how to read data_updated_at and last_change, and when a new entity can be matched.
The sanctions and PEP data is loaded every day from its sources. A change at an authority reaches the API on the next load.
Ask how fresh the data is
GET /sanctions/datasets answers with the source list and one timestamp:
{
"datasets": [
{ "name": "ru_acf_bribetakers", "description": "ACF List of War Enablers" },
{ "name": "US-AECA-DEBARRED", "description": "AECA Debarred List" }
],
"data_updated_at": "2026-09-20T03:03:01"
}data_updated_at is the newest change in the whole data set. Show it in your interface, or check it in your job before you screen. If it has not moved for more than a day, something upstream is stuck. Tell us.
The timestamps on an entity
| Field | Meaning |
|---|---|
first_seen | When we first loaded this record. |
last_seen | When we last saw this record in its source. |
last_change | When the content of this record last changed. |
last_change is the one you use. It drives the date sort and the from_date and to_date filters on search.
Find what is new
Ask search for everything that changed since your last run:
curl -s -G "https://api.linkinlegal.com/v1/sanctions/search" \
-H "Authorization: Bearer $LINKINLEGAL_API_KEY" \
--data-urlencode "from_date=2026-09-19" \
--data-urlencode "sort_method=date" \
--data-urlencode "per_page=100"from_dateandto_dateare inclusive. One day in both gives you the changes of that day.- Both read
last_change, so you get new and changed records, not only new ones. - Page with
pageuntil you passtotal_pages.
Run the job with one day of overlap (yesterday and today), and drop what you have already seen by id. Then a load that finishes late cannot slip through your window.
New data is not the same as a new risk
A record that changes is not automatically a new hit for your customers. Rescreen your own base
with match/batch and compare against
the scores you stored. That catches a change in a name or a birth date, which a "what is new" list
does not show.
When a new entity can be matched
The two endpoints see a new record at different moments.
| Endpoint | Sees a new record |
|---|---|
GET /sanctions/search, GET /sanctions/entities/{id} | At once, after the daily load. |
POST /sanctions/match | After the name refresh that follows the load, at 04:00 UTC. |
match compares against a prepared list of all names and aliases of an entity. That list is rebuilt once a day at 04:00 UTC. Until it has run, a record that arrived after the last refresh is found by search but not by match.
For daily screening this changes nothing: run your job after 04:00 UTC and you work with the newest data.
What we do not promise
- No webhooks. There is no push when the data changes. Poll with
from_date, or rescreen on a schedule. - No source timetable. Each authority publishes on its own rhythm. Our load is daily; the source may be weekly.
- No change feed per entity, except the listing history:
GET /sanctions/entities/{id}/historytells you which authority listed the entity, when it started and when it ended.
Last updated on
Thresholds
The LinkinLegal match threshold is 0.8 by default. What changes when you move it, which value fits onboarding or rescreening, and how to run a review queue.
Limits
What the LinkinLegal sanctions endpoints cannot do: scripts that are not transliterated, entity kinds that cannot be matched, the candidate ceiling and response times.