The email credential appears to be missing, or account creation stops after the Credential Manager response.
Fastest fix: First check whether the parser still expects a top-level vp_token. The updated response includes protocol and data, with the OpenID4VP vp_token inside data; new integrations starting in August 2026 should use the updated format, while migrating integrations should follow Android’s guidance for handling both structures. Client parsing is not credential verification: the server must validate the credential before account creation or sign-in. Android’s implementation guide
Android developers can use this guide to separate a response-shape bug from a credential-verification failure.
Mobile leads can use it to plan compatibility behavior against Android’s migration guidance.
QA engineers can use it to define evidence for successful credentials, unavailable credentials, and email-code fallback.
Last updated: October 28, 2026. We checked the response structure, migration guidance, and validation boundaries against the Android Developers implementation guide, overview, and trust and safety guidance. Recheck those official pages before release if the integration guidance changes.
Android Digital Credentials API email verification response format testing starts with the payload
When a parser reports that no email credential was returned, treat that message as a symptom, not a diagnosis. A missing top-level field may indicate that the code is reading the wrong path. It does not establish that the device had no credential, that the provider returned an empty result, or that the credential is invalid.
The Android response format changed in August 2026. The updated structure includes protocol and data, and places the OpenID4VP vp_token within data. Android says new integrations should use the updated format; existing integrations in the migration period should follow the documented approach for handling the new and legacy structures. These points are documented in Android’s email verification implementation guide. The official guidance is the source of truth for the actual payload shape and migration details.
Start with the raw response captured at the Credential Manager boundary, not with an assumption based on the parser’s error text. Log only a redacted structure: field names, nesting, and protocol identifier may be useful for diagnosis, while personal data, tokens, and credential contents should not be copied into routine logs. Compare that structure with the official example for the protocol being used.
| Integration situation | First thing to inspect | Correct decision |
|---|---|---|
| New integration started from August 2026 | Whether the parser expects protocol and data, and reads the protocol response from data |
Implement the updated structure shown in Android’s current guidance |
| Existing integration in migration | Whether the code assumes only the legacy shape or only the updated shape | Follow Android’s migration guidance and test both documented paths where applicable |
| Parser finds a token but account creation fails | Whether the server received and validated the expected credential and nonce | Diagnose server verification separately from client parsing |
| No credential is returned or the response is unusable | Whether the app exposes an appropriate alternative verification path | Test the unavailable and fallback branches as distinct outcomes |
Do not treat this table as a promise that every response will match a handcrafted example. The protocol, response contents, and current Android guidance determine what a valid payload looks like. Avoid adding fallback parsing that silently accepts any object containing a field named vp_token; permissive parsing can conceal a malformed or unexpected response.
Read the protocol and data fields before changing the parser
In the updated response, protocol identifies the protocol context, while data contains the corresponding protocol response. For an OpenID4VP response, locate vp_token within that data object, following Android’s sample and the applicable OpenID for Verifiable Presentations specification. Do not copy a field path from an unrelated protocol or infer one from a different Credential Manager result.
A practical failure pattern is code that deserializes a response into a model built around a single top-level property. The parser may then return null, a “missing token” result, or an application-level error even though the response contains data at a deeper level. Fix the model and its protocol-specific parsing branch; don’t relabel the response as “no credential” until the received structure has been checked.
This is also where logging can mislead a team. A log statement that prints only the expected top-level property cannot show whether the token is absent or simply nested elsewhere. Capture a redacted structural view at the integration boundary, and record the parser outcome separately. That gives engineering and QA a useful distinction without retaining sensitive credential material.
| Checkpoint | What to record in a test | What that result can establish |
|---|---|---|
| Credential Manager response received | Redacted field names, nesting, and protocol identifier | Whether the response shape matches the parser’s assumptions |
| Client extraction completed | A pass/fail outcome and the expected value’s presence, without logging the token | Whether client code found the expected protocol data |
| Server verification completed | Verification result and the relevant rejection category, without exposing secrets | Whether the server accepted the credential under its validation rules |
| Email fallback completed | Mail send result, controlled inbox receipt, and application verification state | Whether the fallback flow works end to end |
These checkpoints should stay separate in test reports. A client-side “parse passed” result is not evidence that a credential is authentic. A successful email receipt is not evidence that a Digital Credentials API exchange succeeded.
Keep parsing and credential verification as separate trust boundaries
Once the client has extracted the expected protocol response, the server still has work to do. Android’s trust and safety guidance distinguishes parsing from credential verification. The server must verify the credential according to the applicable implementation requirements before it creates an account or accepts a login.
In particular, the verification process must address the credential signature, issuer, holder binding, and original nonce. The nonce matters because the relying application must establish that the response is bound to the request it made, rather than accepting an otherwise plausible credential response in isolation. Consult the official implementation guidance for the exact verification procedure; do not invent checks or treat a successful client decode as a substitute for cryptographic validation. The W3C Verifiable Credentials Data Model provides the broader credential model, but it does not replace Android’s integration-specific instructions.
For useful observability, return separate outcomes from the client and server stages. For example, the client can report that a protocol response was extracted, while the server reports whether verification passed or why it rejected the submission. Keep tokens and personal information out of diagnostic events. This separation helps QA identify whether a failure occurred during response parsing, credential verification, or account policy enforcement.
A common test-design mistake is to mock a successful client parse and then mark the entire registration flow as passed. That test says nothing about issuer trust, holder binding, nonce matching, or signature verification. Maintain a server-side test that exercises those validation rules, and ensure the application does not create an account before the server returns an accepted result.
Implement new parsing and migration behavior deliberately
For a new integration, use the updated response format shown in Android’s documentation. Define a response model that represents the outer protocol and data fields, then dispatch parsing based on the protocol rather than assuming every response has the same internal shape. Follow the official example for extracting the OpenID4VP response from data.
For an existing integration, don’t guess the retirement date of the legacy shape or invent a supported-device range. Android’s migration notes are the source for the current transition behavior. Implement compatibility only as broadly as those notes require, and keep the legacy path easy to identify and remove when Android’s guidance says it is no longer needed. A silent “try every possible nesting path” parser makes later diagnosis harder because malformed and expected responses can look alike.
Use representative fixtures derived from the official examples and your own authorized test environment. Include a documented legacy-shaped response where migration guidance calls for it, an updated response, a response with missing expected data, an unexpected protocol value, and malformed input. The purpose is not to create a private alternative specification; it is to confirm that the parser handles known cases safely and fails closed when it cannot interpret a response.
When a field is missing, return an explicit application-level failure that can lead to the appropriate recovery path. Avoid manufacturing a credential result from partial data. When the protocol is unexpected, report that the response is unsupported rather than treating it as an empty email. And when the server rejects a parsed response, preserve that as a server verification failure instead of changing the client parsing result after the fact.
Verify email-code fallback as its own flow
A credential may be unavailable, a response may be unusable, or server verification may fail. The application should make its alternative path clear, but the fallback must not blur the reason the primary flow stopped. If the fallback is an email verification code, test the mail operation and the application’s verification state independently from Digital Credentials API parsing.
A controlled test should confirm that the application requested the email, that the message reached the test inbox, and that submitting a valid code changes the application’s verification state as intended. Also test rejected and expired-code behavior using the application’s own rules. Do not infer that the whole fallback passed merely because a message arrived: delivery proves receipt in that test setup, not that the code was accepted, tied to the correct account, or handled securely.
The reverse is true as well. If an email does not appear, that alone does not identify a Credential Manager bug. Check whether the app reached the fallback send step, whether the mail service accepted the send request, whether the controlled mailbox received it, and whether the app recorded the expected state. A controlled test inbox can help isolate receipt during an authorized test of your own application, but it cannot validate a Digital Credentials API response or prove that a credential is genuine.
For QA evidence, keep separate results for credential response parsing, server verification, fallback message receipt, and application state. That makes a failed test actionable: a mailbox problem should not be filed as a credential parser defect, and a successful inbox check should not be counted as server-side credential validation.
Run an isolated regression without leaking test data
We recommend exercising the flow only in your own application or an environment where you have authorization. Keep test identities and responses isolated from production accounts. If a bug report needs payload evidence, redact token values, personal details, and other credential contents before sharing it. Our guide to protecting test data covers the privacy decisions that should accompany test-account work.
Use a repeatable sequence:
- Capture the response at the Credential Manager boundary in a controlled test, and retain only a redacted representation of its structure.
- Compare the observed nesting and protocol with the current Android example before changing the parser.
- Run the parser against fixtures for the documented formats relevant to the integration, plus missing-field and unexpected-response cases.
- Confirm that a successful parse reaches the server, and that account creation or sign-in waits for the server’s verification result.
- Exercise server rejection cases for the required credential checks, including signature, issuer, holder binding, and nonce validation.
- Trigger the unavailable-credential and unusable-response paths, then confirm that the fallback is presented and invoked only where intended.
- Check mail send status, controlled inbox receipt, code acceptance, and the final application state as separate assertions.
- Record redacted response structure and server outcomes so later regressions can be compared without preserving sensitive credential data.
This sequence is deliberately diagnostic. It tells the team which boundary failed without making an unsupported claim about why. If the response structure matches Android’s current guidance but server verification fails, investigate the server path. If the server accepts a credential but the app fails to update its state, inspect the application flow. If email receipt passes but code verification does not, the mail service is not the only component under test.
FAQ
Where is vp_token in the updated Android response?
Look inside data in the updated response structure, and use the protocol field to select the relevant parsing path. For OpenID4VP, follow Android’s implementation example and the protocol specification rather than assuming a universal shape. If the parser checks only a top-level field, it may miss a token that is present in the nested response.
Why can older code fail to find a token that was returned?
Older parsing code may be built around a legacy response shape and read vp_token directly from the outer object. The updated response adds protocol and data, with the OpenID4VP result nested under data. Inspect the actual redacted response before deciding the credential is absent; then update the parser according to the migration guidance.
What should a new integration support compared with an existing one?
Android says integrations starting in August 2026 should use the updated response format. An existing integration in the migration period should follow Android’s instructions for handling the relevant new and legacy structures. Verify the current official guidance when shipping; neither a sample response nor this summary establishes an unlisted compatibility range or deprecation date.
Does client parsing mean the server can trust the email credential?
No. Client parsing extracts response data; it does not prove authenticity. Before account creation or sign-in, the server must perform the required credential verification, including the signature, issuer, holder binding, and original nonce. Keep client parsing and server validation as separate outcomes in both application logic and QA reporting.
If you are testing only an email-code fallback for your own application, a separate temporary inbox can keep test traffic away from a personal work inbox. FwdQuick is one option for that mailbox-only check; review the current access details before using it, especially for the test’s registration and retention requirements. Treat inbox receipt as evidence about the email fallback—not as proof that Android credentials parsed correctly or passed server verification.
Frequently asked questions
Where should I look for vp_token in the updated Android response?
Inspect the returned response object for its protocol and data fields, then read the OpenID4VP result from the data portion according to Android’s implementation example. A parser that only checks for a top-level vp_token can report no credential even when the response contains one. Confirm the actual payload shape in your integration logs, with personal or credential data removed.
Why does older email credential parsing code miss vp_token?
Legacy code may assume that vp_token appears at the response’s top level. The updated Android response uses an outer structure with protocol and data, and the OpenID4VP value is nested within data. That mismatch is a client-side parsing issue to investigate first; it does not, by itself, prove that the user has no usable credential.
Which response formats should a new integration or migration support?
An integration starting from August 2026 should implement the updated response format described by Android. Existing integrations in the migration period should follow Android’s migration guidance for handling the new and legacy shapes. Do not infer a universal cutoff or supported-version range from a sample payload; check the current official documentation before setting compatibility behavior.
What must the server verify after the client parses an email credential?
Client parsing only extracts response data; it does not establish that a credential is authentic or acceptable for account creation. Before creating or signing in to an account, the server must perform the required credential verification, including checks for the signature, issuer, holder binding, and original nonce. Keep parsing success and server validation as separate test outcomes.
Choose your route by email lifespan
Create a temporary address for one-time mail; for orders, recovery, or ongoing notifications, log in and create a forwarding alias.