Changelog

Every change that affects your integration or your team lands here, newest first. Changes are additive unless an entry says otherwise: a new field or event never removes an old one, so an integration that ignores what it does not recognise keeps working. Check back from time to time, or before you upgrade anything that reads our payloads.

24 September 2026

Documents missing a field their kind always prints go to review

Every document we read now records which of its fields were present. For each country and document type, we learn from documents approved in manual review which fields a genuine one always carries, and a document that lacks one of them, or carries one that fails its own check, goes to manual review with INCOMPLETE_DOCUMENT instead of being approved automatically. Hiding a field is how an edited real document conceals who it belongs to. A field only becomes expected once enough approved documents of that kind show it nearly every time, so a field that is simply hard to read never triggers this, and the set grows on its own as more documents are reviewed. It never rejects anyone.

INCOMPLETE_DOCUMENT can be waived in your findings policy like any other document finding. Before this, a document the reader sent to review with this finding could still be approved by the sensitivity setting; it now holds at every sensitivity.

The machine-readable zone is compared with the printed page more often

A passport's machine-readable zone is now found in more of the documents we read, including when the page is read as one block of text. Where it is found, it is compared with the printed page as before, and a printed passport number or date of birth that disagrees with it is refused with ID_INVALID.

Uploaded files are kept as they were sent

When an applicant uploads a document photo instead of taking one in the flow, the original file is now kept alongside the photo we read, and whether each document photo came from the camera or from an upload is recorded. It is evidence kept with the verification for our document checks. It changes no decision, and the applicant sees nothing new.

23 September 2026

The document types your flow accepts are now enforced

A flow has always been able to say which documents it takes, and that setting never did anything: whatever the applicant picked in the widget was accepted. It is now enforced when the document is captured, so a flow restricted to passports refuses an ID card on the spot and tells the applicant what it takes. A flow that lists nothing is unrestricted, exactly as before, so nothing changes unless you had narrowed the list and expected it to hold. See Flows.

Groundwork: checking that a document is the type it was said to be

The verification flow now has a way to measure a captured card against the printed designs it is supposed to match, on the applicant's device and again on our side, before the document is read. It is inactive for every country today and reports nothing; the designs it compares against have to be measured against real documents first, and each one is turned on separately. Nothing about your integration changes, and no applicant sees anything new yet. We will say here when the first country goes live.

Your team can edit applicant data, and every edit is versioned

Owners, managers and reviewers can now correct the identity data on a verification, in manual review and after it has been approved or rejected. Every edit is kept as a new version and nothing is ever deleted: version 1 is always what was read from the document, and any version can be restored. An edit never changes the status or the verdict. See Verifications and Roles in the console guide.

New webhook event: verification.data_updated

Sent once for every edit, carrying the names of the fields that changed and the new version number, never the values. Fetch the verification again with include=applicant for the new values. Every existing endpoint was subscribed to it automatically, and new endpoints receive it by default. See Webhook events.

identity_version and identity_edited_at on the verification

The verification resource now says whether its applicant data was edited (identity_version is 0 when it never was) and when. The applicant expansion carries its own version, read together with the values beside it. See Applicant data.

Blurry documents and selfies are retaken before they are sent

The verification flow now checks that a document photo is sharp and large enough to read, and that a selfie shows a clear, frontal, well-lit face, and asks the applicant to retake it on the spot. After two retakes the flow lets them continue, so an older phone can never block anyone.

Documents that print dates day first are read correctly

A document printing its expiry as 25/05/2028 used to be recorded as having no readable expiry, which sent it to manual review. Day-first dates are now read; when a date could be read two ways that disagree on whether the document has expired, it is still sent to a person rather than guessed.

22 September 2026

Allow a repeat verification from your backend

POST /v1/verifications/{id}/reverification lets one person verify again after an approval that would otherwise refuse them with ALREADY_VERIFIED, and DELETE withdraws that permission while it is unused. Until now this was only possible from the console. See Check existing applicants.

21 September 2026

change_reason on the verification

GET /v1/verifications/{id} now says who settled the outcome: engine, reviewer or auto_policy, and null until the verification is final. Webhook outcome payloads carry the same fact as changeReason.

Reopening a decided verification needs its own permission

Sending a decided verification back to review through the API now requires the verification:reopen permission, which no key has by default. Approving or rejecting is unchanged.

An unreadable expiry date is never approved automatically

When the expiry date on a document cannot be read, the verification now goes to manual review with EXPIRY_UNREADABLE, whatever your review sensitivity, instead of being approved without that evidence. See Reason codes.

16 September 2026

One person, one open question

A new verification is refused while the same person already has one waiting in manual review, with VERIFICATION_IN_REVIEW at creation and REVIEW_IN_PROGRESS later in the flow. When one of their verifications is approved, their other open cases are closed. A person is now also recognised by their national ID number, so a driving licence and an ID card for the same person match. See Webhook events and Errors.

14 September 2026

Create keys that can read applicant data yourself

When you create an API key in the console, you can now choose whether it reads outcomes only or full data (applicant:read), which include=applicant,documents needs. A 403 for a missing permission now names the keys on your account that already have it, and a key's last-used time is shown correctly. See Applicant data.