Send a JPG, PNG or PDF of an Aadhaar card and get its fields back as JSON — name, date of birth, gender and address, with the number masked and the last four digits supplied separately. Built for KYC and document pipelines at banks, NBFCs, housing finance companies and fintechs.
Talk to our technical team → — for integration questions, accuracy benchmarks on your own documents, or a volume estimate.
Synchronous and stateless. Same request shape as the masking endpoints, so an existing integration needs no new plumbing.
curl -X POST https://api.maskaadhaar.com/api/v1/extract-aadhaar -H "X-API-Key: " -F "file=@aadhaar.jpg"
Full reference, warning codes and language examples are in the API documentation.
{
"fields": {
"name": "Rahul Kumar",
"aadhaar_number": "XXXX XXXX 9012",
"aadhaar_last4": "9012",
"date_of_birth": "1990-05-12",
"gender": "M",
"address": {
"full": "12 Anna Salai, ...",
"pincode": "600018"
}
},
"checksum_valid": true,
"warnings": []
}
This is the part that makes us different from every other extraction API in the category, so it is worth stating plainly rather than burying in the reference.
aadhaar_number comes back with the first eight digits covered. aadhaar_last4
is supplied separately, so you never have to parse a mask off a string.
The reasoning is the same argument the rest of this site makes. Only organisations registered with UIDAI as authentication or KYC user agencies can verify an Aadhaar number; everyone else is filing one. Matching a customer against a record you already hold needs the last four digits. The first eight are what turn the number into a cross-database lookup key — the property that makes it valuable to an attacker and heavy to store, and for most institutions the property they have no use for at all.
So the default returns everything a KYC process actually consumes, and omits the field that is usually pure liability. If your use case genuinely requires the full number — and some do, under a statutory basis — the entitlement is granted per organisation against an attested lawful basis. Talk to us and we will provision it.
Requesting it on a key without the entitlement returns 403 reveal_not_entitled
rather than quietly downgrading to masked. A caller that believes it is receiving full numbers and
is silently receiving masked ones will write the masked value into a field it treats as
authoritative, and nothing about that failure is visible until a match fails somewhere downstream.
| Field | Notes |
|---|---|
name | As printed. We do not expand initials or normalise honorifics — a guess in a KYC name field fails a match downstream in a way nobody traces back to here |
aadhaar_number | Masked by default. aadhaar_last4 supplied separately |
date_of_birth | ISO YYYY-MM-DD, or null where the card carries only a year |
year_of_birth | Set when the card is year-only. We never synthesise a January date to fill the gap |
gender | M, F or O, normalised rather than passed through |
care_of | The S/O, D/O, W/O or C/O line where present |
address | full and pincode. We do not split into line, locality, district and state — Aadhaar addresses are not consistently structured, and components that are wrong a fifth of the time are worse than one honest string, because you cannot tell which fifth. A partial_address warning flags a read we were not confident about |
checksum_valid | Verhoeff check on the detected number. false means digits were read that do not form a valid Aadhaar number — a read failure, not a number |
vid_detected | Flags a sixteen-digit Virtual ID on the document. A VID is not an Aadhaar number and is never returned as one |
Extraction is easy to get almost right. These are the cases that separate a working implementation from one that quietly returns wrong data.
UIDAI printouts carry both sides on one page, often with one card rotated ninety degrees. Every orientation is scanned rather than stopping at the first field found.
Aadhaar numbers carry a Verhoeff check digit. Validating it means a Virtual ID, an enrolment number or a date sequence of the right length is not returned as an Aadhaar number.
Field officers submit phone photographs at angles, under tube lights, of folded printouts. Where a field genuinely cannot be read it comes back null with a warning, not as a plausible guess.
Requests are served from AWS ap-south-1. For an Indian lender answering a data-residency question, processing stays in-country.
Documents are processed in memory and not written to a database or object store. Extracted values are never logged either: an extraction log is a structured database of Aadhaar demographics, and it is usually less well protected than the document store.
Keys are stored securely and can be rotated or revoked from your dashboard, with revocation taking effect immediately. Quota and rate limits apply per key.
They answer different questions, and a KYC pipeline typically calls both on the same document.
| Extract | Mask |
|---|---|
| ✓Populates the customer record — name, DOB, address | ✓Produces the copy you are allowed to keep on file |
| ✓Removes manual data entry and its typos | ✓Removes the lookup key before the document is stored |
| ✓Returns JSON | ✓Returns the document |
| Together: extract at intake to fill the record, mask at intake to produce the archived copy, and the unmasked original never needs to be written anywhere. | |
The masking endpoint is documented at Aadhaar masking API, and where masking belongs in a pipeline is covered in the KYC pipeline guide.
The same interface for PAN cards, returning the PAN, name, father's name and date of birth. PAN is returned in full: it is not governed by the Aadhaar Act and carries no equivalent lookup-key property, so the masking default above does not apply.
curl -X POST https://api.maskaadhaar.com/api/v1/extract-pan -H "X-API-Key: " -F "file=@pan.jpg"
Not by default. The response carries the number masked, plus the last four digits separately, which is what reconciliation against your own records needs. Full numbers are available per organisation against an attested lawful basis, because the first eight digits are a cross-database lookup key that most institutions have no authorised use for.
Accuracy depends on your document population more than on any published figure, which is why we provision a test quota rather than quote one. Angled phone photographs under poor light are the normal case in field collection, and the design choice that matters is that an unreadable field returns null with a warning rather than a plausible guess.
No, they are separate endpoints, deliberately. A pipeline usually wants both on the same document — extraction to populate the record, masking to produce the copy it archives — and keeping them separate means a failure in one does not silently affect the other. Both consume the same quota.
No. Documents are processed in memory and streamed back; nothing is written to a database or object store, and extracted field values are not logged either. We log the field count, the warnings and the key.
A document with no recognisable Aadhaar card returns 422 and is not billed. A document where some fields read and others do not returns the fields it has, nulls for the rest, and a warning naming the problem — and the X-Extracted-Fields header lets your pipeline branch on it without parsing the body.
Tell us your expected monthly volume and peak throughput and we will provision a key with a test quota, so you can benchmark accuracy on your own documents before committing.