Yente

Twin of the OpenSanctions yente screening API.


Covers	Self-hosted OpenSanctions yente 5.5
Auth	None
Webhooks	No
Operations	12

Coverage

Screening a name against a watchlist: POST /match, dataset search, entity reads, adjacency, the catalog and algorithm metadata, OpenRefine reconciliation and the health probes.

Yente publishes no version selector at all, so the pinned image is the dialect. This one follows the self-hosted 5.5 image, not the hosted api.opensanctions.org edge. The two differ, most visibly on trailing slashes.

Credentials

Yente has none. Its query endpoints are unauthenticated by design, so there is nothing to send and nothing to arm, and a token you send anyway is ignored. The admin reindex call POST /updatez always answers 403 {"detail": "Invalid token."}, with or without a token, which is what the real service does too.

Vendor specific details

The score float is not a stable contract. The decision is, so assert on the match bool and which entity came back, not on the number. Near a borderline result with an unusual threshold, the bool itself can differ from the real matcher.
A trailing slash is a 307 redirect with an empty body, method and query string preserved. The hosted edge normalizes it in place instead, so code that works against api.opensanctions.org can break on a self-hosted one.
A retired entity id 308-redirects to the canonical entity, and the query string is dropped from Location. An id that never existed is still a 404.
There are two error envelopes. Framework validation is a 422 with a list of {type, loc, msg, input}; yente’s own checks are a 400 with a plain string detail. Validation runs before lookup, so a bad parameter beats a missing entity’s 404.
A query written in a non-Latin script scores zero against every entity, including one whose own name carries that exact string. Both tokenizers split on ASCII, while the real matcher transliterates first.

Its own notes

Once a sandbox is running, this twin serves its own operating notes at {control_url}/veris/manual: the credentials it accepts, the API versions it serves, and the fault statuses you can arm against it. They are generated from the same source as its behaviour, so they cannot drift.