How DeepRead Works
How DeepRead Works
DeepRead processes documents as background jobs. You upload a document, poll for the result or get a webhook, and receive Markdown text + optional structured JSON with per-field needs_review flags.
What DeepRead Does
Two engines read the document. extract (the default on Free and Standard) is one OCR pass; deep-extract (the default on Enterprise) reads every page twice, reconciles the two reads and verifies every extracted value. Both end with the same outputs.
extractdeep-extractThe Processing Pipeline
Every document follows this flow; the middle depends on the engine you pick with pipeline:
Why async? These pipelines take seconds per page on extract and longer on deep-extract; async avoids request timeouts.
API Flow
- Submit a document to
POST /v1/process→ returns{ "id": "...", "status": "queued" } - Receive webhook notification when job completes (or check status manually with
GET /v1/jobs/{id}) - Use results (every response carries
schema_version: "dp02"):document.content.text= Markdown OCR outputdocument.layout= typed dp.lite.v1 layout object (blocks + page-mappings, on either engine)extraction.fields= structured extraction list (if you provided a schema)review.review_rate+ per-fieldneeds_review= what needs verification
See the API Reference for ready to implement examples: API Reference.
Structured extraction
To keep extraction accurate and fast on long documents, DeepRead uses a two-phase strategy:
- Field page detection (fast): scans all pages (text-only) to find which pages likely contain each field’s value
- Field extraction (accurate): runs vision extraction only on the relevant pages and returns per-field
needs_reviewflags + validation
When validation fails, the field is flagged with needs_review: true and a review_reason.
How to read the results
Key idea: treat needs_review as your “needs verification” switch, and use the review summary for routing.
{ "status": "completed", "schema_version": "dp02", "extraction": { "fields": [ { "key": "total_amount", "value": 1250.0, "needs_review": true, "review_reason": "Consensus disagreement on page 3: ...", "location": { "page": 3 } } ] }, "review": { "quality_score": 0.95, "review_rate": 0.05 } }
See Human Review Flags and Jobs & Webhooks.
Optimizer
The optimizer improves your schema using sample documents (not run on every production job). See The Optimizer.
Error Handling
Failed jobs return status: "failed" with an error message. Common errors:
| Status | Cause |
|---|---|
failed | Pipeline step error or timeout |
400 | Invalid schema or request, or a file that could not be converted to PDF |
402 | The plan does not include a feature you sent, or the credits do not cover the job (the body names what) |
402 | The API key is at its monthly spend limit (key_limit_reached) |
404 | Job not found or expired |
409 | The idempotency_key was used before with a different file or options |
413 | Document over the hard maximum (2,000 pages or 500 MB) |
415 | The plan does not accept this file type (the body names the plan that does) |
429 | Submissions per minute, pages in flight, polling, or the monthly allowance exceeded (Retry-After set) |
503 | The API key could not be checked because our database did not answer; retry after Retry-After (5 s) |
See Error Handling & Retry for recovery strategies.