How to troubleshoot DC API verification
Find the cause of a DC API error from the message a holder or browser reported, and know which issues you can fix and which are platform limitations.
DC API support is currently offered as a tech preview. The Digital Credentials API specification itself is still under active development in the W3C Web Incubator CG, and platform implementations continue to evolve. As such, functionality may be limited, may not work in all scenarios, and could change or break without prior notice as browsers and operating systems update their implementations.
This guide covers known issues when verifying credentials through the DC API.
Before you start
The DC API is invoked by the browser and handled by the operating system. Many failures are caused by a browser, operating system, or wallet limitation rather than by your configuration.
Most of a DC API request happens on the device, outside your application and not visible to MATTR VII, so no analytic events are recorded. The useful evidence is commonly:
- The browser console on the verifying page, which shows the error thrown by
navigator.credentials.get(). Capture this information for troubleshooting. - The browser and operating system versions on both devices. Several issues only occur with a specific browser and operating system combination.
Holders see a wallet QR code or redirect instead of the credential picker
The Verifier Web SDK falls back to OpenID4VP when any of these conditions is not met:
- The verifier application has a
dcApiConfigurationobject. - The browser supports the DC API.
- The request is for a single credential.
- No
walletProviderIdis passed torequestCredentials().
Fix: check each condition in order. Refer to the DC API guide for more details.
Calling get() needs to be triggered by an activation triggering user event
NotAllowedError: Calling get() needs to be triggered by an activation triggering user eventThe DC API can only be called in response to a user action, such as a button press.
Fix: Have the user request the credential via a button click. Don't trigger the request automatically when the page loads.
Currently, Chrome on iOS only keeps that user action valid for a very short time. If building the request takes slightly too long, the browser rejects the call even when it was started from a button handler.
Workaround: add this tag to the <head> of your verifying page:
<meta name="chrome" content="nointentdetection">Holders can also use Safari instead.
No supported document requests to present
TypeError: No supported document requests to present.The Verifier Web SDK reports this as:
[RequestCredentialsFailed] Failed to request credentials with Digital Credentials API
(cause: TypeError: No supported document requests to present.)Applies to: cross-device flows in Safari 27 on macOS 26. Same-device flows and macOS 27 are not affected.
This is a browser issue. Safari 27 can be installed on macOS 26 through a security update, so users may have it without choosing to upgrade.
Workaround: update the verifying machine to macOS 27. Same-device flows continue to work in the meantime.
Your info wasn't found
This message comes from the holder's operating system or wallet when no credential matches the request. Check the following:
- The credential is not registered with the operating system. This can happen after the wallet is reinstalled. Deleting and reissuing a test credential re-registers it.
- The wallet is not allowed to share credentials with websites. On iOS, this is a setting the holder controls in the operating system settings for the wallet.
- The document type is not supported on iOS. iOS only allows DC API requests for a fixed list of document types.
- The request signing certificate is not trusted by the wallet. Apple Wallet hides the credential from the picker. Google Wallet shows it but fails after the holder selects it.
Fix: first check whether the holder sees a picker at all. If the picker shows other credentials, the issue is with matching this credential. If there is no picker, check registration and wallet settings first.
No eligible IDs, or no picker appears
Chrome reports no eligible IDs, or Safari shows no credential picker.
The request format depends on the device making the request:
| Requesting device | Protocol used |
|---|---|
| iOS or macOS | ISO/IEC 18013-7 Annex C (org-iso-mdoc) |
| Android and other platforms | OpenID4VP (openid4vp-v1-unsigned) |
Safari only accepts org-iso-mdoc. Chromium-based browsers pass any protocol to the wallet. This
means these combinations do not currently work:
- An iPhone or iPad requesting a credential held on an Android device.
- Safari on macOS requesting a credential held on an Android device, unless the Android wallet supports Annex C.
Workaround: use a Chromium-based browser on the requesting device for cross-device flows between iOS and Android. Where you cannot control the holder's browser, keep an OpenID4VP path available.
We cannot process this type of code
Something went wrong. We cannot process this type of code.Applies to: cross-device flows where the holder scanned the QR code from inside a wallet app.
In a DC API cross-device flow, the QR code is read by the phone's operating system, not by a wallet. A wallet's own scanner cannot process it.
Fix: holders must scan the code with their phone's camera app. Say this in your interface next to the QR code.
If the holder uses Safari on the desktop and both devices are signed in to the same Apple Account, the request can transfer to the phone directly, without a QR code.
The digital-credentials-get feature is not enabled in this document
NotAllowedError: The 'digital-credentials-get' feature is not enabled in this document.
Permissions Policy may be used to delegate digital credential API capabilities to
cross-origin child frames.Applies to: verifying pages embedded in an iframe.
Fix: allow the feature on the iframe element:
<iframe allow="digital-credentials-get" src="https://your-iframe-origin.example"></iframe>And set the permissions policy on the top level page:
Permissions-Policy: digital-credentials-get=("https://your-iframe-origin.example")For a same-origin iframe, you can use self instead of the origin. Both are required.
Cross-device fails on managed devices
The holder confirms the browser prompt and the flow fails, but the same devices work on a different network or on unmanaged hardware.
Cross-device flows use Bluetooth to confirm the two devices are close together, and the connection is established via coordination servers from Google and Apple. A device or network policy that restricts this causes the flow to fail.
Fix: check that:
- Bluetooth is turned on for both devices, and the browser is allowed to use it.
- The two devices are physically close together.
- Network access on the verifying machine or mobile device is not restricted. Check if WebSocket connections to
cable.auth.com(Apple) orcable.ua5v.com(Google) are allowed.
iOS holders return an untrusted result
A presentation from an iOS wallet completes, but reports the verifier as unsigned or untrusted.
The same request from an Android wallet does not.
This is a current limitation. The iOS Holder SDK does not yet perform verifier authentication for DC API requests. Refer to the holder DC API overview.
Fix: none at present. Do not rely on this trust status for iOS DC API results.
Planning for a tech preview
Browser and operating system updates can change DC API behavior, sometimes in a minor update. Wallet support also varies. We recommend keeping an OpenID4VP path available for flows that must work for every holder, and offering the DC API as the improved experience where it is supported.
Next steps
How would you rate this page?
Last updated on