> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/identity-verification/database-validation/aadhaar-verification-via-digilocker.md).
# Aadhaar Verification via DigiLocker
***
### Overview
For users in India, the platform can confirm that the holder's demographic details, such as name and date of birth, match the record held against their Aadhaar number, the identity number issued by the national identity authority.
The **Aadhaar Verification (DigiLocker)** node runs this check via DigiLocker, the Government of India's document wallet. You add the node to a workflow in the Workflow Builder and branch the flow on the result.
The node matches the name, date of birth, and PIN code the user provides, together with a LiveID selfie, against the user's DigiLocker record, and returns a pass/fail decision with individual match scores.
### What Gets Checked
The node confirms:
* That the name, date of birth, and PIN code the user enters match the record held against their Aadhaar number
* That the face captured in the user's LiveID selfie matches the record, with a liveness check to confirm a live user is present
* That the user consented to the DigiLocker lookup and completed it with a one-time password (OTP)
### What It Does and Doesn't Tell You
It confirms that the user's submitted details and selfie correspond to the Aadhaar record held by DigiLocker, with individual match scores for name, date of birth, PIN code, and face.
It does not verify the Aadhaar number in isolation. The check runs through DigiLocker, so it depends on the user completing DigiLocker sign-in or sign-up and giving consent; if the user cannot access DigiLocker, the node cannot complete the verification.
### Prerequisites
* Community Administrator access to the AdminX UI and the Workflow Builder.
* The Aadhaar Verification (DigiLocker) node enabled for your tenant. If you don't see it in the Node Library, contact your 1Kosmos representative.
### Add the Node to a Workflow
1. Open the Workflow Builder.
2. In the Node Library on the right, expand the **Third-Party Verification** category.
3. Locate **Aadhaar Verification (DigiLocker)** and drag the node onto the canvas.
4. Connect the node's branches to the rest of the workflow.
5. Click **Save**. Use **Preview** to review the flow before publishing.
### End User Experience
When the workflow reaches this node, the end user:
1. Enters their full name (as per Aadhaar), date of birth, and PIN code, then selects **Verify with DigiLocker.**
2. Captures a LiveID selfie to complete the liveness check.
3. Is redirected to the DigiLocker portal to authenticate.
4. Enters their Aadhaar number, verifies the OTP sent to their registered mobile number, and enters their 6-digit DigiLocker security PIN.\
\
5. Reviews the requested Aadhaar information and selects **Allow** to provide consent for sharing.
6. Is redirected back after DigiLocker processes the request.
7. Sees a confirmation once their identity has been successfully verified.
{% hint style="info" %}
DigiLocker delivers the result through a callback after the user gives consent, so expect a short delay between consent and the workflow advancing.
{% endhint %}
### Viewing Aadhaar Verification Results
In addition to the node's own output, community administrators can review a readable summary of any Aadhaar verification attempt from the Sessions page in AdminX.
1. Go to **Verification > Sessions**.
2. Find the session for the user you want to review. Each row shows the identity, document type (**Aadhaar Card**), outcome (**Passed** or **Failed**), risk level, signals detected, and location.
3. Click the session to open **View Results**.
The View Results page shows:
* **Session Details** — Session ID, session status, the browser/OS used, and the IP address the session was run from.
* **Summary** — the user's name, the document type, and the **Overall Recommendation** (**Verification Passed** or **Verification Failed**).
* **Match Score** — See [#match-score](#match-score "mention")
* **Data Extracted** — the name, date of birth, country, and PIN/zip code read from the Aadhaar record.
* **Images** — captured images for the session, available on request via **Show Images**.
#### Match Score
The Match Score panel breaks the overall recommendation down into the four individual checks that feed it:
* **Full Name Match** — whether the name the user entered matches the name on the Aadhaar record.
* **Face Match** — whether the LiveID selfie matches the record, shown as **Match** or **No Match** alongside a confidence score (for example, 0.98). This is the only field in the panel that displays a numeric score; the other three show only a match/no-match badge.\
The default face match threshold is set to 0.7; A `face_match_confidence` score above 0.7 is accepted, and this threshold is not configurable by users or admins today.
* **DOB Match** — whether the date of birth the user entered matches the record.
* **Address Match** — whether the PIN code the user entered matches the record. This corresponds to the `zip_match_confidence` field in the node's own response.
Each of the four checks is evaluated independently, so a session can show **Verification Failed** overall while some fields still show **Match** (for example, a face mismatch does not affect the Full Name, DOB, or Address results). Use this panel together with the individual match fields when you need to know which specific check caused a failure, rather than relying on the overall recommendation alone.
This is the same Match Score and recommendation data returned in the node's own response, presented for administrators to review without needing to inspect raw node output.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.1kosmos.com/identity-verification/database-validation/aadhaar-verification-via-digilocker.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
.png?alt=media&token=f2020fab-5656-48ad-87f9-612fd6a16788)