Bulk Processing API

Many documents, one call

The same operations as the single-document endpoints, taking a batch and returning a ZIP with a manifest. Built so a run of ten thousand documents is a script you can leave running, not a project.

Talk to us about your document volume Read the docs

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

3 endpointsmask Aadhaar, mask PAN, redact
Manifestper-document status
Quota up frontno part-processed batch
Batch sizeset per plan
ZIPdocuments plus manifest.json

The endpoints

POST /api/v1/bulk/mask-aadhaar

Batch Aadhaar masking.

POST /api/v1/bulk/mask-pan

Batch PAN masking.

POST /api/v1/bulk/anonymise

Batch PII redaction, document-agnostic — use this one for mixed document types.

All three take the files under the files field, not file. Sending the wrong field name is a 422 and is the most common first-integration mistake.

What comes back

A ZIP, containing the processed documents and manifest.json.
Per-document status in the manifest: masked, no number found, or failed. The HTTP status tells you only that the batch was accepted.
Headers summarising the run: documents submitted, documents masked, documents where nothing was found, documents failed.
Quota checked against the whole batch up front, so you never receive a part-processed ZIP with a 429 halfway down it.
Charging follows the single-document rule: only documents that produced a redaction are billed.

Batch size is a plan setting. If your plan allows one document per call, the batch endpoints still work — they just take one at a time. Tell us the batch size your pipeline emits and we will size it to that rather than leaving you to discover the limit with a 413.

Working the manifest

The ZIP is the output people look at. The manifest is the output that decides whether the run actually worked.

Match on your own id

Name files with a stable identifier from your system before you send them, so the manifest can be joined back to your records without relying on the original filename surviving.

Persist it

Write manifest rows into your own store as the run proceeds. This is what makes a run resumable, and a long run will be interrupted.

Split the outcomes

Masked documents go to the archive. No-number findings go to a review queue. Failures go to a retry queue. Three destinations, not one.

Reconcile at the end

Documents submitted should equal masked plus no-number plus failed. If it does not, something in your own pipeline dropped a file.

Sizing a run

Batch size is a plan setting, not a fixed number. Tell us what your pipeline emits and it is provisioned to that, rather than leaving you to find the ceiling with a 413.
Batching saves round trips, not compute. Fifty documents in one call is fifty documents of OCR. What it buys is one thing to track, retry and log instead of fifty.
Quota is checked against the whole batch up front. A batch that would exceed your remaining quota is refused cleanly rather than part-processed, so you never have to reconcile a half-finished ZIP.
Concurrency belongs to your side. Run several batches in parallel up to your per-minute rate; do not put the whole backlog in one request and hope.
Time-box the run. Backlog throughput is provisioned for a window and stepped down afterwards, so you are not carrying peak capacity for the rest of the year.

Questions we get asked

How large can a batch be?

It is set per plan rather than per tier. Tell us what your pipeline emits and we size it. Exceeding it returns 413 naming the limit.

Does batching make processing faster?

It removes the per-request round trip and connection overhead, which is real but modest. It does not reduce the OCR work — fifty documents is fifty documents either way. The bigger win is operational: one call to track instead of fifty.

What if the batch exceeds our remaining quota?

It is refused up front with a 429 rather than part-processed. You get a clean failure to retry after a renewal instead of a ZIP you have to reconcile.

How do we make a long run resumable?

Name files with a stable id from your own system, and write manifest rows back into your own store as each batch completes. A run that restarts from the beginning after an interruption will not finish, and it will be interrupted.

Is one big batch better than several small ones?

No. Batching removes per-request overhead, not OCR work, and one enormous request is a single point of failure with a long timeout. Several batches running in parallel up to your per-minute limit is both faster and easier to retry.

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.

Contact sales Enterprise overview