Skip to main content

Overview

Once you’ve picked a preset (see Browse credential presets), issue against it by passing the preset id along with the user’s data. This guide uses didx:basic-identity, an sd-jwt credential with attributes firstName and lastName.
Need a custom shape that no preset matches? See Custom credential template. For everything else, use a preset.

Endpoint

Request

Request body

The body has a single top-level field, credentials, which is an array. Each entry describes one credential to issue as part of this issuance. The most common case is a single-entry array; pass more than one to bundle multiple credentials into the same offer.
For each entry, pass either presetId or credentialTemplateId, not both. Most integrations only ever use presetId. The template path is for custom credential shapes.

Response

HTTP 201 Created What you get back is an issuance resource. The issuance represents the offer interaction itself — the protocol for getting credentials into the user’s wallet — and it carries the credential resources it produces inside credentials[]. The next page, Issuance vs credential, goes into the resource split in detail. For now, the short version is: the top-level id belongs to the offer flow, and each credentials[].id is a credential you’ll act on later.

Key response fields

The top-level id and the inner credentials[].id are different resources with different endpoints. Capture both now — recovering them later is more work. See the next section, Issuance vs credential.

Deliver the offer

Get the credential offer to the user. Two options:
  1. By email, username, or other identifier: Deliver via identifier.
  2. As a QR code or deeplink rendered in your own UI: Deliver out of band.