Use case

Bulk KYC document processing

Two different problems wear the same name. A steady flow of documents arriving daily is a throughput question. A decade of archived files is a project with an end date. They need different sizing and different code.

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

The manifest is the output that matters

A batch call returns a ZIP containing the processed documents and a manifest.json giving per-document status. The HTTP status only tells you the batch was accepted.

Masked
Something was found and redacted. File it.
No number found
Returned unchanged and still fully readable. This is the category that matters. A run reporting "4,800 documents processed" with 300 of these has left 300 readable documents in your archive.
Failed
Could not be read at all — corrupt file, unsupported format. Retry or route to review.
One document failing does not fail the batch. Quota is checked against the whole batch up front, so you are never left with a part-processed ZIP and a 429 halfway down the manifest.

Running a backlog

A worked run

Forty thousand archived documents, a four-week window. The shape of the plan matters more than the numbers.

Week 0 — sample
Run 500 representative documents. Read the manifest. If 8% come back with nothing found, the real project is 3,200 documents needing human attention, and that is the number to plan around.
Week 0 — size
40,000 documents over three working weeks is roughly 2,700 a day. Provision throughput for that, plus headroom, and step it down at the end.
Weeks 1–3 — run
Batches in parallel up to the per-minute limit, manifest rows written back to your own store as each completes, three output queues: archive, review, retry.
Week 4 — reconcile
Submitted equals masked plus no-number plus failed. Work the review queue. Record a decision for anything that cannot be fixed.
The 8% is invented; yours will differ and you will not know it until you sample. A plan built on an assumed rate is the most common way these runs overshoot.

Mistakes that cost a week

Questions we get asked

How many documents per call?

Set per plan. Higher-volume plans take larger batches; a negotiated plan can be sized to whatever your pipeline emits. Note that batching amortises the HTTP round trip, not the OCR work — fifty documents is fifty documents of processing either way.

What happens if one document in the batch is corrupt?

The rest are still processed and returned. That document gets a failed status in the manifest.

Can we mix document types in one batch?

Yes for /bulk/anonymise, which is document-agnostic. The Aadhaar and PAN batch endpoints expect their own document type.

How do we estimate how long a backlog will take?

Sample a few hundred documents first. That gives you a real processing rate and, more importantly, the proportion that come back with nothing found — which is the share needing human attention and usually the part that determines the timeline.

What is the most common way these runs go wrong?

Counting no-number findings as successes. Those documents were returned unchanged and are still fully readable, so a run reporting 40,000 processed can leave thousands of readable documents in the archive while the report says the project is done.

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.