> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didx.co.za/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> What's new in the DIDx platform.

<Update label="2026-05-06" description="didx:me release">
  ## API surface

  * **`/api/v1/` versioning.** All existing endpoints are now mirrored under `/api/v1/` with a versioned prefix. Unversioned `/api/` routes continue to work, so there are no breaking changes for existing integrations.
  * **Issuances and credentials are separate resources.** Under `/api/v1/`, the previously conflated `/credentials` resource is split:

    * `/api/v1/issuances`: issuance sessions (offer / exchange flow).
    * `/api/v1/credentials`: flat issued credentials and revocation.

    Each resource now has consistent `{id}` semantics. See the `Credentials` API reference for the new shapes.

  ## Preset-driven workflows

  You can now drive issuance and verification end-to-end with a `presetId`. No template bookkeeping.

  * **Issue a credential by preset.** `POST /credentials/issuance` accepts `presetId` instead of `credentialTemplateId`. The first issuance per `(preset, tenant)` materialises the underlying template behind the scenes; subsequent calls reuse it. See [Issue a credential](/products/didx-me/guides/issuers/issue-credential).
  * **Create a presentation request by preset.** `POST /presentations/request` accepts `presetId`, mirroring the credential flow. See [Create a presentation request](/products/didx-me/guides/verifiers/create-presentation-request).
  * **Tenant-portable trusted issuers on presentation presets.** Presets now declare trusted issuers as real-world identifiers (public DIDs or x509 certificates) instead of tenant-scoped record ids. When a tenant uses the preset, each issuer is auto-resolved against that tenant's own trusted entities (reused or created). The response surfaces a `meta.trustResolution` block describing what mapped where. See [Presentation presets](/products/didx-me/guides/verifiers/presentation-presets-intro#trustedissuers-which-issuers-count-as-proof).

  ## Wallet & verifier behaviour

  * **Org-pushed presentation requests no longer fail when the user has no matching credential yet.** Push always succeeds for a valid request URI. As long as the request hasn't expired, the user can come back and respond to it whenever they actually obtain credentials that satisfy it.
  * **Verification error details propagated.** Errors from underlying verification surface as a list in the API response, instead of being collapsed to a single message. Easier to diagnose why a presentation failed.
</Update>