Skip to main content
Alentra lets your app ask a user’s government-issued digital credential a precise question and get back a cryptographically verified answer. The credential lives in the user’s own wallet. Alentra resolves one country, credential profile, and presentation provider from its canonical ledger, then verifies the signed response against the issuing authority’s trust anchors, and delivers the result to you. Three ideas make up the whole model.

​
1. Primitives — the verbs

A primitive is one verified action. You don’t call an “Identity API” or a “Sign API”; you compose primitives.

identify

Disclose specific government-attested fields (“blocks”) — e.g. first_name, dob, country, document_number.

age_verify

Prove the holder meets an age threshold. Alentra computes it from the credential’s birth date; this primitive returns only the boolean and threshold, not the date.

sign

The holder’s device signs a hash of one or more documents you provide (what-you-see-is-what-you-sign), bound to a verified identity.

light_sign

The same device signature over short inline terms text — no file upload. For consent and acceptance flows.
See Primitives for the full parameter and result shapes.

​
2. Credential routes — what is trusted and how it arrives

Alentra keeps the issuing jurisdiction and credential trust profile separate from the wallet provider. Google Wallet can carry several countries’ credentials; the US can offer several Apple/Google routes. The exact tuple is server-validated and locked for the session. Read current route status and provider capabilities from public GET /v1/catalog. See Credential routes & coverage for the current map.

​
3. Sessions — one flow for the user

A session bundles the steps you need into a single user experience. You create it server-to-server, then hand the user its hosted URL. On that page the user’s wallet completes each step on-device; Alentra verifies each one and sends you a signed webhook as it happens.
1

Create

POST /v1/sessions with your steps[]. Alentra returns a session id and a hosted url.
2

Hand off

Send the user to url. Alentra’s page and the browser’s native Digital Credentials flow handle same-device or cross-device presentation; you host no wallet UI.
3

Verify & deliver

The wallet responds, Alentra verifies it cryptographically, and you receive a logical step.completed event with the claims or signature — one per step. Delivery is at-least-once, so order results by stage.
4

Conclude

The last step completes the session. A stop, failure, or deadline instead ends it as session.stopped, session.failed, or session.expired.

​
What Alentra is not

Alentra does not ingest a photograph of the physical ID. Claims come from the issuer’s digitally signed credential in the wallet, verified by signature — not by OCR. There is no selfie or liveness check. A customer may explicitly request the credential’s signed portrait claim. (sign separately uploads the document being signed and retains a completed original as evidence.)
Alentra returns only the fields your step requests. age_verify returns a boolean to your business and withholds the birth date; the underlying identity is kept encrypted as audit evidence and is available only through the legal-review tier.
There is no Alentra “account” the user logs into. The credential stays in their wallet; each session is a fresh, consented disclosure. Alentra deliberately retains the completed result and its encrypted evidence; the evidence period and legal- hold process must be fixed in the signed production schedule.

Next: Quickstart

Create a session and receive your first verified result.