Get Issued Files

API reference

curl -X POST "https://__mock__/verification/v2/digilocker/get_issued_files" \  -H "AccessToken: string" \  -H "Content-Type: application/json" \  -d '{}'

{
  "issued_files": {
    "items": [
      {
        "date": "15-01-2025",
        "description": "Aadhaar Card",
        "doctype": "ADHAR",
        "issuer": "Unique Identification Authority of India (UIDAI)",
        "issuerid": "in.gov.uidai",
        "mime": [
          "application/json",
          "application/xml",
          "application/pdf"
        ],
        "name": "Aadhaar Card",
        "type": "file",
        "uri": "in.gov.uidai-ADHAR-abc123def456ghi789jkl012mno345",
        "parent": "",
        "size": ""
      }
    ]
  }
}

{
  "detail": {},
  "message": "string"
}

{
  "detail": {},
  "message": "string"
}

{
  "error": "string"
}

Overview

Call POST /verification/v2/digilocker/get_issued_files from your backend after the user has finished the DigiLocker Init journey and KwikID has completed the OAuth exchange. You send:

1. Authorization: Bearer <token> - your KwikID Verification API credential (same model as Init).
2. AccessToken header - the DigiLocker session token for this user after the hosted flow completes (see Init follow-up in the OpenAPI description for that operation).

On success, the JSON body includes issued_files.items: one object per document, with uri, name, issuer fields, mime, and related metadata. Use uri with Get XML (PAN, Aadhaar, etc.) when you need the actual file or XML. Treat the response as sensitive; do not expose it to untrusted clients or analytics.

Key features

• Two headers: API Bearer plus DigiLocker AccessToken (not interchangeable; both required for this call as documented in OpenAPI).
• Server-side only: Do not put your API Bearer token in a browser or mobile client.
• Discovery step: Lists what the user has in DigiLocker so your product can offer downloads or PAN or Aadhaar flows next.

Implementation

Prerequisites

1. Completed DigiLocker flow for this user (after Init and user consent).
2. Valid AccessToken for that DigiLocker session (from the flow your integration obtains server-side; do not guess or fabricate).

Step 1: Call from your backend

POST /verification/v2/digilocker/get_issued_files HTTP/1.1
Host: <verification-api-base-url>
Authorization: Bearer <token>
AccessToken: <digilocker-access-token>
Content-Type: application/json

{}

Use your real base URL (production or sandbox from KwikID). Send an empty JSON object {} if you have no extra fields (matches typical POST usage for this route).

Step 2: Use the response

On 200 OK, iterate issued_files.items. For each row, uri identifies the document for Get XML; name, doctype, and issuer help you label choices in your UI. For a full field-by-field reference of this list shape, see DigiLocker API (Document List API Response).

Do: Log correlation IDs only; do not log full JSON or tokens in plain text.

Do not: Send AccessToken or full issued_files payloads to the public internet or third-party analytics.

End-to-end placement

Error handling

Security notes

Warning: issued_files can describe government-issued identity documents. Handle it under your data protection and DigiLocker policies. Never ship raw responses to untrusted clients.

• Keep Bearer and AccessToken on servers you control.
• Use HTTPS for all calls.

Benefits

• One list call after OAuth to know which documents exist before calling Get XML per URI.
• Same Init then follow-up pattern as Get Aadhaar XML and Get XML (PAN, Aadhaar, etc.), so your integration stays consistent.

Next steps

• DigiLocker Init
• Get Aadhaar XML data
• Get XML (PAN, Aadhaar, etc.)
• DigiLocker response field reference
• Verification API index