DEV Community: sushrut mishra

The best OCR and document extraction APIs for developers in 2026

sushrut mishra — Tue, 06 Oct 2026 06:05:25 +0000

Run a phone photo of a crumpled receipt through a plain OCR engine and you get a wall of characters with the totals in the wrong spots. Useless. That gap, between reading the text and actually understanding the document, is what splits the seven tools here.

Some you host yourself for free. Some are cloud APIs built for whatever stack you're already on. One reads the layout first and hands back real structure. That's how the list is sorted, and every tool gets a snippet you can paste and run.

Agentic extraction: reading beyond OCR

LandingAI's Agentic Document Extraction (ADE)

LandingAI's Agentic Document Extraction (ADE) isn't really an OCR engine, and that's the point. Plain OCR turns pixels into characters. ADE reads the layout first, works out what each block is, and hands you structured data an agent can just use.

Parse reads a document down to its lines and table cells, and grounds every one of them: each value carries its own page, character range, and bounding box, so it points straight back to where it sits on the page. What comes back is reading-order Markdown plus a structured tree of pages, elements, lines, and cells, each with a stable id. Feed that Markdown to Extract, and typed JSON comes back with every value still traceable to its page.

On the infrastructure side, ADE ships Python and TypeScript SDKs and a CLI, plus an async Jobs API for large batches, and a single document can run up to 6,000 pages or 1 GB. Credits run at a flat $1 for every 100, across every tier. For a regulated shop, there's HIPAA-compliant processing with a BAA and a Zero Data Retention option starting at the Team tier, and VPC or on-premises deployment on Enterprise.

Reach for it when you need structured, checkable output from messy documents, not raw text you'll spend a day reshaping.

Install with pip install landingai-ade. A minimal Parse flow, submitting a job and reading back the result, looks like this:

from landingai_ade import LandingAIADE

client = LandingAIADE()  # reads VISION_AGENT_API_KEY

job = client.v2.parse_jobs.create(
    document_url="https://your-storage.example.com/scanned-invoice.pdf",
    service_tier="standard",
)
done = client.v2.parse_jobs.wait(job.job_id, raise_on_failure=True)

# done.result.markdown holds the reading-order Markdown, grounded per element
print(done.result.markdown)

Managed cloud OCR APIs

Mistral OCR

Mistral OCR is a vision language model that reads a page and gives you Markdown back, with image bounding boxes and structure metadata. It handles 40 plus languages and takes PDFs and the usual image formats, and because the output is Markdown per page, it drops into an LLM pipeline with barely any cleanup. It's a hosted call to Mistral, and it's one of the cheaper managed options per page.

Reach for it when you've got multilingual docs and you care more about clean Markdown than where it runs. Install with pip install mistralai. One call, page Markdown out:

from mistralai import Mistral

client = Mistral(api_key="YOUR_KEY")
ocr_response = client.ocr.process(
    model="mistral-ocr-latest",
    document={"type": "document_url", "document_url": "https://example.com/doc.pdf"},
)
print(ocr_response.pages[0].markdown)

AWS Textract

If you're already on AWS, Textract is the path of least resistance. Its detect_document_text call reads printed and handwritten text and gives you lines and words with coordinates, and when you need forms and tables too, analyze_document covers that at a higher price. Pricing runs per feature and per page, so a plain text call costs less than a forms-and-tables one.

Reach for it when you want dependable text plus location data inside an AWS pipeline. It runs through boto3, and the pure OCR call is detect_document_text:

import boto3

client = boto3.client("textract")
with open("scanned-form.png", "rb") as f:
    resp = client.detect_document_text(Document={"Bytes": f.read()})

for block in resp["Blocks"]:
    if block["BlockType"] == "LINE":
        print(block["Text"])

Azure AI Document Intelligence

Azure AI Document Intelligence is the old Form Recognizer, renamed. Its prebuilt-read model pulls printed and handwritten text out of PDFs and scans, and it reads Word, Excel, PowerPoint, and HTML too, tracking paragraphs, lines, words, and languages along the way. It runs as a cloud call or as an on-premises Docker container, which matters when your data can't leave the building, and the same Read engine underlies Azure's Layout, Invoice, and Receipt models, so moving up to structure later is a small step rather than a rebuild.

Reach for it when you're on Azure and want OCR with a clear path to prebuilt document models. Install with pip install azure-ai-documentintelligence. Point prebuilt-read at a file:

from azure.ai.documentintelligence import DocumentIntelligenceClient
from azure.core.credentials import AzureKeyCredential

client = DocumentIntelligenceClient(
    endpoint="https://<resource>.cognitiveservices.azure.com/",
    credential=AzureKeyCredential("YOUR_KEY"),
)
with open("scanned-doc.pdf", "rb") as f:
    poller = client.begin_analyze_document("prebuilt-read", body=f)
print(poller.result().content)

Google Cloud Vision

Google Cloud Vision is Google's general image API, and OCR is one feature among many. DOCUMENT_TEXT_DETECTION handles dense and handwritten pages and returns them as pages, blocks, paragraphs, words, and symbols with bounding boxes, and it figures out the language on its own. Pricing runs per image and per feature, with the first 1,000 units a month free and a flat rate after that.

Reach for it when you're on GCP and want reliable OCR with plenty of per-word metadata to build on. Install with pip install google-cloud-vision. Document mode handles dense and handwritten pages:

from google.cloud import vision

