Sessions

A verification session connects a relying-party backend, an end user, and an EUDI wallet. Create it on the server with POST /v1/sessions; the response contains a session_id, expiry, QR URL, and wallet deep links.

Lifecycle

Session lifecycle

CREATED
PENDING
VERIFYING

VERIFIEDPresentation accepted
FAILEDVerification rejected

EXPIRED is also reachable from any active state when its deadline passes.

Sessions can start at PENDING. A presentation can also move CREATED directly to VERIFYING. VERIFIED and FAILED are terminal outcomes.

Your backend creates a session with the minimum credential and claim request.
Your application displays the QR code or opens a supported wallet deep link.
The wallet sends its presentation to the public OID4VP response endpoint. The wallet does not need your API key.
Your backend reads the session status and requested claims, or listens for status events on the WebSocket endpoint.
Your backend deletes the session after it has consumed the result.

Session creation is asynchronous. A successful creation response is not a verification result. Handle CREATED, PENDING, VERIFYING, VERIFIED, FAILED, and EXPIRED as distinct states. Claims are available only when the session reaches a verified result and are retained for a limited period; delete the session as soon as your application no longer needs it.

The request is checked against the relying-party policy before a session is created. Requests outside the configured intended use or claim scope are rejected. Ask for the smallest set of claims needed for the user-facing purpose.

Start with Create session, follow GET status or the status WebSocket, and delete the session after use. See Quickstart for the complete flow and Webhooks for signed terminal notifications.