Changelog
Every change to the /v1 API, newest first, with what to do about breaking ones.
Changes to the /v1 contract, newest first. Breaking marks a change that can turn a
request that used to succeed into a failure.
2026-08-30
POST /v1/screen returns its matches ordered strongest first, and every match now carries a score between 0 and 1. Responses also carry recallCapped.
Nothing is required — the fields are additive and the order is the array you already receive. Two things are worth knowing. score is a DETERMINISTIC ORDERING FIGURE, not a probability and not a confidence: 1 means the name matched exactly, and lower values rank a close or partial name below it. It is computed from the name comparison and the corroborating fields, never from a search relevance score, so the same subject and the same list versions always produce the same value and the same order. Do not threshold on it — every match, at every score, carries the same "Potential match — verification required" label and still needs a person to verify it. And recallCapped: true means the check reached its candidate limit: the matches are the strongest of what was found, and there may be more. Narrow the subject (add a date of birth, an NPI or a state) rather than paging — there is no paging on this endpoint.
2026-08-23 · Breaking
A person is identified by one name on POST /v1/screen and PUT /v1/monitor. The firstName, middleName, lastName and suffix fields are gone.
Send the whole name — including any generational suffix — in name. A body still carrying the old fields is refused with a 400 naming name, rather than an anonymous unrecognized-field error, so the failure says what to change. Organizations are unaffected: they keep legalName.
Versioning
What counts as a breaking change, and how changes to /v1 are announced.
Enroll an entity in continuous monitoring PUT
Enroll one person or organization in continuous monitoring. The entity is screened immediately and added to your organization’s monitoring (tagged source `api`); the response returns its monitored-record id and current status — `clear` or `potential_match` with per-field evidence and provenance, never an automated "excluded" verdict. From then on it is re-screened whenever a covered source publishes a new immutable list version, and a match-status-change webhook announces any change. Each entity under monitoring accrues one metered record-month per billing month, reported by `GET /usage`.