client = vision.ImageAnnotatorClient()
with open("handwritten-note.png", "rb") as f:
    image = vision.Image(content=f.read())

response = client.document_text_detection(image=image)
print(response.full_text_annotation.text)

Open source OCR engines

Tesseract OCR

Tesseract is the old reliable: open source, Apache 2.0, backed by Google, and able to read 100 plus languages entirely on your own hardware. You get plain text out of the box, with hOCR and TSV available if you want word positions. It nails clean scans. Throw handwriting, tables, or a bad photo at it, though, and you're writing the cleanup yourself.

Reach for it when you want free, self-hosted OCR and your documents are reasonably tidy. Install the Tesseract binary, then pip install pytesseract pillow:

import pytesseract
from PIL import Image

text = pytesseract.image_to_string(Image.open("scan.png"))
print(text)

PaddleOCR

PaddleOCR is Baidu's open source OCR toolkit, also Apache 2.0. It turns PDFs and images into structured, LLM-ready JSON or Markdown, and it reads a lot of languages. PP-OCR pairs detection with recognition, and the PP-Structure pipeline adds layout, tables, and reading order on top. It runs locally on CPU or GPU, which makes it a fit for self-hosted and air-gapped setups.

Reach for it when you want open source OCR that keeps structure, especially for multilingual or Chinese text. Install PaddlePaddle, then pip install paddleocr:

from paddleocr import PaddleOCR

ocr = PaddleOCR(lang="en")
result = ocr.predict("scan.png")
print(result)

How the seven compare

Tool	Text type	Languages	Output	Deployment	Cost model
LandingAI ADE	Print, handwriting, scans	Broad, incl. non-Latin	Markdown + structured JSON	Cloud, VPC, on-prem	Credit-based
Mistral OCR	Print, scans	40+	Markdown	Managed cloud	Per page
AWS Textract	Print, handwriting	Broad	Text + blocks	AWS cloud	Per feature, per page
Azure AI Document Intelligence	Print, handwriting	Broad	Text + layout	Cloud, on-prem container	Per page
Google Cloud Vision	Print, handwriting	Broad	Text + blocks	Cloud, on-prem option	Per image, per feature
Tesseract OCR	Print, clean scans	100+	Plain text	Self-hosted	Free
PaddleOCR	Print, scans	Many	JSON, Markdown	Self-hosted	Free

Matching the tool to the job

The right pick follows from what you're actually optimizing for. If you're pulling structured data out of messy or regulated documents, LandingAI ADE is the one built for it: you get grounded structure instead of raw text to reshape yourself. If the job is clean Markdown from multilingual pages, Mistral OCR does that with the least friction.

If you're running OCR inside a cloud you're already committed to, stay there: Textract on AWS, Azure AI Document Intelligence on Azure, Cloud Vision on GCP. And if the requirement is free, self-hosted, or air-gapped, Tesseract handles clean scans well, while PaddleOCR is the better choice once you also need layout and tables preserved.

Whatever you land on, test it against your worst documents, not the clean sample in the docs. The photographed receipt, the multi-column scan, the handwritten form: that's where these tools actually fall apart, and it's the part that bites you later if you skip it now.

OCR versus document extraction, and a few practical differences

OCR turns pixels into characters. Extraction goes further and reads layout, tables, and fields, then hands back structured data. ADE sits on the extraction side of that line; Tesseract and Cloud Vision sit closer to plain OCR.

Handwriting support varies more than people expect. Textract, Azure AI Document Intelligence, and Cloud Vision all read it reasonably well. Tesseract is built for printed text and does a poor job on handwriting.

Running fully offline is possible with a few of these. Tesseract and PaddleOCR run entirely on your own hardware. Azure and Google both offer on-premises container options, and ADE offers VPC and on-premises deployment on its Enterprise tier.

7 document extraction APIs worth building on in 2026

sushrut mishra — Tue, 06 Oct 2026 06:04:58 +0000

Picking a document extraction API in 2026 comes down to one question: can you trust the output enough to act on it without someone re-reading the page? Here's the short version, before we get into the details:

For extraction you can verify value by value, LandingAI's Agentic Document Extraction (ADE) grounds every field to the exact line it came from, and Reducto is its closest agentic peer. If your data has to stay inside AWS, Google Cloud, or Azure, the native service is the easy path. And if budget rules and you can self host, Docling and Unstructured do the job for free.

Every tool below comes with a minimal snippet, so you can see how it is actually called rather than only what its pricing page claims.

The 7 document extraction APIs, compared

Each option is judged on the four things that decide whether an extraction survives production: how it structures its output, whether it grounds each value back to the page, where it can run, and how it prices at volume.

LandingAI's Agentic Document Extraction (ADE)

LandingAI's Agentic Document Extraction (ADE) is built around one idea: ground everything. Every element Parse returns comes with its own page, character range, and bounding box, so you can trace any extracted value back to exactly where it sits on the page. The second generation runs on the DPT-3 model family, and the whole output is built for code to consume, not for a person to skim.

Parse itself returns reading-order Markdown plus a hierarchical breakdown: pages, elements, lines, table cells, each carrying its own stable id and its grounding. Hand that Markdown to Extract, and it pulls your fields into typed JSON where every value still traces back to its exact page location.

On the infrastructure side:

