One captured ID or selfie image, read from Persona on request (owner only)
Streams one image the signer captured (the ID's front or back, a selfie) from Persona to the owner. This is the one read that still goes to Persona: images are never stored, so each view is an explicit owner action that fetches the image then. Only an image the stored report lists is fetched (anything else is a 404 without a call to Persona). It is never stored or cached (Cache-Control no-store), the bytes are checked to be an image, and it is only ever fetched from a Persona host. Restricted to the document's owner. Views are not written to the document's audit trail. Which images exist is listed in the report's verifications[].photos.
View as MarkdownAuthorization
bearer In: header
Path Parameters
The verification id from the report
Value in
- "front"
- "back"
- "selfie"
- "left"
- "center"
- "right"
Response Body
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/v1/documents/string/recipients/string/verification-report/photos/string/front""string"A recipient's Government ID result, read from Easerix (owner only)
Returns the result of a recipient's Government ID verification as Persona last reported it. The result is stored in Easerix when Persona's webhook delivers it (or when a reconciliation read settles an inquiry no webhook did), so this call is served from the database and never calls Persona. It is never cached by clients (Cache-Control no-store) and is limited to the fields below: the verified name, per-verification document type, issuing country and check results, and the names of the images that exist. It carries no images (those are fetched one at a time from the photos endpoint) and the document number, birth date and address are never stored or returned. Until Persona has reported anything the status is not_started or in_progress and the other fields are empty. updatedAt is when the stored result last changed. Restricted to the document's owner, because org sharing widens who can read a document and must not widen who can read a signer's identity result. Views are not written to the document's audit trail. A recipient with no Government ID inquiry has no report (404).
Suggest recipients as the sender types
The recipient picker's memory. Merges two sources and de-duplicates them by lowercased email: people the caller has sent to before, read out of the recipients of documents the caller may READ (their own, plus documents a teammate shared with the workspace — a teammate's PRIVATE document never contributes), and the members of the caller's workspace, which the auth service owns and is asked for with the caller's own bearer token. Document-agnostic on purpose: the editor already knows who is on the document in front of it, so filtering out people already added is the client's job. Ranking puts email matches ahead of name matches and prefixes ahead of infixes, then someone already sent to ahead of a colleague who hasn't been, then most recently used. An empty q returns the most recently used recipients, newest first, with workspace members filling the remainder. Degrades rather than fails: if the auth service is slow or unreachable the response is still 200 with send history alone, so the field the caller is typing into never breaks. Not paginated, deliberately. limit is a ceiling, not a window: there is no cursor and no offset, and a larger limit is capped rather than paged. Send history is stored as one row per time someone was added to a document, so an offset would skip rows rather than people and a second page would mostly repeat the first after de-duplication — and the member half has no cursor to page at all. Narrow with q instead. Browsing the full contact list is a separate surface, not a page of this one. kind=group switches this same endpoint to a different resource entirely: previously-used signer-group labels (EAS-125+) instead of people, matched by label text only. There is no workspace-roster merge for this kind — a label isn't an identity — so the response is shaped differently (GroupLabelSuggestion, not RecipientSuggestion): each entry also carries the member roster from that label's most recent use, offered as one-click additions once the new group exists, never added by this endpoint itself. Same tenancy boundary as the person path: a label (and its roster) is only ever suggested from a document the caller may read.