The short version: into memory, through OCR, back to you, gone. This page is the long version, written so your security team can check it against a questionnaire rather than having to ask.
Talk to our technical team → — for integration questions, a security review or a volume estimate.
To be precise, because your security team will check: a document sent to the API reaches our server — it has to, something has to run the OCR — and during OCR the engine writes it to a short-lived temporary file — held in RAM on a tmpfs mount, not on the instance’s physical disk — which is deleted within the same request. What never happens is persistence: no upload directory, no object store, no queue, and no database row holding document content. It is processed and gone when the request ends. We state the temporary file plainly rather than claim a document never touches disk at all, because the OCR stack cannot actually work that way and a strace would show the difference — and a claim your security team can disprove in one command is worse than the honest one.
Our browser tools are the genuine exception: they run entirely on your own machine and upload nothing at all. That is why they work without an account. They are for one-off documents; the API is for pipelines.
One row per API call, so you can reconstruct what a key processed and we can answer a billing dispute. These are the only fields:
/api/v1/mask-aadhaar.No filename. No document bytes. No Aadhaar number, PAN, name or date of birth — not in the audit row, and not in the response headers either. The redaction endpoints report a count by type rather than the values found, because a header carrying the identifier it just redacted would put that identifier into every access log and proxy between us and you.
403. This is the control that stops a masking customer reaching an extraction endpoint that returns the number in the clear.429; one that has spent its monthly quota gets a 429 naming the limit; one whose paid period has lapsed gets a 402.Strict-Transport-Security for one year including subdomains, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin.No. There is no temporary file, no upload directory and no object storage in the request path. The document exists in memory for the duration of the call and the buffer is released when the request ends.
No. We do not retain documents, so there is nothing to train on. The OCR and detection are pattern and checksum based rather than a trained model on customer data.
No. For images the pixels are painted over. For PDFs the page is rasterised before the redaction is drawn, which destroys the underlying text layer. Drawing a rectangle over a live PDF text layer leaves the number recoverable by copy-paste or pdftotext, and that is precisely the failure this exists to prevent.
Only the account that owns it. We store a SHA-256 hash and a 13-character prefix. Where recovery is enabled an encrypted copy lets the owner retrieve it from their own dashboard; nobody else can read it, and support identifies a key by its prefix.
Yes, on an enterprise agreement. Tell us your egress ranges and a leaked credential becomes unusable from anywhere else.
There are no documents to return or destroy, because none were stored. Account records and the request metadata are deleted on termination under the DPA.
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.