Certificates signed by the German EUDI Wallet Sandbox registrar omit the mdlDS extended key usage, which previously blocked importing them for a certificate signing request that requested the signMdl capability. When the imported certificate was issued by the German Sandbox registrar, Paradym now accepts it and keeps the requested signMdl capability, so you can issue an mDL into the German Sandbox. This is implemented as a workaround, and behavior may change in the future.

You can now fetch a single webhook by its ID through the API. This makes it easy to read back a webhook's current name, url and eventTypes.

See the get webhook API and the webhooks documentation.

When a wallet rejects an OpenID4VP verification request, for example because the user declined or the wallet does not hold the requested credentials, the verification session now surfaces the wallet's own error instead of a generic "an unknown error occurred" message with a support ID.

You will see the wallet's reason (such as access_denied) and its description in the session error, so you can tell why the verification did not complete without contacting support.

This is non-breaking and there is nothing to set up.

You can now update an existing webhook's name and eventTypes through the API, instead of having to delete and recreate it. This makes it easy to keep a webhook (and its signature secret) while adjusting which events it receives, for example when you start consuming a new type of flow.

Edit a webhook from the dashboard under Settings → Webhooks, or use the API: PATCH /v1/wallets/{walletId}/webhooks/{webhookId} for a partial update (at least one of name or eventTypes), or PUT to replace the webhook (both name and eventTypes required). The webhook url is immutable and the signature secret is unchanged.

See the update webhook API and the webhooks documentation.

The signing keys behind your certificates are now tracked as resources of their own. GET /v1/wallets/{walletId}/keys, and the new My Keys page under Trust, show every key, its status, and what is scheduled to happen to it. Request ?include=certificate,certificateSigningRequest to see what each key is used for. Each certificate also carries the keyId of the key it signs with.

A key is reclaimed automatically once every certificate it backs has been revoked or has expired. An imported certificate never gets there, since only the issuing CA can revoke it, so DELETE /v1/wallets/{walletId}/keys/{keyId} releases its key early. It can cost you the ability to revoke, so read deleting a key first. Changed your mind? POST /v1/wallets/{walletId}/keys/{keyId}/cancel-deletion undoes it for the whole grace period, as long as something still needs the key.

Retiring a key takes effect immediately: it stops signing at once rather than when its material is finally erased, and any outstanding credential offers it would have signed are expired along with it.

This is non-breaking, and there is nothing to set up.

Resolved an issue where the openid4vc.issuance.offerRetrieved and openid4vc.verification.requestRetrieved events were not delivered.

Credential templates now support a datetime attribute type for mDoc and SD-JWT VC credentials, next to the existing date-only date type. Use it for values that include a time of day, such as 2026-08-12T10:30:00Z (RFC 3339).

Values must be provided in UTC with whole-second precision (ending in Z, no fractional seconds or timezone offsets); other RFC 3339 forms are rejected at issuance. This is the date-time form ISO 18013-5 requires for mDoc credentials, and it applies to SD-JWT VC as well so datetime behaves the same across formats.

Select the type in the attribute dialog when creating a credential template in the dashboard, or pass "type": "datetime" in the create credential template API. Existing templates and credentials are unaffected.

Creating an AnonCreds credential template with an existing schema failed with Schema not found whenever that schema had to be resolved from the ledger (typically a schema created outside your wallet). Resolving those schemas now works, so you can reuse any published AnonCreds schema in a credential template.

Two bugs regarding Trusted Wallets have been fixed:

• Wallet attestations signed by DIDs are now correctly matched against the DIDs in the Trusted Wallet.
• When no Trusted Wallet is configured, X.509 certificate-signed attestations are now correctly trusted.