DigiLocker Production Readiness Checklist
Use a DigiLocker launch worksheet to verify permissions, contract compatibility, consent, failure handling, data retention, and operational ownership.
A DigiLocker launch needs evidence of provider approval, compatible integration behaviour, and a workable operating process. Assign an owner and a test to each of those areas.
DigiLocker describes onboarding, technical integration, and launch steps. The API Setu consumer SOP describes approval and responsibilities for using APIs. Confirm the applicable route for your application. DigiLocker partner onboarding API Setu consumer SOP
Fill in a readiness worksheet
| Area | Evidence to bring to the launch review | Suggested owner |
|---|---|---|
| Access | Approved organisation, client, purpose, and document types | Provider relationship owner |
| Configuration | Exact contract revision, environment, and callbacks | Integration engineer |
| User journey | Consent screen and approved alternative path | Product owner |
| Evidence checks | Cases for source, permissions, integrity, and expiry | Security reviewer |
| Operations | Bounded alerts, support workflow, and dependency monitoring | Operations owner |
| Cleanup | Token revocation and result retention tests | Data owner |
Replace each suggested owner with a named role in your organisation. Link the evidence in the appropriate internal system.
Run tests in two layers
Synthetic fixtures help verify your own code. Use them to test duplicate callbacks, an expired grant, malformed records, and cross-account access. Include a result that completes processing with an unknown expiry.
Provider tests check compatibility with an approved integration. Confirm the host, approved credentials, consent values, token response, document permission, and sample retrieval. Use only the data and access approved for the environment.
Record each test's environment and expected outcome. A test plan should let a reviewer distinguish simulated behaviour from an observed provider result.
Rehearse a launch interruption
Suppose a deployed application starts returning permission failures after a configuration change. The operator should be able to stop new verification attempts, keep the rest of the application available, and tell affected users what to do next.
Plan how to close existing attempts and remove results according to policy. Check who can disable the integration. Record how an authorised operator restores service after the configuration passes review.
Prepare the operating handoff
- List the alerts and their owners.
- Give support a safe diagnostic template.
- Confirm who handles provider escalation.
- Run one cleanup exercise.
- Record the launch decision and unresolved issues.
Keep the worksheet current when the contract, approved documents, or data flow changes. Troubleshoot DigiLocker failures.
Review readiness with NamoID
NamoID engineers can help turn the worksheet into test cases for your application. Share your stack, approved scope, and the stage that needs review. Message the NamoID team in Slack