Issuance vs credential

Two things, not one

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

An issuance — the offer session. It has offerUri/offerQrUri, a status that tracks the offer/acceptance flow (offered → completed, or failed/expired), and any errors that happened along the way.
One or more credentials — the actual credentials that will end up in the user’s wallet. Each has its own id, its own status (offered/issued/revoked), and is what you act on later (e.g. to revoke).

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?

If you want to…	Use the…
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 / template	Credential — `GET /v1/credentials`

Lifecycles, side by side

Two resources, two state machines:

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. The cheapest thing you can do is store both ids against your own record when you issue:

issuance id — so you can ask “was this offer ever accepted?” later, or wire up the openid4vc.issuance.completed webhook.
credential id — so you can revoke it without having to hunt for it later.

Capturing now is much easier than recovering later.

Reading them 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 "https://test.didxtech.com/me-creds/api/v1/issuances/<issuance-id>" \
  -H "Authorization: Bearer <access_token>"

Without any id, list credentials and narrow with filters:

curl -X GET "https://test.didxtech.com/me-creds/api/v1/credentials?filter[status]=issued&filter[format]=sd-jwt-vc" \
  -H "Authorization: Bearer <access_token>"

Supported filters: filter[id], filter[status], filter[format], filter[credentialTemplateId], filter[exchange]. Standard cursor pagination via page[size], page[before], page[after]. Full schemas: Credentials API reference.

Overview

User Onboarding

Issuance

Verification

Webhooks

Custom Templates (advanced)

Errors

Two things, not one

Which one do you need?

Lifecycles, side by side

Capture both ids at issuance time

Reading them back later

​Two things, not one

​Which one do you need?

​Lifecycles, side by side

​Capture both ids at issuance time

​Reading them back later

Two things, not one

Which one do you need?

Lifecycles, side by side

Capture both ids at issuance time

Reading them back later