Python and TypeScript SDKs, plus a CLI
An async Jobs API built for large batches
Single documents up to 6,000 pages or 1 GB
HIPAA-compliant processing with a BAA and a Zero Data Retention option, starting at the Team tier
SLAs, uptime guarantees, priority rate limits, and VPC or on-premises deployment on Enterprise

Best for: developers who need to verify extraction field by field, especially in audit and regulated workflows.

Install it with pip install landingai-ade. Here's a minimal Parse flow: submit a job, wait for it, read back the result.

from landingai_ade import LandingAIADE

client = LandingAIADE()  # reads VISION_AGENT_API_KEY

job = client.v2.parse_jobs.create(
    document_url="https://your-storage.example.com/invoice.pdf",
    service_tier="standard",
)
done = client.v2.parse_jobs.wait(job.job_id, raise_on_failure=True)

# done.result.markdown holds the reading-order Markdown, grounded per element
print(done.result.markdown)

From there, Extract takes that Markdown plus a schema you define and returns typed JSON, with every value still traceable back to its page location. The Extract API reference has the exact schema and request format if you want to go deeper.

Reducto

Reducto takes on the full document lifecycle in one platform: parse, extract, classify, split, and edit. It grounds every value to a bounding box citation, and it leans on multi-step layout analysis plus a self-correcting OCR pass to handle the pages other tools choke on.

It returns layout-aware chunks that are ready for retrieval, so you skip a second re-chunking pass.

It reports processing over four billion pages. Deployment options run cloud, VPC, on-premises, and air-gapped, and higher tiers add SOC 2 Type II, HIPAA, and Zero Data Retention.

On the independently published LongExtractBench, it completed all 225 long documents at 99.6% precision and recall.

Best for: regulated teams that lead their evaluation with hard documents. Trade-off: the advanced agentic modes cost more credits than basic OCR.

Install with pip install reductoai. You upload a file, then run parse or extract against it:

from pathlib import Path
from reducto import Reducto

client = Reducto()  # reads REDUCTO_API_KEY
upload = client.upload(file=Path("invoice.pdf"))

result = client.extract.run(
    input=upload.file_id,
    instructions={"schema": {
        "type": "object",
        "properties": {
            "document_date": {"type": "string"},
            "amount_due": {"type": "number"},
        },
    }},
)
print(result)

LlamaParse

LlamaParse is the parsing layer inside the LlamaIndex ecosystem, which makes it the obvious pick if you're already building retrieval and agents there. It reads visually complex pages using vision language models and hands back RAG-ready Markdown you can drop straight into a LlamaIndex pipeline.

It covers 90+ formats and offers a few parse modes, from a fast pass on digital text to a slower, agentic mode reserved for the hardest pages. Because the integration with LlamaIndex is native, you skip the glue code most RAG projects end up writing by hand.

Best for: RAG projects already standardized on LlamaIndex. Trade-off: credits are tiered, and which mode you pick affects the bill more than page count does.

Install with pip install llama-cloud-services. A minimal parse returns Markdown you can feed straight into a pipeline:

from llama_cloud_services import LlamaParse

parser = LlamaParse()  # reads LLAMA_CLOUD_API_KEY
documents = parser.load_data("invoice.pdf")
print(documents[0].text)

Docling

Docling comes out of IBM Research and now lives under the Linux Foundation as an MIT-licensed open source project. If you want strong layout-aware parsing but need to run it yourself, this is the strongest free option available. It converts PDFs, Office files, HTML, and images into one unified, traceable representation, entirely on your own infrastructure.

It ships as a Python library, a CLI, an HTTP service, and an MCP server, which makes it a natural fit for air-gapped environments. There's no per-page API cost either, which matters if you're ingesting at high volume on a tight budget.

Best for: teams comfortable owning their own infrastructure. Trade-off: you're running and tuning the pipeline yourself, with no vendor SLA to fall back on.

Install with pip install docling. It converts a file locally and exports Markdown:

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("invoice.pdf")
print(result.document.export_to_markdown())

Unstructured

Unstructured pairs an open source library with a hosted platform, and it's built for breadth. If you need to pull in many file types rather than squeeze maximum accuracy out of one, this is the tool. It partitions PDFs, emails, HTML, and Office files into typed, metadata-rich elements ready for chunking.

Connector support is broad on both ends, sources and destinations, which makes it easy to pull mixed document sets into a vector store. It also exposes element-level coordinates, and the hosted platform adds SOC 2 Type II, HIPAA, and in-VPC deployment.

Best for: large-scale, multi-format RAG ingestion. Trade-off: table fidelity and reading order on complex, multi-column layouts need more tuning here than on the vision-first platforms.

Install with pip install "unstructured[pdf]". One call partitions a file into typed elements:

from unstructured.partition.auto import partition

elements = partition(filename="invoice.pdf")
for el in elements:
    print(el.category, el.text)

AWS Textract

AWS Textract is Amazon's managed OCR and form extraction service, and if your stack already lives on AWS, it's the path of least resistance. It reads printed and handwritten text, pulls key-value pairs and tables, and returns geometry coordinates for every block it detects.

Pricing runs per feature and per page, across Detect Text, Analyze Tables, Analyze Forms, and Analyze Queries. It's tightly wired into the rest of the AWS stack too.

Best for: high-volume, AWS-native pipelines with fairly predictable documents. Trade-off: the output is raw, so restoring reading order and semantic structure is work you write yourself.

It runs through boto3, and it returns blocks rather than your schema:

import boto3

