Credential offers, presentation requests and DIDComm invitations now include direct deeplink URIs in their API responses, alongside the existing universal-link based offerUri / authorizationRequestUri / invitationUri.

Until now these URIs pointed to a Paradym (or custom wallet) invitation page, which then deeplinks into the wallet. In some flows you might want to directly link into the wallet outside of the Paradym invitation page.

The new fields give you the raw scheme directly:

• OpenID4VC issuance offer: offerDeeplinkUri (openid-credential-offer://…) and offerDeeplinkQrUri
• OpenID4VC presentation request: authorizationRequestDeeplinkUri (openid4vp://…) and authorizationRequestDeeplinkQrUri
• DIDComm invitation: invitationDeeplinkUri (didcomm://…) and invitationDeeplinkQrUri

The …DeeplinkUri fields are plain deeplink strings you can place behind a button or render into your own QR code. The …DeeplinkQrUri fields return a QR code image (like the existing …QrUri) whose contents are the deeplink instead of the universal link.

These fields are additive and non-breaking, existing integrations keep working unchanged. See Issue credentials and Verify credentials, or the API Reference for more information.

EU Lists of Trusted Entities (LoTEs) are now available starting from the Builder tier, instead of requiring the Pro tier.

You can now point a trusted entity at a LoTE URL and let Paradym fetch, validate, and keep the list of trusted issuance and revocation certificates up to date automatically, on any Builder plan or higher. Configure it under Trusted Entities or via the API.

No action is required. Existing projects on the Builder tier immediately gain access to this feature.

Paradym can now verify the PID and EEAs from the German EUDI Wallet, as well as issue EAAS.

• ETSI LoTEs of the EU PID Providers List type now cover any SD-JWT VC credential type within the urn:eudi:pid: namespace, so the LoTE is used automatically when verifying a country-specific PID type such as Germany's urn:eudi:pid:de:1. The German test trust list can now also be imported.
• As a temporary workaround for the German EUDI Wallet rejecting DCQL queries that contain trusted_authorities, Paradym omits trusted_authorities from the query when an OpenID4VP request is signed with an Access Certificate issued by the German Sandbox registrar. This may change at any point in the future. The configured trusted issuers are still fully validated by Paradym when the presentation is received.
• You can now copy the public key of a certificate signing request from the dashboard. This makes the registration in the German EUDI Wallet Sandbox Registrar easier. Under My Certificates in the "Trust" tab, open the ⋯ menu of a request and choose Copy public key to copy its SPKI PEM (-----BEGIN PUBLIC KEY-----). The existing Copy request option still copies the full PKCS#10 request.

To verify the German PID, configure a trusted entity with the German test trust list and request urn:eudi:pid:de:1 in your presentation template.

When configuring an ETSI LoTE with custom credential types (e.g. an EU Public EAA Providers List), each credential type can now be an exact or a starts-with match. A starts-with matcher covers every credential type sharing a prefix, which is useful for namespaces where multiple types are registered (for example the urn:eudi:pid: namespace for SD-JWT VCs).

In the dashboard, pick Exact or Starts with from the dropdown next to each credential type when editing a trusted entity's LoTE (Trusted Entities). From the API, pass an object { "type": "startsWith", "value": "urn:eudi:pubeaa:custom:" } instead of a plain string in credentialTypes. This change is backwards compatible: existing exact string matchers keep working.

Not possible to provide credentialTypes for known LoTE types

For LoTE types where the credential types are determined automatically (e.g. EU PID or mDL Providers List) it is not possible anymore to provide custom credential types. All LoTE entries on a Trusted Entity now return the LoTE type (pidProvider, pubEaaProvider, mdlProvider), and only pubEaaProvider LoTE entries are allowed to provide custom credential types.

When fetching an ETSI List of Trusted Entities (LoTE), Paradym now extracts certificates from each entity's Revocation services in addition to its Issuance services.

This means a credential issued by a LoTE-listed provider whose status list is signed by a separate revocation authority is now verified correctly, including its revocation status, as long as both certificates are published in the same LoTE. No action is required; existing LoTE-backed trusted entities pick this up automatically.

When you revoke a credential, Paradym updates and re-signs the status list that tracks its revocation state. Previously this could happen even when the status list was signed by an expired certificate, producing a status list with an invalid signature. Revocation now validates the issuer certificate first and ensures its not expired.

Paradym now automatically generates and hosts an SD-JWT VC Type Metadata document for your SD-JWT VC credential templates. Wallets and verifiers can dereference a credential's vct (type) URL to retrieve a JSON document describing the credential's display information and claim structure, so they can render and validate credentials without relying on the OpenID4VCI issuance flow.

When you create or update an SD-JWT VC template with a Paradym-generated vct URL, Paradym builds the Type Metadata document from the template (name, description, branding, attributes and localization) and serves it at the vct URL. The document is re-published every time the template is saved, so it always stays in sync — including localization, which now flows into the metadata's display arrays.

If you supply your own custom vct, Paradym does not publish the document for you, but you can still retrieve the generated metadata to self-host it — either from the new Type Metadata section on the template detail page in the dashboard, or via the new API endpoint GET /v1/projects/{projectId}/templates/credentials/sd-jwt-vc/{credentialTemplateId}/type-metadata (see the API Reference).

Learn more in the new Credential Metadata guide.

Profile logos and credential template background images are now automatically downloaded and re-hosted on Paradym's own infrastructure instead of being served directly from external URLs. This eliminates requests to arbitrary third-party domains when wallets render your credentials, improving both security and reliability.

What changed

• When you set a project profile logo or a credential template background image via URL, Paradym fetches the image, validates it (JPEG, PNG and SVG, max 1 MB), and stores a stable copy in the Paradym bucket.
• The stored URL is immutable from the wallet's perspective — updating an image overwrites the same path, so existing deep links keep working.
• Images are validated on upload: unsupported formats (GIF, WebP) and oversized files are rejected with a clear error. Because SVGs can carry active content, every SVG is sanitized before it is stored — scripts, inline event handlers, javascript: links and embedded HTML (foreignObject) are removed, and only the sanitized output is hosted.
• Existing images up to 10 MB are downloaded, validated (JPEG, PNG and SVG) and re-hosted by Paradym. If an image is larger than the regular 1 MB limit, it is compressed and re-encoded down to fit, so it keeps working without any action from you. Images larger than 10 MB cannot be migrated: their URL is unset, so you will need to upload a new image for your project profile or the credential template's background image.

No action is required unless one of your images was larger than 10 MB, in which case re-upload it from the dashboard.

Custom wallet settings moved to their own tab

The settings for the wallet shown on your invitation page, its display name and the Apple/Android application IDs used to render the App Store and Play Store buttons, have moved out of the Profile tab into a dedicated Custom Wallet tab under Settings.

The QR code and Open in Wallet button on the invitation page now use the protocol deep link (openid-credential-offer://, openid4vp:// and didcomm://) instead of the Paradym universal link. This means an invitation can be opened by any wallet that supports the underlying protocol, rather than only the Paradym wallet, improving interoperability with third-party holder wallets.

If a recipient doesn't have a compatible wallet yet, the invitation page still links to the configured wallet's app store pages so they can download one.

We've added new ready-to-use example templates to the documentation, complete with issuance and verification payloads:

• Proof of Age as mDoc, based on the EU Digital Identity Wallet Age Verification specification (issuance / verification).
• ISO 23220-4 Photo ID as mDoc, based on the ISO/IEC TS 23220-4 Photo ID profile (issuance / verification).