Skip to main content
Reducto offers two processing modes: synchronous and asynchronous. The SDK provides run() and run_job() methods that map to different API endpoints: The same pattern applies to all endpoints: /extract vs /extract_async, /split vs /split_async, and /pipeline vs /pipeline_async.
The Go SDK is currently in alpha and has limited async support. Go users should use the REST API directly for async operations. See the cURL examples below.

run() vs run_job()

Both methods produce the same results. The difference is whether you wait synchronously or retrieve results later.

Synchronous: run()

The run() method handles the job lifecycle internally. If the document takes too long, the request may time out. For documents over 50 pages or complex processing, consider using run_job() instead.

Asynchronous: run_job()

The run_job() method has no limit on concurrent submissions. You can queue thousands of documents and process them in parallel without managing connections or timeouts.

Job lifecycle

When you submit a job via the async endpoint, it moves through these states: Jobs typically spend most of their time in Pending (waiting for capacity) or InProgress (actual processing).

Polling for results

The simplest way to get results from an async job is to poll the job status:
Polling is straightforward but requires keeping a process running. For production systems processing many documents, webhooks are more efficient.

Priority processing

By default, synchronous (run()) jobs are prioritized over asynchronous (run_job()) jobs. This ensures interactive requests get fast responses while background jobs process when capacity is available. You can request priority processing for async jobs if your account has priority budget available:
Priority jobs are processed before non-priority async jobs but may still queue behind synchronous requests.

Async endpoints

Every Reducto endpoint has a corresponding async variant:

Using metadata

Include metadata with your job submission to help identify and route results:
The metadata is included in webhook notifications, making it easy to match results back to your application context without maintaining a separate mapping.

When to use async

Use run() when:
  • Processing single documents interactively
  • Document size is small (under 20 pages)
  • You need results immediately in the same request
  • Testing and development
Use run_job() / async endpoints when:
  • Processing many documents in parallel
  • Documents are large or complex
  • You want fire-and-forget with webhook notification
  • Building batch processing pipelines
  • Processing in background workers

Job Retention

Jobs are deleted after 12 hours. This is part of Reducto’s zero data retention (ZDR) policy. If you query a job ID from more than 12 hours ago, you’ll receive a “Job not found” error.
Default behavior: Job results are retained for 12 hours. After this window, you’ll need to reprocess the document. For longer retention: Enable persist_results to keep results indefinitely:
persist_results requires opting in to Reducto Studio. Contact support to enable this feature for your organization.
Best practice: Always store results in your own database when you receive them via polling or webhook, rather than relying on Reducto’s retention.
You can also delete job artifacts on demand using DELETE /job/{job_id}. This removes the stored output before the automatic retention window. See Deleting Jobs & Uploads for details.

API Reference

See the full API documentation for async endpoints:

Svix Webhooks

Get notified when jobs complete instead of polling.

Batch Processing

Process many documents in parallel with run().

Chaining Endpoints

Reuse parsed documents across multiple calls.

Pipeline Basics

Bundle workflows into a single API call.