client = boto3.client("textract")
with open("invoice.png", "rb") as f:
    resp = client.analyze_document(
        Document={"Bytes": f.read()},
        FeatureTypes=["FORMS", "TABLES"],
    )

# resp["Blocks"] holds LINE, KEY_VALUE_SET, TABLE, and CELL blocks

Turning those blocks into your target JSON is a step you write yourself, often with a second model call.

Google Document AI

Google Document AI is Google Cloud's document processing suite, organized around processors for OCR, form parsing, and a handful of specialized document types. If you're standardized on GCP, this is the natural choice. Each processor returns structured fields with bounding regions, and the specialized parsers handle common formats like invoices and receipts right out of the box.

Pricing runs per processor and per page, depending on which ones a given workflow calls. It wires directly into BigQuery, Vertex AI, and the rest of the Google stack.

Best for: managed extraction inside GCP. Trade-off: it stays inside its home cloud, so your data stays resident in GCP too.

You call a processor you have created in the console:

from google.cloud import documentai

client = documentai.DocumentProcessorServiceClient()
name = client.processor_path("PROJECT_ID", "us", "PROCESSOR_ID")

with open("invoice.pdf", "rb") as f:
    raw = documentai.RawDocument(content=f.read(), mime_type="application/pdf")

result = client.process_document(
    request=documentai.ProcessRequest(name=name, raw_document=raw)
)
print(result.document.text)

How the 7 stack up at a glance

Tool	Output	Grounding	Deployment	Pricing	Best for
LandingAI ADE	Markdown + JSON elements	Element-level (page, character range, bounding box)	Cloud, VPC, on-prem	Credit-based, priced per model and tier	Verifiable, audit-ready extraction
Reducto	Layout-aware chunks	Bounding box citations	Cloud, VPC, on-prem, air-gapped	Credit-based, complexity-tiered	Hard docs, regulated teams
LlamaParse	RAG-ready Markdown	Layout bounding boxes	Managed cloud, enterprise options	Credit-based, tiered modes	LlamaIndex RAG projects
Docling	Unified doc, Markdown	Partial layout metadata	Self-hosted, local, air-gapped	Free, open source	Self-hosted ingestion
Unstructured	Typed elements	Element-level coordinates	Open source, hosted, in VPC	Free library, usage-based platform	Broad multi-format ingestion
AWS Textract	Raw text, tables, forms	Block geometry, page level	AWS cloud	Per feature, per page	AWS-native pipelines
Google Document AI	Structured fields	Bounding regions	GCP cloud	Per processor, per page	GCP-native workflows

How to choose the right document extraction API

The right choice comes down to whatever constraint is actually squeezing your project. A few starting points:

Need to verify every value for an audit or a human review? Look at the agentic grounding platforms: LandingAI ADE and Reducto.
Locked into a specific cloud? Use that cloud's native service: Textract for AWS, Google Document AI for GCP, Azure Document Intelligence for Azure.
Working with a tight budget and comfortable self-hosting? Docling and the Unstructured library get you there for free.
Already building on LlamaIndex? LlamaParse saves you the integration work.

Whichever way you lean, run your own test before committing. Take a sample of your hardest documents, run it through two or three finalists, and look closely at the grounding, the table fidelity, and the actual cost on pages that resemble production, not the demo.

Frequently asked questions

Which document extraction APIs run on-premises?
LandingAI ADE offers VPC and on-premises deployment on its Enterprise tier, and Reducto offers the same on its enterprise tiers. Docling runs fully locally, air-gapped included. Azure Document Intelligence has a container option, while Textract and Google Document AI stay inside their home clouds.

Which options are free?
Docling and the Unstructured library are free to self-host. LandingAI ADE's Explore tier starts you off with 1,000 free credits on a pay-as-you-go basis, and most other managed APIs offer some kind of free allowance to get started too.

Which APIs ground extractions back to the source page?
LandingAI ADE grounds every element to its page location, character range, and bounding box. Reducto grounds to a bounding box citation. LlamaParse and Unstructured both return layout coordinates you can map back to the page yourself.

Ready to see it on your own documents? Get started free.

Turning a multi page financial PDF into clean, traceable JSON with LandingAI ADE

sushrut mishra — Fri, 18 Sep 2026 11:48:49 +0000

The hard part of a financial PDF is rarely the text. It is a table that runs across pages, a total that carries to the last page, and footnotes that change what a number means. You want that as typed JSON your pipeline can use, and in anything regulated you also want to prove each value came from a specific spot on the page. This walks through the three call pipeline in LandingAI's Agentic Document Extraction, our ADE platform, that gets you both: Parse turns the document into grounded structure, Extract shapes it into your schema, and Ground ties every value back to its page.

The pipeline at a glance

Call	Input	What it returns
Parse	The PDF or image	Reading order Markdown with tables as HTML, plus a grounded tree of pages and blocks
Extract	The parsed Markdown and a schema	Your fields as typed JSON, with per field text ranges
Ground	The extract metadata and the parse structure	Every value mapped to a page and a bounding box

Setup

Install the library and set your key. The client reads VISION_AGENT_API_KEY from the environment, and you pass environment="eu" if your key is an EU key, since keys are region specific.

pip install landingai-ade

from pathlib import Path
from landingai_ade import LandingAIADE

client = LandingAIADE()  # reads VISION_AGENT_API_KEY

Step 1: Parse the PDF

