Verifications

A verification is one attempt by one person: a session that was created, run, and finished with a verdict. This page lists every one of them for your organization, newest first, in the environment you are looking at.

If you want the person rather than the attempt, use Persons.

Finding the one you want

The search box takes a name, an email, a document number or a session id.

When an exact search finds nothing, the console offers similar names: rows whose name is close to what you typed. Spelling and transliteration differ between systems, so the person you want is often there. It compares the most recent verifications in your current view rather than your whole history, and says how many it looked at.

The filters narrow by status, verdict, flow, reason code, score range, date range, API key, source, and by what decided it: our engine, an automatic policy, a reviewer, or something outside this console. Unread only and In review, anyone are the two shortcuts a working team reaches for most.

The columns

Status and verdict are not the same thing and it is worth knowing why. The verdict is what the checks concluded; the status is where the session stands. A session whose verdict is review has status manual_review until somebody decides it, and then the status becomes approved or rejected while the verdict recorded by the engine stays what it was.

An expired session usually means the applicant never finished. Two reasons say something different, and both mean this attempt produced no new verification rather than anything about the person. ALREADY_VERIFIED means you already hold an approval for them: either this attempt was refused, or it was a case waiting on review that closed on its own when the same person was approved on another verification. REVIEW_IN_PROGRESS means they started again while an earlier case of theirs was still waiting on a reviewer, so this attempt was refused. Their person page shows the approval or the open case beside it. Manual review explains both.

Working several rows at once

Select rows with the checkboxes and the bulk bar appears: apply tags, mark read or unread, or assign the cases to a colleague. It reports how many rows it changed and how many it skipped, which happens when a row is not eligible for what you asked.

Export takes the current filtered list off the platform as a CSV or NDJSON file. It asks for a code from your authenticator app first, and it is owner-only by default, because an export writes decrypted identities into a file that we can never recall or expire. Large exports are capped and the console tells you when it hit the cap, so narrow the filters to reach the rest.

The detail page

Select a row and you get everything recorded about that attempt.

Session holds the id, the flow that ran, the engine tier, the applicant's language, the overall score and the reason codes.

Applicant holds identity as read from the document and confirmed by the applicant. It is shown in full to any role allowed to see applicant details, and every view is recorded against your name in Team activity. A role that may not see applicant details is told so instead. If the person has verified with you before, a line here links to their person page and tells you which attempt of how many this is.

When somebody on your team has edited the applicant data, this card turns amber and carries a Modified badge with the version and how many times it was edited, for example "Version 3 · edited 2 times". That is the signal that the record no longer says exactly what was read from the document. History opens every version, described in Editing applicant data below.

Checks lists each check that ran, its own verdict and its reason codes. This is where "why was this rejected" is actually answered.

Evidence is what the applicant captured: document scans, selfie, liveness frames or video. Select an image to enlarge and zoom it. Occasionally an image is no longer in storage, and the console says so rather than showing you a broken frame.

Activity is the whole trail, oldest first: consent, every check, any review decision, and each webhook we sent about it.

Tags are your team's own labels, and they stay with the person behind the verification. If no person record is linked yet, the console says so, because a tag put there would have nobody to stay with.

Things you can do from here

Decide it. The decision panel appears only when there is an open review case on this session. Approve, reject, or hand it to a colleague. A session the engine decided on its own has nothing to decide, and one that is already resolved says so. The full workflow is on Manual review.

Edit the applicant data. Fix a name, a date or a number by hand, beside the scan. See Editing applicant data below.

Re-read the document. Reprocessing runs extraction again over the images we already hold and replaces the stored identity fields. It does not change the status, the verdict or the score, and it cannot be undone. Use it when the reading is wrong rather than when the decision is. If the second reading recognises nothing, the previous values are kept. A field somebody on your team edited by hand is kept as they left it: a new reading never overwrites a person's correction.

Allow one more verification. When re-verification is on, holding an approval for somebody means a new session for them is refused. This control lets one through, once, with a reason and a time window. It does not undo the approval: that stands until a new verification replaces it, so if the person never comes back, nothing about their record changes. You can withdraw the allowance again before it is used.

Editing applicant data

The engine sometimes reads a document wrong: a dropped digit in a national ID, a transposed date, a name it would not transliterate. Edit on the Applicant card opens the scan beside every field the document prints, including names and dates as printed in the document's own script, so you can type what the document actually shows. It works on a verification in review and on one that is already approved or rejected. The same control sits on the case in Manual review.

Editing changes the stored applicant data only. It re-runs no check, and it never changes the status, the verdict or the score: an approved verification stays approved. Your webhook endpoints receive verification.data_updated for every saved change, so your own systems know to fetch the record again. See Webhooks.

Every save is a new version, and nothing is ever deleted. The first edit also keeps the record exactly as the engine read it, as version 1, so the original read can always be restored.

An already decided verification asks for your authenticator code before the change is saved, because the applicant and your systems have already been told something about it. A case still in review does not.

A change that contradicts an approval is flagged before it is saved. On an approved verification the console checks whether the new values break the rules the approval was made under, and lists each one:

You can go back, or choose Save anyway. The verification stays approved either way, and the version records that you saved it knowing about the conflict. If you need a different outcome, that is a separate decision.

If somebody else saved first, your save is refused rather than merged, and the dialog asks you to reload the record and make your change again on top of theirs.

Some verifications cannot be edited here, and the card says why: one still being captured or processed, or one that expired; one in an environment you do not hold; and one mirrored from another platform, which owns its data.

The version history

History lists every version, newest first. Each one shows who made it and their role, when, the reason and the note, whether the verification was approved, rejected or in review at the time, any conflicts that were confirmed, and each field that changed, from its old value to its new one. A change made by platform staff while helping you is labelled as platform staff rather than under a team member's name.

Restore on an older version saves a new version with that version's values. It asks for a reason, and it follows the same rules as an edit: the conflict warning on an approval, the authenticator code on a decided verification. Restoring deletes nothing, so a restore can itself be undone the same way.

Opening the history shows applicant data, so it needs the same permission as seeing the applicant card and is recorded in Team activity. Editing and restoring need the Edit applicant data permission, which owners, review managers and reviewers hold by default. See Roles and permissions.