Use case

Extract, verify, mask, store

Four steps in that order. Reversing any two of them is where onboarding flows end up storing an identifier they did not need, or trusting a number they never checked.

Talk to our technical team → — for integration questions, a security review or a volume estimate.

The order, and why it is that order

1. Extract
/extract-aadhaar returns name, date of birth, gender and the number as JSON, so the customer is not retyping what is printed in front of them. checksum_valid tells you whether the number read cleanly — a mis-read caught here never becomes a customer record.
2. Verify
/verify-document checks the card against the digitally signed QR code printed on it. A card where the printed details and the signed data disagree has been altered. This is the step almost every onboarding flow skips.
3. Mask
/mask-aadhaar. You needed the number to verify. You do not need to keep it readable afterwards.
4. Store
The masked document. Not the original.
Verify before you mask. The QR check reads the card as printed. Mask first and there is nothing left to verify against.

What each step catches

Designing the failure paths

The happy path is four calls. What determines whether the flow works in production is what happens when one of them does not return what you hoped.

Extraction returns nothing
Glare, a clipped corner or heavy compression. Ask for a retake while the customer is still present rather than falling back to manual keying later.
Checksum fails
The twelve digits read are not a valid Aadhaar number. Almost always a misread rather than a forgery. Re-capture before you treat it as a fraud signal.
No readable QR
Common on older cards and poor scans. Treat as unverified, not invalid, and decide your own policy for that state — it is a business decision, not a technical one.
QR disagrees with the print
This one is a real signal. The printed details and the signed data differ, which means the card has been altered. Route to manual review.
Masking returns zero
Do not store the document. It is unmasked and readable. Retry or queue for review.

What to keep afterwards

A useful test: if your object store were dumped publicly tomorrow, which of the above would you mind about? Everything on that list except the last line is defensible.

Questions we get asked

Do you authenticate against UIDAI?

No, and we are not licensed to. Verification here means checking the card against the signed QR code printed on the card itself, which catches tampering without any external call. Authenticating a person against the UIDAI database requires a licensed AUA.

Can we auto-fill a form from the card?

Yes, that is what the extraction endpoints are for. Note that returning the unmasked number is entitled per organisation against a stated lawful basis rather than being available by default.

What if the QR is missing or damaged?

The response says so rather than failing. Older cards and poor scans often have no readable QR — treat it as unverified rather than as invalid, and decide your own policy for that case.

What if the QR cannot be read at all?

Common on older cards and poor scans. Treat it as unverified rather than invalid — the absence of a signature is not evidence of forgery. What you do with an unverified document is a business policy decision, and it should be an explicit one.

Should we keep the original alongside the masked copy?

If you keep it, you have not removed the risk — you have filed it. The point of masking at ingestion is that the unmasked version never becomes a stored object. If a regulation genuinely requires retaining the original, that is a different design and worth being deliberate about rather than defaulting into.

Related

Talk to us about your document volume

Tell us how many documents a month you process and what your peak looks like. We will size a plan, provision a key with a test quota, and answer a security questionnaire if you need one.