client.v2.parse sends the document to the DPT-3 model and returns a single response with three parts: markdown, structure, and metadata. The Parse v2 API takes PDFs and images, so convert other formats first. Tables come back as HTML inside the Markdown, which keeps rows, columns, and spanning cells intact rather than flattening them into text.

parsed = client.v2.parse(
    document=Path("annual-report.pdf"),
    model="dpt-3-pro-latest",
    options={"pages": [2, 3, 4]},  # optional: limit the parse to specific pages
)

print(parsed.markdown)        # reading-order Markdown; tables render as HTML
structure = parsed.structure  # tree: document -> pages -> blocks, each grounded
print(parsed.metadata.page_count, parsed.metadata.billing.total_credits)

Two production details worth knowing up front. If some pages fail, the request still succeeds with HTTP 206 and lists the bad pages in metadata.failed_pages, so a single unreadable scan will not sink the whole job. And a synchronous parse is meant for documents you can wait on; for long filings you move to the jobs API, covered at the end, which is built to handle multi hundred page documents.

Walk the structure to find every table

The structure field is a tree. The root is the document, its children are pages, and a page's children are the blocks on it. Every node carries the same base shape: a type, a stable id, a span giving the start and end character offsets in the Markdown, and a grounding object holding the page, the range of characters, and a normalized bounding box. A table node also has children, which are its cells.

That regular shape means you can walk the tree once and pull out exactly what you need. Here is a short recursive walk that finds every table and reports the page it sits on.

def find_tables(node, found=None):
    found = [] if found is None else found
    if getattr(node, "type", None) == "table":
        found.append(node)
    for child in getattr(node, "children", []) or []:
        find_tables(child, found)
    return found

for table in find_tables(structure):
    page = table.grounding.page
    print(f"table {table.id} on page {page}, {len(table.children)} cells")

Because each table knows its own page, a statement that breaks across three pages comes back as three table blocks you can read in order rather than one flattened blob. That is the difference that lets carried totals and continued rows stay meaningful.

Step 2: Extract into a typed schema

client.v2.extract reads the Markdown and returns JSON in the shape of a schema you define, as a Pydantic model, a dict, or a JSON string. Because it works across the whole document at once, a grand total on the final page and its line items on earlier pages land in one object, and footnotes come through as their own field instead of being dropped.

from pydantic import BaseModel, Field

class LineItem(BaseModel):
    label: str = Field(description="Row label in the statement")
    amount: str = Field(description="Amount for the row")

class Financials(BaseModel):
    line_items: list[LineItem]
    grand_total: str = Field(description="Total that carries to the final page")
    footnotes: list[str] = Field(description="Footnote text tied to the table")

result = client.v2.extract(schema=Financials, markdown=parsed.markdown)
print(result.extraction)  # typed JSON in the shape of Financials

By default, fields your schema asks for that the model cannot support are skipped so extraction continues; pass strict=True to reject those with a 422 instead, which you want in a pipeline that should fail loudly. Alongside extraction, you get extraction_metadata, where every field carries the value and the character ranges it was quoted from. That metadata is what makes the next step possible, and it is the clean, structured JSON downstream systems and vector databases consume, the same output the best document parsing APIs are judged on.

Step 3: Ground each value to its page

Extract knows which characters each value came from; Ground turns those text positions into visual ones. You send it the extraction_metadata from Extract and the structure from Parse, and it returns every field mapped to the block it was quoted from, with a page number and a bounding box. It runs synchronously and consumes no credits.

grounded = client.v2.ground(
    extraction_metadata=result.extraction_metadata,
    structure=parsed.structure,
)
print(grounded.grounding)

Each field comes back tied to its exact place on the page:

"grand_total": [
  {
    "block_id": "table-cell-42",
    "type": "table_cell",
    "grounding": {
      "page": 4,
      "range": { "start": 8120, "end": 8131 },
      "box": { "xmin": 0.71, "ymin": 0.88, "xmax": 0.86, "ymax": 0.90 }
    }
  }
]

One rule keeps this honest: the extraction metadata must come from an Extract run on the Markdown of the same Parse response you pass as structure. Re parsing shifts the character ranges and invalidates an older extraction, so pair them by the doc_id the extract metadata carries. The box is normalized zero to one on the page, so you can highlight the value on a rendering, crop the region, or attach it as a citation in a review interface. If your organization runs Zero Data Retention, Ground is off by design, and you compute the same overlap client side by matching each field's ranges against each block's grounding.range. Either way, that grand total on page 4 now carries proof of where it came from, which is the audit trail a finance or compliance reviewer needs before trusting an automated number.

Scale it in production

A synchronous call is fine while you build, and it raises a timeout error on documents too large to finish inline. For those, the jobs API mirrors the same shape: client.v2.parse_jobs and client.v2.extract_jobs each expose create, get, list, and wait, and a single job handles up to 6,000 pages or one gigabyte per PDF.

job = client.v2.parse_jobs.create(
    document=Path("full-10k.pdf"),
    model="dpt-3-pro-latest",
)
parsed = client.v2.parse_jobs.wait(job.job_id)  # or poll with get() and list()

For high concurrency, AsyncLandingAIADE exposes the same calls with await. Wrap the work in the library's error types so a pipeline degrades cleanly rather than crashing: a partial parse returns 206 with failed_pages, a job that times out or fails raises JobWaitTimeoutError or JobFailedError, and any non success status raises an APIStatusError carrying the status code and response.

