#Credential Receiving

The Wallet API v2 receives credentials from an issuer using OID4VCI 1.0. You hand the wallet a credential offer — typically an openid-credential-offer:// URL from an issuer such as Issuer2 — and the wallet claims the credential and stores it in a linked Credential Store.

All endpoints live under /v2/{target}/wallet-service-api/, where {target} is the wallet's resource path ({organization}.{tenant}.{wallet-id}).

#How It Works

Receiving a credential runs through the same steps regardless of format:

1. Resolve the offer — parse the offer and fetch the issuer's metadata.
2. Get an access token — exchange a pre-authorized code (or an authorization code) for a token.
3. Sign a proof of possession — prove the wallet controls the holder key.
4. Fetch the credential — request it from the issuer's credential endpoint.
5. Store it — the credential is saved to the wallet's Credential Store.

#Two Ways to Receive

• Full flow — a single call (POST /v2/{target}/wallet-service-api/credentials/receive) runs every step for you. This is the recommended path and what the per-format guides below use.
• Custom Flow — drive each step yourself. Use it for custom wallet UIs, the authorization-code grant, deferred issuance, and advanced options like inline keys.

#Supported Formats

Choose the credential type that matches your use case — the flow is identical; only the offer's credential type and the stored format differ:

• SD-JWT VC (IETF) via OID4VCI — format: dc+sd-jwt
• W3C VC via OID4VCI — format: jwt_vc_json
• mDL / mDoc (ISO 18013-5) via OID4VCI — format: mso_mdoc

Need fine-grained control? See Custom Flow.