How Startups Prepare an API Setu Access Application
Prepare an API Setu access request with a defined use case, document scope, consent flow, and test plan. Understand where approval fits in the process.
Start an API Setu application with one clear request. Name the service you plan to provide, the API it needs, and the data you will use. A directory entry helps you find an API. The publisher decides whether your organisation can consume it. API Setu overview
For example, a vehicle rental startup might need a driving licence before handover. That is easier to review than a request for broad access to identity documents.
Find the provider and the role
Identify the publisher and confirm the service in the official directory. If you need to receive a person's issued documents through DigiLocker, investigate the requester route. If your institution publishes its own records, investigate the issuer route. DigiLocker partner resource centre
API Setu's consumer SOP describes organisation registration, use case review, and a separate subscription approval. It dates from February 2024. Use it to prepare your evidence, then confirm the current requirements for your organisation and API. API Setu consumer SOP
Prepare an application worksheet
| Field | Example for a rental service |
|---|---|
| Applicant | Legal name of the company that operates the booking app |
| Application | Customer booking service and responsible engineering owner |
| Requested API | DigiLocker requester workflow, subject to approval |
| Document | Issued driving licence |
| Trigger | Customer requests a vehicle handover |
| Purpose | Review the proposed driver's licence for that booking |
| Minimum fields | Issuer, masked reference, and relevant validity information |
| Alternative | Staff review using the operator's approved procedure |
| Retention | Time limit and owner for each retained field |
| Support | Contact who can investigate errors using a request reference |
Change each row to match your actual service. Identify which organisation determines the purpose and which parties process the data. Include a flow diagram if a vendor will receive or store any part of the response.
Describe the approval stages in your project plan
- Identify the API and its publisher.
- Record the applicant organisation and authorised contact.
- Gather the evidence requested in the current partner portal.
- Submit the use case through the applicable route.
- Confirm the specific subscription and permissions when approved.
- Use the approved test environment and credentials for compatibility checks.
- Obtain the required launch approvals before processing production data.
Track the owner and status of each step. The official DigiLocker model describes legal, technical, and launch reviews. Ask the provider which steps apply to your arrangement. DigiLocker partner onboarding
Build while access is under review
Use synthetic responses to develop the application journey. Include denied consent, unavailable records, and an expired document. Mark every synthetic fixture so the team can distinguish it from evidence from an approved provider environment.
Decide what the user sees when access is unavailable. Keep the request reference for support. Give the user a route to complete the task through an approved alternative.
Once approved, compare the provider contract with your fixture assumptions. Confirm the host, allowed documents, redirect URI, and consent fields. Record the exact API version before you adapt production code. DigiLocker integration guide.
Review your application with NamoID
NamoID engineers can help turn a proposed use case into an access and integration checklist. Share the API you need, your stack, and a synthetic workflow. The provider handles approval. Message the NamoID team in Slack