What you end up with

Three calls take a messy multi page filing to typed JSON where every value knows its page and its box. Parse preserves the structure and grounds each block, Extract shapes the content to your schema, and Ground makes each number verifiable against the source. Try the flow on your own document in the Playground at ade.landing.ai, then move the long files to the jobs API when you take it to production.

Where general multimodal LLMs break on document extraction, and when you need a dedicated platform

sushrut mishra — Fri, 18 Sep 2026 11:45:32 +0000

Every team building on documents eventually asks whether a general multimodal model like GPT-4o, Gemini, or Claude is enough, or whether the work needs a dedicated extraction platform. We build one of those, LandingAI's Agentic Document Extraction, our ADE platform, so here is the honest comparison, judged on the dimensions that decide whether extraction holds up in production.

The comparison at a glance

Dimension	General multimodal LLM	LandingAI ADE
Grounding	Returns the value as text, with no coordinate tying it to the page	Bounding box per line with DPT-3 Pro, per word with DPT-3 Verity; Extract cites the exact word
Consistency across runs	Probabilistic, so table shape and values can drift call to call	Standardized JSON every run; Verity transcribes deterministically
Confidence signal	None per value by default	A confidence score for every word with Verity
Cost at volume	Billed per token of the whole document, on every run	Billed per character returned; a basic page runs under a cent on Verity Standard

Can general multimodal LLMs handle production document extraction?

They are strong for exploration and reasoning, and they give way once you need the same structure from many documents with a record you can defend. The specific places they break:

No coordinate: you get the field value back as text, with no box tying it to the page, so nothing downstream can auto verify it against the source
Drift across runs: the same page can return a different table shape or a reworded value from one call to the next, because the output is probabilistic
Hallucination on hard tables: on merged cells, multi page tables, or totals that carry between pages, a general model can return a clean looking number that has no basis on the page
Token cost: you pay per token of the entire document on every run, which climbs fast at volume

For a concrete head to head, see ADE versus Gemini document processing and what each architecture tells you about grounding.

What you get from ADE instead: grounding you can read

Every element ADE returns carries its location. A value comes back with the page it sits on, its character range in the Markdown, and a bounding box on the image, inside a top level structure object. The shape looks like this:

"structure": {
  "page": 2,
  "range": { "start": 1180, "end": 1197 },
  "box": { "xmin": 412, "ymin": 604, "xmax": 588, "ymax": 631 }
}

Read that back to front: box is where the value physically sits on the page, range is where it sits in the returned Markdown, and page says which page. That trace is the thing a general model was never built to emit. On top of it:

DPT-3 Pro grounds to the line: every text line in a block carries its own bounding box, across all block types, and it detects tables, figures, signatures, and marginalia in reading order
DPT-3 Verity, in public preview, grounds to the word: every word carries a bounding box and a confidence score, and it transcribes digital text and tables deterministically
Extract turns that grounding into citations, so any field you pull traces back to a specific word on a specific page, which is what an audit or a human review needs

What makes a pipeline agentic, versus IDP and OCR?

An agentic pipeline reads a page's layout and structure first and adapts to a format it has never seen, rather than following a fixed template or a single OCR pass.

Template IDP: coordinates and rules tuned for one layout, so a shifted column or a new vendor format quietly breaks it, which is exactly where a document it was never trained on fails
Single pass OCR: characters with no blocks and no grounding, leaving every bit of meaning to you
Agentic, in ADE: reads layout down to words and table cells, adapts without templates, and grounds every value, which is why rule based and single pass approaches lose accuracy under load on the hard pages

How to choose

Reach for a general model when you are prototyping, when volume is low, or when the task is reasoning over a document rather than pulling the same fields from many. Reach for ADE when you need structured extraction at volume, a value you can trace back to the page, and a cost you can predict; most serious pipelines use both, a platform to produce grounded data and a model to reason over it once it is trustworthy. Run one of your own documents through ADE at ade.landing.ai and read the boxes and confidence scores it returns.

LandingAI's Agentic Document Extraction pricing explained: credits, service tiers, and characters

sushrut mishra — Wed, 16 Sep 2026 06:38:36 +0000

Flat per page pricing charges the same for a dense contract page and a near empty cover sheet, which quietly overcharges any real document mix. We took the opposite approach with LandingAI's Agentic Document Extraction, our ADE platform, and built the cost controls into the product so a mixed workload stays economical without you engineering around the bill.

This post walks through the pricing model we landed on and the three factors that decide what any job costs. The pricing core concepts guide holds the full formulas; what follows is the practical version for the developer staring at a billing object and working out how total_credits got there.

How ADE pricing works at a glance

Question	Answer
What is the billing unit	Credits, where one credit is one US cent, so one dollar buys 100 credits
What sets a job's cost	Three factors: the service tier, the Parse model, and the characters returned
What is the default tier	Standard, at about half the Priority rate
Where do I see the cost	A billing object with `total_credits` in every API response, mirrored in the Playground Usage table
Does the interface change the price	For the same tier the rate holds across the Playground, the REST API, and the Python and TypeScript SDKs; note the Playground always runs Priority

Everything runs on credits

ADE bills in a single unit, credits, and one credit equals one US cent, so a dollar buys 100 credits. That value holds on every plan and in every region, and every ADE service draws from one shared balance, so you track one number for the whole product. You buy credits two ways:

