Delivery

By default LutraID returns the wallet URI to you and you decide how the holder sees it. Set deliveryMode: "email" and LutraID sends it instead.

Editions: SaaS · Self-hosted. The public edition has no email delivery and rejects these fields.

Modes

Supplying recipientEmail with direct, or omitting it with email, is a validation error.

curl "$LUTRAID_API/v1/organizations/$ORG/issuers/$ISSUER/create-credential-offer" \
  -H "X-API-Key: $LUTRAID_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "issuanceProfileId": "8f1b…",
    "deliveryMode": "email",
    "recipientEmail": "ana@example.com",
    "data": [{ "documentTypeId": "pid-sd-jwt", "credentialSubject": { "given_name": "Ana" } }]
  }'

The same two fields exist on initiate-verification.

What the email contains

A QR code image of the wallet URI, an Open in wallet button pointing at an HTTPS bridge link that resolves to the deep link on the holder's device, and the transaction code when one was generated. Bridge links live for 14 days by default.

Delivery status

The response echoes deliveryMode, recipientEmail and deliveryStatus. Mail goes out through a queue, so status advances asynchronously:

not_requested → pending → queued → sent → delivered, or bounced, complained, failed, needs_review.

Transitions are monotonic — bounced and complained are terminal. Read the current value from the issuance or verification record; there is no delivery callback.