Start a DigiLocker requester integration with an approved use case and a versioned contract. Define the document you need, the person who shares it, and the decision your application makes after retrieval.

This guide uses the September 2026 Meri Pehchaan requester specification as a reference. Confirm the contract assigned to your client before using these request shapes. DigiLocker partner resource centre Requester v2.4 specification

Step 1. Confirm access and environment

Use the requester route when your application needs to receive documents with the user's consent. Use the issuer route when your organisation publishes its own records. API Setu documents the registration and subscription steps. API Setu overview DigiLocker partner onboarding

Record the approved client, purpose, document types, host, and exact redirect URI. Keep distinct Test and Live configuration. Confirm which host and credentials the provider has approved for each environment.

Prepare the organisation information before implementing the provider flow. API Setu access application worksheet.

Step 2. Start one verification attempt

Start from the application's signed-in account. Bind the attempt to the application, user, and intended purpose. Generate fresh state and a Proof Key for Code Exchange (PKCE) verifier. Store both on the server. PKCE binds the authorization code to the requester that started the flow.

The following is an illustrative authorization request. Encode the parameters when constructing the URL. Supply only values approved for the client.

GET /public/oauth2/1/authorize
response_type=code
client_id=YOUR_APPROVED_CLIENT_ID
redirect_uri=YOUR_REGISTERED_HTTPS_CALLBACK
state=YOUR_ONE_TIME_STATE
code_challenge=YOUR_S256_CHALLENGE
code_challenge_method=S256
scope=openid
req_doctype=DRVLC
purpose=Verify driving licence for vehicle pickup
service_name=Example Rental Booking

The v2.4 authorization section describes the purpose and service name fields and the document type selector. scope=openid selects the documented OpenID Connect path. Your contract determines the supported controls for the client. Requester v2.4 specification

Use a nonce for an identity flow that expects one under the approved contract. Keep consent fields separate from general sign-in configuration. DigiLocker consent fields.

Step 3. Validate the callback and exchange the code

Look up the pending attempt using state.
Check that it belongs to the expected user and application.
Handle a denial through the approved alternate path.
Consume the state before exchanging the code.
Send the exchange from the backend using the matching contract.
Verify the applicable token signature and claims.

For the documented OpenID Connect flow, v2.4 lists /public/oauth2/2/token. Use the same registered redirect URI and the original PKCE verifier in the exchange as required. Use the documented client authentication method. Keep secrets on the server. Requester v2.4 specification

A browser return should identify the pending attempt. The application backend decides whether to retrieve or attach a result. Secure callbacks and account binding.

Step 4. Check returned access and retrieve the selected document

Question	Where to check it
Is the grant still valid?	Token lifetime and consent expiry under the applicable contract
May the application list issued records?	Returned list permission
May it retrieve the selected record?	Returned document permission for the specific URI
Does the record match the requested evidence?	Allowed document type and issuer
Did download integrity pass?	The documented response integrity check

The v2.4 specification lists /public/oauth2/2/files/issued for issued records. Use the contract's supported file or XML route for retrieval. Confirm which formats the issuer and endpoint return. Requester v2.4 specification

The issued list and a selected document grant serve different purposes. Filter the list and check permission for the exact record again before retrieval. Keep user-uploaded copies in a separate review path. Issued documents and uploaded files.

Step 5. Record evidence and close the attempt

Check the response integrity according to the endpoint. If your policy requires an independent issuer signature, run the appropriate check and record its result separately. A document can arrive from an approved source and still require more validation for the intended use.

In a synthetic case, consent succeeds and the issued list loads. The selected licence is outside its required validity period. Record the completed retrieval and route the business decision to the appropriate review step. Driving licence result interpretation.

Use a data retention policy for the fields and evidence your workflow needs. Keep document contents, credentials, and tokens out of diagnostics. Close ended attempts and use the provider's approved revocation process. Grant expiry and revocation.

Test the outcomes before launch

Use the DigiLocker outcome matrix with synthetic fixtures first. Record approved provider-environment tests separately.

Case	Expected application behavior
Denied consent	End the attempt without document retrieval
Missing exact document permission	Stop before fetching that document
Invalid identity signature or nonce	Reject the identity response
Invalid download HMAC	Reject the document response
Expired or unknown licence validity	Route the business decision to the approved policy
Completed result	Inspect each check before accepting the evidence

For mobile return handling, keep the provider callback on its approved HTTPS host. Open the hosted journey in a supported system browser. Verify the registered app or universal link separately. Callback and account binding.

Review an integration with NamoID

NamoID's controlled preview handles post-login driving licence checks for approved applications. It reports the approved source and download integrity results. It reports the independent issuer signature status as not_verified.

The team can help review your contract, consent request, callback binding, and synthetic test cases. Share your stack, intended document, and current access stage. Message the NamoID team in Slack