Self service, by card at ade.landing.ai, which suits developers and teams testing a workload or running in production without a contract
Enterprise, through an annual agreement and standard procurement, which suits volume terms and invoicing

Both paths spend the same credits at the same rate.

The three factors that set a job's cost

Once credits sit in your balance, three factors decide how many a job spends: the service tier you pick, the Parse model you run, and the number of characters processed.

Service tier, the speed you ask for

The service tier is the lever you control most directly, since it sets how fast the result returns, and the same work at a different speed costs a different amount. It maps onto what determines processing speed in production, so you trade turnaround for cost deliberately. Tier selection applies to both Parse and Extract, and there are two of them.

Tier	Latency	Mode	Reach for it when
Priority	Seconds to minutes	Sync or async	A person or agent is waiting on the result
Standard	Minutes to hours	Async only, and the default	Background pipelines and scheduled ingestion

Standard costs about half of Priority. Because there is no synchronous Standard path, a synchronous call always bills at Priority, so high volume production work belongs on the Standard async default where the same job costs roughly half.

Model, the Parse model you run

The DPT-3 family gives you two Parse models, and the one you pick moves the price directly. Both bill the same way, a per page rate plus a rate for every 1,000 output characters, so only the numbers differ.

DPT-3 Pro, the default and highest quality model, is the one to reach for on harder pages: handwriting, figures, charts, diagrams, or poor scans
DPT-3 Verity, the lower latency model built for clean, machine readable content like digital text and tables, currently in preview, is the cheaper path for simpler pages

Model and tier	Per page	Per 1,000 output characters
DPT-3 Pro, Priority	1.0 credit	0.50 credits
DPT-3 Pro, Standard	0.50 credits	0.25 credits
DPT-3 Verity, Priority	0.30 credits	0.20 credits
DPT-3 Verity, Standard	0.15 credits	0.10 credits

Two things stand out. Standard is half of Priority on every line, and Verity's page rate runs under a third of Pro's. Because the tier and the model both scale the same page, they compound, so the same page on Verity at Standard costs a fraction of what it costs on Pro at Priority. On a typical business document, DPT-3 Pro on Standard runs a median of about 1.5 credits.

Teams moving from ADE Gen1 typically see 25% to 80% lower per page cost on a mixed workload, and running Verity on Standard for the easy pages is what reaches the top of that range. You avoid building that cost optimization yourself, since the levers sit in the API call rather than in your pipeline.

Characters, the content you get back

You pay for the visible content ADE returns, meaning the Markdown text, tables, and fields on the page. Bounding box coordinates, confidence scores, and other structural metadata stay uncounted, so a sparse page returns few characters and costs little while a dense page returns more and costs more, which is what keeps a mixed workload fair. You also hold a direct control here: the pages parameter skips pages you do not need, and the options parameter toggles block types on or off, so trimming output you will not use trims the characters you pay for.

Keeping simple documents inexpensive

For simple documents that should not cost much, LandingAI's ADE gives you two levers that stack. Run them on DPT-3 Verity, the model built for clean digital text, and keep them on the Standard tier, which costs about half of Priority. Because the charge also tracks characters, a light page of clean text returns little content and lands at the bottom of the range.

Every charge is visible in the response

You never have to guess what a job cost, because every ADE API response carries a billing object reporting the credits consumed and the tier it was charged at, and the Playground mirrors the same figures in its downloadable Usage table. Here is the relevant metadata from a real Parse response, a one page invoice run synchronously on DPT-3 Pro:

"metadata": {
  "model_version": "dpt-3-pro-20260710",
  "page_count": 1,
  "output_markdown_chars": 1779,
  "billing": {
    "service_tier": "priority",
    "total_credits": 1.9
  }
}

The billing object is the headline: total_credits is what the job cost, and service_tier records the rate it paid. The two fields above it produced that number. A synchronous call bills at the Priority rate for DPT-3 Pro, which is 1 credit for the page plus 0.5 credits per 1,000 output characters. The page returned 1,779 characters, so the content charge is about 0.89 credits, and 1 plus 0.89 rounds to the 1.9 you see.

Now run the same invoice on the cheaper path, DPT-3 Verity on the Standard tier. Standard is async only, so this goes through Parse Jobs, and the billing comes back like this:

"billing": {
  "service_tier": "standard",
  "total_credits": 0.4
}

Same document, 0.4 credits against 1.9, a 79% drop. The tier alone roughly halves the bill and the model alone cuts it to about a third; together they compound to that 79%. That is the whole pricing model in one comparison: the document never changed, only the two choices you made in the call.

The levers you control

Default to Standard for background and production work, and pay about half of Priority
Send clean digital pages to DPT-3 Verity, and reserve DPT-3 Pro for the hard ones
Trim the response with the pages and options parameters so you pay for the characters you actually use
Remember the Playground always bills at Priority, so read a lower tier's real cost from an API run on Standard or from the per service formula

Where to check the real numbers

The honest way to know what ADE will cost you is to run a representative document through it at ade.landing.ai and read the total_credits the billing object hands back. Measured per thousand pages, we see ADE Gen2 land at or below common industry benchmarks, and the per service formulas live at docs.landing.ai as the reference to trust. If you are weighing ADE on price against the field, our guide to the best document parsing APIs sets out the comparison, and the full pricing core concepts guide covers the concepts end to end.

