Async and Batch OCR for Long Scanned PDFs

The short answer

Use asynchronous OCR for long scanned PDFs and background document processing. A job-based API lets your application record a submission, continue other work, and collect the output when processing finishes. Keep synchronous calls for documents that reliably finish within the response time your users can accept.

Reducto’s async processing documentation recommends considering async for documents over 50 pages or complex processing. Treat that as a starting point: page count, scan quality, layout, and enabled processing options all affect the decision.

For an overnight backlog, also consider the dedicated batch queue. Standard async and the batch queue serve different turnaround requirements.

Choose between sync, async, and the batch queue

The batch queue supports /parse_async and /extract_async. Set queue_priority: "batch" to opt in. Reducto documents completion within 12 hours and 20% lower credit consumption than the equivalent standard job. This setting does not enable discounted batch processing on other endpoints.

If the batch queue is saturated, submission can return HTTP 503 with Retry-After: 300. Respect the requested delay before retrying.

Running many requests concurrently is another form of batch processing. It does not automatically select the discounted queue. Similarly, using Python’s AsyncReducto client makes your application’s requests asynchronous; use run_job() when you want the server to return a job ID for later retrieval.

Record each document before submitting it

Create a durable record for every source document and processing attempt. Include the source identifier, expected page count or selected page range, configuration version, submission time, and returned job ID.

This record becomes the basis for answering operational questions: Was this file submitted? Is it still waiting? Did processing fail? Has the output been saved?

Attach identifiers such as batch and document IDs as job metadata to help route callbacks. Keep credentials and secrets out of metadata. Preserve your own job record even when metadata makes matching results convenient.

Control how quickly you submit work. Async submission does not remove edge rate limits: excess request rates can return 429, while account concurrency throttling can increase queue time. The dedicated batch queue also has the capacity response described above.

Track the job through completion

Reducto exposes the following job states:

Keep processing status separate from application status. A job can be Completed while your application still needs to fetch its output or resolve a validation issue. Mark a document ready for downstream use only after those steps succeed.

Polling or webhooks

Polling is a straightforward option for a small workload. Schedule status checks with a sensible interval and stop at a terminal state. Avoid having every worker repeatedly query every outstanding job.

For larger workloads, Svix webhooks provide completion and failure notifications. Verify the signature against the raw request body, durably record or enqueue the event, and return a successful response promptly. Reducto’s guidance calls for a response within 15 seconds.

Use the svix-id header to recognize a repeated delivery. Make downstream writes safe to repeat as well: receiving the same result twice should not create duplicate records or trigger the same business action twice.

Separate delivery retries from processing retries

A webhook retry repeats a notification. Resubmitting a document creates another processing attempt. Handle these as separate operations.

If submission times out before you receive a job ID, the outcome may be uncertain. Your application should record that uncertainty and reconcile it with available job records or callbacks before automatically submitting another copy. Webhook deduplication alone cannot prevent duplicate submissions.

For a failed job, inspect the error before retrying. Temporary service problems may warrant another attempt; unsupported formats, invalid inputs, or missing access require a correction. Use bounded backoff with jitter for retryable errors, honor Retry-After where provided, and account for retries already performed by your SDK. See Reducto’s error reference.

Track recovery per document so one failed file does not cause an entire successful batch to be rerun.

Validate long scans before using their output

A successful API response is one part of acceptance. Define checks around the output your application needs:

• Compare the processed page count with the intended input range.
• Check that required sections and fields are present.
• Review representative pages with handwriting, faint text, or dense tables.
• Check continuity across table page breaks.

Matching page counts alone does not prove that every value was recognized correctly. Review content quality against the requirements of the downstream workflow.

When a section needs another attempt, Parse supports a page range. Include surrounding context when a table or section crosses the selected boundary, and retain the original page references when combining results.

Store results as soon as they are ready

Your result handler should support both inline Parse output and output returned through a URL. For URL-backed results, fetch the referenced content and store it successfully before marking the document ready. See the Parse response guidance.

The async documentation says job results are generally available for 12 hours. That availability window is separate from the batch queue’s 12-hour completion commitment.

Under Reducto’s data retention policy, API-submitted processing data on Growth and Enterprise typically expires within 24 hours, with exceptions for Studio-run jobs and persisted results. Confirm persistence settings with support when longer storage is required.

Growth and Enterprise also have on-demand deletion. Job artifacts and uploaded files are managed separately; deleting a job does not remove your externally hosted source document. Keep your own storage and retention policy explicit.

Measure the full batch

Use a representative evaluation set to measure submission failures, time spent waiting, processing duration, result-storage failures, and validation exceptions. Track both documents and pages that reach an accepted final state.

Ordinary async priority can move work ahead of standard async jobs, but it may still wait behind synchronous traffic. Choose the processing mode around your deadline and measure with that same mode.

For capacity sizing and vendor selection, use How to Choose a High-Volume Document Ingestion Platform. For the broader path from intake to validated output, see Document Workflow Automation.

Frequently asked questions

Do all Reducto endpoints support async?

No. Parse, Extract, Split, and Pipeline have documented async variants. Classify is synchronous only. The discounted batch queue specifically supports Parse and Extract async requests.

Does async OCR improve recognition accuracy?

Choosing async changes how the job runs and how you receive its result. Evaluate recognition quality separately using the same documents and processing configuration.

Should every scanned PDF use async?

No. A short scan may fit an interactive request. Prefer async when document complexity, processing time, or background workload makes keeping the original request open impractical.