Every Aadhaar extraction API in the market returns the full twelve-digit number by default. It is worth asking why, because for most of the organisations calling those APIs the number is a field they cannot verify, do not use, and are not entitled to insist on — and which turns their document store into something worth stealing.
This is an argument for a default, not a prohibition. There are organisations with a statutory basis for holding a full Aadhaar number, and they should have it. The claim is narrower: that handing it back to everyone, automatically, because the field exists on the card, is the wrong shape for the problem.
On this page
You probably cannot verify it
Checking an Aadhaar number against UIDAI requires registration as an authentication or KYC user agency. That status is granted to a defined set of entities under specific conditions, and most organisations running KYC in India — NBFCs, housing finance companies, insurance intermediaries, brokerages, fintech lenders and the vendors serving all of them — do not hold it.
If you are not registered, the number your OCR just extracted has never been checked against anything. It is a string your OCR read off a photograph. Its correctness rests entirely on the quality of that read, which is the same OCR you would want to double-check if the field mattered.
That is the first oddity: the field being treated as the most sensitive output of the call is also the one carrying the least assurance.
The 2018 Puttaswamy judgment sharpened the position by striking down Section 57 of the Aadhaar Act, which had been read as permitting private bodies to require Aadhaar under contract. A private entity now needs a statutory basis to make it mandatory. A great many organisations kept asking anyway, because the form already had the field and customers comply.
What the last four digits are actually for
Masking covers the first eight digits and leaves the last four. That split is not arbitrary and it is the whole argument in miniature.
The last four are a reconciliation key. They let a person or a system confirm that the document in front of them belongs to the record they already hold. An operations officer looking at a file can say "yes, same customer" because the record ends in the same four digits. Nothing in that workflow needs more.
The first eight are what make the number a lookup key — the property that identifies a person across databases that have never spoken to each other. That is exactly what makes it valuable to an attacker, and for an organisation that cannot authenticate, it has no internal use at all.
So an extraction API that returns the last four and omits the first eight has not degraded its output for most callers. It has returned the part with a use and withheld the part with only a liability.
What changes when it lands in your database
An extracted field goes somewhere different from a document. This is the part that gets underweighted when the decision is framed as "the number is on the card anyway".
A document sits in a document store, usually access-controlled, usually with a retention policy someone has at least thought about. An extracted field goes into the customer master, which is queried by reporting, replicated to analytics, exported to a data warehouse, synced to a CRM and read by every internal tool that has ever needed a customer record.
Extraction takes a number that was one scan among thousands and turns it into a structured, indexed, joinable column across your entire estate. That is a genuine change in exposure, and it happens the moment the API returns the field — not when someone decides to use it.
It also changes what a breach looks like. A leaked document store is a collection of files someone has to process. A leaked customer table is a clean CSV of names, dates of birth, addresses and Aadhaar numbers, already parsed, already joined. The second is worth considerably more, and extraction is what converts one into the other.
When you genuinely need the whole number
The argument would be dishonest without this section, because the cases exist.
Delivery of subsidies and benefits from the Consolidated Fund of India under Section 7 of the Aadhaar Act is the clearest. Income tax filing and PAN linkage under Section 139AA is another. Certain regulated financial verifications where a statute or a regulator requires it. And organisations that are registered as authentication or KYC user agencies, performing the authentication they are licensed for.
What those have in common is a specific legal basis attached to a specific purpose. That is a much smaller set than "everyone integrating a KYC pipeline", and it is exactly the distinction a default should encode: available on request, with the basis recorded, rather than handed to every caller because the schema has a field for it.
What a defensible default looks like
Four properties, and the fourth is the one most often missed.
Masked by default. XXXX XXXX 9012, with the last four
supplied separately so a caller never has to parse a mask off a string.
The full number as an entitlement, not a parameter. Granted per organisation, at provisioning, against a lawful basis attested at contract time. A flag any caller can set is not a control; it is a field with an honesty policy.
The attestation recorded when it is granted. That record is the thing that matters if the question is ever asked, and it cannot be reconstructed afterwards from logs.
An error, not a silent downgrade. If an unentitled caller asks for the full number, the request must fail. Quietly returning the masked value instead is the worst option available: the caller believes it is receiving full numbers, writes the masked string into a field it treats as authoritative, and nothing surfaces until a match fails somewhere that has no idea why.
Three objections worth answering
"Our customers expect the full number." Some do, and they can have it under the process above. But the expectation is largely an artefact of every vendor returning it by default, which is a description of market convention rather than of need. The useful question to put to a customer asking for it is which internal system consumes it and what that system does with it. The answer is frequently that nothing does.
"Masking makes us less competitive." It makes the default different, not the capability smaller. And it is the honest answer to the question a technical buyer actually asks a masking company selling extraction: whether the two products contradict each other. A vendor that argues institutions should not accumulate full Aadhaar numbers and then returns them automatically has answered that question badly.
"The number is on the document either way." True, and it is the reason the document should be masked too. But a field in a database is not a number on a scan, for the reasons in the section above. The document is one file among thousands; the field is a column joined across your estate. Treating them as equivalent is what makes extraction feel harmless when it is the step that changes the shape of the risk.
Masked by default, full on attestation. Our extraction endpoint returns XXXX XXXX 9012 with the last four separately. The unmasked number is an entitlement granted per organisation against a lawful basis — and asking without it returns 403 rather than silently downgrading.