Document Masking API

Mask any document, not just a card

Most masking tools know one document. A KYC folder is never one document. This endpoint covers identifiers wherever they are printed, on forms nobody has classified, with no parser to write and nothing to configure per document type.

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

The folder, not the card

Aadhaar is the identifier with a law attached, which is why every vendor names it first. It is not the one that turns up most often. A single onboarding folder routinely carries a PAN, a bank account and IFSC, a mobile number, an email address, and a GSTIN on the invoice stapled behind them — printed on a rent agreement, a salary slip and a utility bill as often as on an identity card.

An endpoint that only understands Aadhaar cards leaves all of that readable in your archive. Document masking is the same idea one level up: stop matching documents, start matching identifiers.

Aadhaar masking
Knows it is looking at an Aadhaar card. Produces the UIDAI-recognised masked form, last four digits left readable, so the document still works as a KYC record.
PAN masking
Knows it is looking at a PAN. Covers the middle of the number and leaves the structure intact.
Document masking
Knows nothing about the document. Finds identifiers wherever they are printed, on a form it has never seen.

They are not substitutes. Use the specific endpoints on the cards you are filing as KYC evidence, and this one on everything else that arrived with them.

What gets covered

A wrong mask cannot be undone. That is the whole reason bank_account is off by default and why the type list is worth narrowing when you know what the document is. GET /api/v1/pii-types returns the current list as JSON, unauthenticated, so you can read it before a key is issued.

Masking or redaction

Masking
Covers part of the identifier and leaves enough to recognise it — the last four Aadhaar digits, the structure of a PAN. The document stays usable as a KYC record.
Redaction
Covers the identifier entirely. Use it when the document needs to be shareable rather than usable as identity evidence.

Mask what you keep. Redact what you send. If you are handing a document to a third party, an analyst or a model, you want redaction — and the PII firewall is that call placed at the boundary.

PDFs are rasterised rather than annotated. Drawing a rectangle over a PDF leaves the text readable underneath by copy-paste or pdftotext, which is not a mask at all. See PDF PII redaction for why that distinction decides whether the work was real.

Questions we get asked

What counts as a document here?

Any JPEG, PNG or PDF. The endpoint matches identifiers rather than recognising layouts, so a rent agreement, a salary slip, a utility bill or a hospital discharge summary is handled with no per-document work.

How is this different from the Aadhaar masking API?

The Aadhaar endpoint knows it is looking at an Aadhaar card and produces the UIDAI-recognised masked form, with the last four digits left readable so the document still works as a KYC record. Document masking is the general case: it does not know what the document is, and covers whatever identifiers it finds.

Should I mask or redact?

Mask what you keep as a KYC record, because the last four digits are what make it usable as identity evidence. Redact what you send to a third party, because there the goal is that the document carries nothing at all.

Do you keep the document?

No. It is processed in memory and returned in the same response. Nothing is written to disk, and no identifier values are returned in headers — only counts by type.

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.