LandingAI's Agentic Document Extraction, 2nd Generation: new models, agent ready output, and atomic citations

sushrut mishra — Wed, 16 Sep 2026 06:33:57 +0000

LandingAI's Agentic Document Extraction, which we call ADE, now has a second generation, and this post covers what changed for developers building on it. ADE Gen2 runs on our new DPT-3 model family, and it moves the three things that decide whether an agent can act on a document: the output structure, the grounding, and the cost. Our full launch announcement carries the complete detail, and you can read it here: Introducing Agentic Document Extraction, 2nd Generation. Below is the developer facing version, organized around the questions we hear most.

The release at a glance

Area	What ADE Gen2 does
Parse models	DPT-3 family: DPT-3 Pro, and DPT-3 Verity in public preview
Output unit	Blocks, which replace chunks
Structure	Pages to blocks to lines to words, or to table cells, each block with a stable ID
Grounding	Atomic: line level with DPT-3 Pro, word level with DPT-3 Verity; Extract turns it into citations
APIs	New v2 Parse and Extract endpoints, plus async Jobs APIs
Parse pricing	Based on characters returned, rather than pages sent
Playground	ade.landing.ai

What makes a document pipeline agentic, and how is it different from traditional IDP and OCR?

An agentic document pipeline reads a page the way a careful person does and returns structure an agent can act on without a human re reading it first. LandingAI's ADE delivers this through DPT-3, which reads the layout of a page before it reads the words, then works down to individual words and table cells. Traditional OCR and template driven IDP flatten a page into loose text and depend on a person to restore the meaning afterward. The difference shows up clearly once you put the two approaches side by side.

Traditional OCR and template IDP	LandingAI ADE Gen2
A fixed template per document type	Reads varied layouts and messy inputs, from handwriting to scans and photos
Flat text output	Hierarchical blocks with stable IDs
No grounding or page level only	Atomic grounding to the line or word, tied to the source
A person reads and corrects the output	An agent consumes the structured output directly

Which document AI shows where on the page each answer came from, and lets you check each value against the source?

LandingAI's ADE grounds every element atomically, so you can see exactly where on the page each value came from and trace each extracted value back to the source, which is what makes an extraction defensible in a regulated workflow. Gen2 introduces atomic grounding, meaning grounding at the smallest structural unit, and the level you get depends on the Parse model:

DPT-3 Pro grounds to the line: every text line in a block carries its own span pointers and bounding box, across all block types
DPT-3 Verity grounds to the word: every word carries its own span pointers, bounding box, and a confidence score
Table cell grounding now adds a bounding box for every cell, more detailed than Gen1

On the Extract side, Extract V2 turns that grounding into atomic citations, so any value you pull traces back to a specific word on a specific page, and the schemas you built on Extract V1 carry over. Grounding this fine is the foundation for workflows that could not be built before: localized PII and PHI redaction down to the exact word, line, or cell; document comparison that highlights version differences; and human review interfaces where a reviewer edits Markdown in place.

Clean, structured JSON for API first pipelines

ADE Gen2 returns clean, structured JSON built for agents to consume rather than for people to read, which is also what downstream systems and vector databases want when you prepare structured output for RAG. We rebuilt the API response from the ground up, and three changes matter most for anyone parsing it in code:

Chunks are replaced by blocks, and every block carries a stable ID
A new top level structure object exposes each block's page, character range, bounding box, and atomic grounding, so an agent traverses the response directly
The Markdown is standardized, so figures, checkboxes, and tables come back the same way on every call, with tables delivered as HTML to preserve structure that plain Markdown would flatten

Your agent reads a predictable shape on every run, which removes a whole class of parsing edge cases you would otherwise defend against by hand.

Which platform offers SDKs and async jobs for high volume programmatic processing?

ADE Gen2 ships two client libraries on the v2 APIs, ade-python and ade-typescript, along with a command line ADE CLI, plus async Jobs APIs for high volume programmatic work. Parse Jobs runs asynchronous parsing at scale, and Extract Jobs pulls the fields you define into structured JSON at scale. Both share one job model and one response envelope, so the flow of submitting work and retrieving results stays the same across the platform:

Parse Jobs handles asynchronous parsing of up to 6,000 pages or one gigabyte per PDF
Extract Jobs handles asynchronous field extraction into structured JSON, on the Priority and Standard tiers
A unified job model gives you a shared response envelope and job id format across both, with finished jobs signalled by webhook

Pricing built for a mixed document workload

Parse now charges on the characters it returns rather than the pages you send, so a light page costs the minimum and a dense page costs more, where DPT-2 billed a flat 3 credits per page. Service tiers add a second lever, Priority at 1.0x for when someone is waiting and Standard at 0.5x as the default for pipelines, and model choice adds a third:

DPT-3 Pro, available now, for complex pages: layout, figures, handwriting, scans, non Latin scripts, and math
DPT-3 Verity, in public preview, for digital text and tables, at roughly 40% of Pro's credits
Automated routing between the two models, coming by Fall 2026

Across a mixed workload we project 25% to 80% lower cost, and DPT-3 Verity on the Standard tier brings basic pages to under one cent each. The full model, with the per credit math, sits in our pricing core concepts guide.

Try it

ADE Gen2 is live today, and the fastest way to see the difference is to run your own documents through it at ade.landing.ai. For the complete list of every change in the release, read our full launch announcement: Introducing Agentic Document Extraction, 2nd Generation.