Reading verifications

Two ways to read, and which one you want depends on who is asking.

For a machine, use the ordinary API with a key. A warehouse sync, a nightly report or a status badge on a customer record has no person behind it and needs none.

For a screen one of your staff is looking at, use a session. The difference is not the data, it is that we can record who looked: reading somebody's identity writes an audit row naming the member of your team who did it, and that row appears on their page in our console beside everything else they have done.

The queue and the record

GET /v1/console/verifications
GET /v1/console/verifications/{id}

Both return status, verdict, score, reason codes, the flow, and decided_by, which answers the first question anybody asks about an outcome: was this the engine, a person, your automatic policy, or something settled elsewhere.

mode defaults to every environment the seat holds, which mirrors how our console opens. A member with both gets sandbox and live together, and each row carries its own mode so you can badge them. Pass ?mode=live to narrow. A seat asking for an environment it does not hold gets an empty list rather than an error, because that is the honest answer to "the rows you may see there".

Identity and images

GET /v1/console/verifications/{id}/identity
GET /v1/console/verifications/{id}/evidence

These are separate endpoints, not a flag on the record, because they need a different permission: verifications.reveal, which several roles deliberately do not hold. A viewer can read the list and never the person.

identity returns the fields read off the document. fields is null when we hold nothing for that verification, which you can act on. If we hold something and cannot open it you get an error instead, never an empty answer, because "this applicant submitted no details" is something you would act on and it would be false.

evidence returns short-lived URLs to the captured images. They expire in two minutes: fetch them when you render, do not store them, and do not put them in a log, because a URL that outlives the page is a copy of somebody's passport sitting in your logs.