Issuance vs credential

Two resources, not one

When you call Issue a credential, the platform creates two kinds of resource at once:

Issuance. The offer session. It has offerUri and offerQrUri, a status that tracks the offer and acceptance flow (from offered to completed, or to failed or expired), and any errors that happened along the way.
Credentials. One or more, and these are what end up in the user’s wallet. Each has its own id, its own status (offered, issued, or revoked), and is what you act on later, for example to revoke it.

In the issuance response, the credentials live one level deeper, in a credentials[] array:

{
  "data": {
    "id": "cm7d9cq5600pwk3zq3kmpg8uc", // issuance id
    "status": "offered",
    "credentials": [
      {
        "id": "cm7d9cq5600pzk3zq9wzxxtc3", // credential id
        "status": "offered",
        "format": "sd-jwt-vc",
        "revocable": true
      }
    ],
    "offerUri": "...",
    "offerQrUri": "..."
  }
}

The two ids look similar but mean different things, and the API has separate endpoints for each.

Which one do you need?

Goal	Resource	Endpoint
Look up the state of the offer (was it accepted? did it fail?)	Issuance	`GET /v1/issuances/{id}`
List historical offer sessions	Issuance	`GET /v1/issuances`
Revoke a credential after it was accepted	Credential	`POST /v1/credentials/{id}/revoke`
List credentials by format, status, or template	Credential	`GET /v1/credentials`

Lifecycles, side by side

Each resource has its own state machine.

Issuance status	Meaning
`offered`	Offer created, waiting for the user to accept
`completed`	User accepted; the credential is in their wallet
`failed`	Something went wrong during the exchange
`expired`	The offer wasn’t accepted in time

Credential status	Meaning
`offered`	Created as part of an issuance, not yet accepted
`issued`	Accepted and active in the user’s wallet
`revoked`	Explicitly invalidated (SD-JWT only). See Revoke a credential

Capture both ids at issuance time

The issuance and credential ids are both stable from the moment the issuance is created. You don’t need to wait for the user to accept. Store both against your own record when you issue:

Issuance id. Lets you ask “was this offer ever accepted?” later, or wire up the openid4vc.issuance.completed webhook.
Credential id. Lets you revoke the credential without hunting for it first.

Read the ids back later

If you didn’t capture an id at issuance time, you can recover it: By issuance id, fetch the issuance back and read credentials[].id from it:

curl -X GET "$BASE_URL/me-creds/api/v1/issuances/ISSUANCE_ID" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Without any id, list credentials and narrow with filters:

curl -X GET "$BASE_URL/me-creds/api/v1/credentials?filter[status]=issued&filter[format]=sd-jwt-vc" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Supported filters are filter[status], filter[format], filter[credentialTemplateId], and filter[exchange]. Cursor pagination uses page[size], page[before], and page[after]. Listing issuances at GET /v1/issuances takes filter[id] and filter[status] instead.

Filter by template id, not preset id. There is no filter[presetId]. The issuance response reports the credentialTemplateId the platform resolved your preset to, so capture it from the first issuance if you want to list everything issued from that preset later. The value is stable for a given preset within your tenant.

Full schemas are in the Credentials API reference.

Overview

User Onboarding

Issuance

Verification

Branding

Webhooks

Custom Templates (advanced)

Errors

Two resources, not one

Which one do you need?

Lifecycles, side by side

Capture both ids at issuance time

Read the ids back later

​Two resources, not one

​Which one do you need?

​Lifecycles, side by side

​Capture both ids at issuance time

​Read the ids back later

Two resources, not one

Which one do you need?

Lifecycles, side by side

Capture both ids at issuance time

Read the ids back later