Indian customer documents, end to end: strip what you must not keep, read what you need, check the card is what it claims to be, and run the whole thing over a batch. Twenty-two capabilities across five layers, behind one key.
Talk to our technical team → — for integration questions, a security review or a volume estimate.
A customer document passes through the same five questions at every institution that handles one. What must not be kept? What does it say? Is it what it claims to be? Should it be trusted? And how does that happen ten thousand times without a person in the loop.
The identifiers on a customer document outlive every process you built around them. This layer is what stops a document being a liability the moment it is stored.
Find Aadhaar, VID, PAN, passport, voter EPIC, driving licence, GSTIN, IFSC, phone and email on a document nobody has classified. Checksum validated where a checksum exists.
Cover the identifier and rasterise the page, so nothing is recoverable underneath by copy-paste or pdftotext.
Replace an identifier with a stable token instead of a black box, so records can still be joined and matched without holding the value. Talk to us about what your join key needs to survive.
One call between a document arriving and a document reaching your database, your warehouse or a model you do not control.
A document nobody has read is a document somebody will have to. This layer turns the file into fields.
Read an Indian identity document in the conditions it actually arrives in — a phone photo, a rotated scan, a compressed forward.
Establish what a file is before deciding what to do with it, so a folder of mixed uploads can be routed without a person sorting it.
Name, date of birth, gender and address as JSON, so the customer record fills itself. The Aadhaar number comes back masked by default.
Turn a statement into transactions, balances and the patterns a credit decision is actually made on, rather than a PDF an analyst scrolls.
Line items, totals, GSTIN and dates off an invoice, in the many layouts Indian invoices come in.
Reading a document tells you what it says. It does not tell you whether to believe it. Aadhaar is the one Indian document where belief can be proved rather than estimated, because UIDAI signs the QR payload.
Check the printed text against the data UIDAI signed into the QR code. A forger cannot re-sign the payload, so a disagreement is a finding rather than a suspicion.
Establish that a PAN is structurally valid and belongs to the holder the document names.
Put two documents side by side and report where they disagree — the check nobody runs, on the pair everybody collects.
Whether the name, date of birth and address agree across every document in one customer's folder. Most fraud is not a forged card; it is a folder that does not add up.
Normalise an Indian address, then decide whether two of them are the same place — given that they will never be the same string. More below.
The most underrated check in Indian KYC. Two documents almost never spell an address the same way, and almost nobody compares them, because a string comparison says they disagree and a human says they obviously match.
Normalisation comes first — the same place, written the way every downstream system can agree on:
Flat 4B, XYZ Apartments,
Near ABC Chowk,
Rohtak, Haryana 124001
↓
{
"address_line": "Flat 4B, XYZ Apartments, Near ABC Chowk",
"city": "Rohtak",
"state": "Haryana",
"pincode": "124001",
"normalized": true
}
normalized is the field that matters,
and it is why this is a capability of its own rather than something the extraction endpoints
do quietly. Aadhaar addresses are not consistently structured. Split them blindly and roughly
a fifth come out wrong — and components that are wrong a fifth of the time are worse than
one honest string, because the caller cannot tell which fifth. A flag that admits when
the split is unreliable is the difference between a component you can join on and a component
that quietly corrupts a match.
Then the comparison. The same customer's address arrives on documents that were never meant to agree with each other:
Three documents nobody currently compares, on the check that catches the folder that does not add up.
What counts as a match is still your policy. A lender verifying a mortgage address and a fintech doing light-touch onboarding should not be using the same threshold, and we are not the right party to pick one for you.
Reasons to disbelieve a document, each one named. There is no score here, and that is deliberate — see below.
Where a printed field disagrees with the signed payload, the specific field is reported: name, date of birth, last four digits, gender, pincode.
A card whose signature does not verify, or whose QR was replaced wholesale, is a different failure from a card that was photographed badly. The response distinguishes them.
The same document submitted twice under two identities, across a portfolio rather than within one application.
Every finding arrives as an identifier with a severity and a plain-language reason, so a reviewer can act on it in seconds.
qr_name_mismatch. Named signals can be argued with, which
is the property that matters.One document is an integration. Ten thousand a month is an operation.
A batch in, a ZIP out, with a manifest naming every document that came back unchanged — the ones still carrying a readable number.
Verify, extract, redact and store as one ordered pipeline rather than four calls you sequence yourself.
Documents with a validity date stop being valid while they sit in your archive. Knowing which ones, before an auditor does.
A callback when a batch finishes, so a long queue does not have to be polled.
Selling five capabilities separately makes the customer the integrator. They sequence the calls, hold the intermediate state, decide what a disagreement between two steps means, and own the audit trail. A KYC case does that for them: one object, one decision, one record of how it was reached.
One call in, a decision and its reasons out.
The decision step collects signals rather than emitting a
score, for the reason set out under Trust. A case that comes back review arrives
with the named findings that put it there, so a human clears it in seconds instead of
interpreting a number. Your own policy decides which signals are disqualifying — that
threshold belongs to your risk team and your regulator, not to us.
This is the layer most worth having and the one that needs the most agreement about your process before it is worth building. Tell us what your case flow looks like — the institutions that describe theirs are the ones it gets designed around.
Every capability authenticates with the same X-API-Key
header and takes the same multipart/form-data body with a single file
part. That is the whole reason to buy a platform rather than five vendors: the second
capability is a URL change, not a second integration, a second contract and a second security
review.
curl -X POST https://api.maskaadhaar.com/api/v1/mask-aadhaar \ -H "X-API-Key: $MASKAADHAAR_KEY" \ -F "file=@document.pdf" \ --output masked.pdf
The API reference documents every endpoint
that is live, with its parameters, headers and errors.
GET /api/v1/pii-types returns the current detection list as JSON and needs no
authentication, so you can read it before a key is issued. For anything on this page you want
to build against, talk to our technical team —
knowing which capability you need next is how it gets prioritised.
One API and one key. Every capability uses the same authentication, the same quota and the same multipart request shape, so adding a second capability to an existing integration is a URL change rather than a new project.
No. Most customers start with one capability, usually masking or redaction, because that is the one with a compliance deadline attached. The rest are there when you need them.
Because a score that decides whether a real person gets a loan has to be calibrated against labelled genuine and forged documents in your own capture conditions, and an uncalibrated number manufactures confidence with nothing behind it. The Trust capabilities return named signals instead: a compliance officer can defend a named signal at an audit and cannot defend 0.83.
The API reference documents every endpoint that is live right now, and GET /api/v1/pii-types returns the current detection list as JSON without authentication. Those two are the authoritative answer at any moment. Talk to us about anything on this page you want to build against.
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.