Security

Where your documents go

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.

The document lifecycle, in full

1. In transit
HTTPS only. HTTP is redirected permanently, and HSTS is set for one year including subdomains, so a browser or client that has seen us once will not fall back to plaintext.
2. In memory
The upload is read into memory and passed to OCR. It is never written to a temporary file, never queued, never uploaded anywhere else.
3. Processing
OCR and redaction happen in-process on the same host. PDFs are rasterised, which is what makes the redaction real rather than an annotation over a live text layer.
4. Response
The result streams back to you. The buffer holding it is released when the request ends.
5. After
Nothing of the document survives. One metadata row is written — see below — and that row contains no document content.
Your documents are never written to our disks. They exist only in memory, for the length of one request, and are gone the moment it ends. Plenty of vendors say "no retention" and mean "we delete nightly". We mean there is nothing to delete: no filesystem write, no bucket, no temp directory, no queue. If our database were fully compromised tomorrow, not one customer document would be in it, because none was ever put there.

To be precise, because your security team will check: a document sent to the API does reach our server — it has to, something has to run the OCR. What it never does is land on a disk. It is read into memory, processed, streamed back and released. Any vendor telling you an uploaded document never reaches their infrastructure is describing something that cannot work, and a network trace will show it.

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.

What is actually recorded

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:

key_id
Which credential made the call. Not the key itself.
endpoint
Which operation, e.g. /api/v1/mask-aadhaar.
file_type
pdf, jpg or png.
file_size_bytes
The size of what was sent.
masked_count
How many regions were redacted, or fields returned. A number, not the values.
processing_ms
How long it took.
status_code
What we answered.

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.

Credentials and access control

Infrastructure

Region
AWS ap-south-1 (Mumbai). Single region. Documents are processed there and nowhere else.
Ingress
Caddy terminating TLS, with certificates renewed automatically. Strict-Transport-Security for one year including subdomains, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin.
Application
Containerised, running as an unprivileged user. Port 8000 is not published to the host — the reverse proxy is the only ingress.
Database
Managed Postgres holding accounts, plans, key hashes and the metadata rows above. Row-level security is enabled, so the anon key cannot reach a password hash or a key hash. The application connects with a service role.
Documents at rest
None. There is no document at rest to encrypt, because no document is ever written down.
What we do not claim. We are not SOC 2 or ISO 27001 certified today and we will not imply otherwise on a page your auditor is reading. If a certification is a hard requirement for your procurement, tell us before you spend time on an evaluation.

Questions we get asked

Do documents ever touch disk?

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.

Do you use our documents to train models?

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.

Is the redaction reversible?

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.

Who can see our API key?

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.

Can you restrict our key to our own IP ranges?

Yes, on an enterprise agreement. Tell us your egress ranges and a leaked credential becomes unusable from anywhere else.

What happens to our data if we leave?

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.

Read next

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.