DigiLocker API v2.4 Migration Guide
Review the September 2026 DigiLocker requester changes, update consent parameters, and test how your integration handles returned permissions and fields.
Start a DigiLocker v2.4 migration by comparing your approved contract with the new specification. The revision history dates version 2.4 to 9 September 2026. It records changes to consent fields, user details, the Verify Account API, and APAAR support. Requester v2.4 specification
Treat that date as the specification revision. Confirm with the provider which contract applies to each client before you change a live integration. The resource centre also lists other requester material. DigiLocker partner resource centre
Map each change to a component
| Area | Published v2.4 change | Review in your application |
|---|---|---|
| Consent screen | Added service name and revised accepted purpose values | Use the approved service label and plain purpose text |
| Authorization request | Added prompt and login hint options | Review only the options required for your journey |
| User details | Added fields for mobile, picture, and email | Accept extra fields without collecting them by default |
| Token response | Added mobile and purpose fields to the documented response | Keep logs free of tokens and extra personal data |
| Account verification | Removed Verify Account from the specification | Find any dependency and review its purpose with the provider |
| Academic identity | Added APAAR details and related options | Confirm eligibility and purpose before using these fields |
The specification includes distinct token response sections. Check the response for the exact flow you use before making a field mandatory. Requester v2.4 specification
Keep earlier controls in place
PKCE and the requested document-type parameter appear in earlier entries in the revision history. A migration should preserve callback binding, exact redirect URIs, and checks on returned permissions.
The current authorization section describes purpose and service_name as required. Check their allowed character set before the redirect. A configuration error should become a message your operator can fix. Consent parameter guide.
Run a focused migration review
- Record the approved client, environment, and specification revision.
- Compare the configured request with the matching authorization section.
- Test a user who grants the requested document.
- Test a user who denies consent or grants less access.
- Verify that the application ignores unused response fields.
- Test the approved cleanup path for a partial grant.
For a synthetic regression case, let a token exchange succeed while omitting the document grant. The application should stop before document retrieval. The result should tell support which stage needs review.
Plan changes per application
Use separate configuration for each application and environment. An older approval may name different capabilities or omit a newly required consent label. Review that approval before enabling the new route.
Record the migration outcome and the contract used to obtain it. A passing fixture shows how your code handles the response. A provider test shows how the approved client behaves in that environment. Keep both records in your rollout notes.
Review your migration with NamoID
NamoID engineers can help compare your authorization request, consent fields, and callback handling with the applicable contract. Share a redacted request shape and your current version in Slack. Message the NamoID team in Slack