IronStratum Get an API key

Document parsing API: text out, structured parse, or archival fidelity

A document parsing API turns documents a program cannot read, page images, scans, and PDF pages, into text it can. Buyers searching this product type meet a wall of vendor lists that sort providers by name. The decision that actually matters sorts by document: plain text out at volume, a structured Markdown parse for pipelines, or verbatim fidelity for old print. This platform's parsing catalog is built around those three routes, and this page states where each one stands. The honest answer comes first: none of the three serves traffic yet. Two are staged for the platform's specialty fleet wave, and one is a written evaluation with no catalog row. What follows is the framework for choosing a route, what the independent benchmarks say about the models behind them, and what the open-weights road looks like for each.

Last verified: 2026-09-11

What a document parsing API does

Start with the smaller product inside the name. OCR, optical character recognition, reads the marks on a page and returns text. It answers one question: what characters are printed here. For decades that was the whole industry, and engines like Tesseract still do useful work at that job.

Parsing answers a bigger question: what is this document. A parser reads the characters and the layout together, then writes a file that reflects the page's structure: paragraphs in reading order, tables rebuilt cell by cell, formulas as LaTeX-style text, headings as headings. The market folded the two jobs together because a new model class, vision-language models that read layout and text in a single pass, made the combined job cheaper than stitching two engines together. The OmniDocBench benchmark from opendatalab exists to score exactly this combined task, and its leaderboard is where the open parser families now compete.

The output ladder is the useful way to hold the distinction. Raw text feeds a search index or a word count. Structured Markdown or JSON that rebuilds tables, formulas, and reading order feeds a retrieval pipeline, a database, or an agent that needs to know what is a table cell and what is a caption. A verbatim transcript, text as printed, spelling and typography quirks included, feeds citation-grade scholarly and archival work. Three rungs, three different buyers, and one search results page that rarely separates them.

Three routes for three document jobs

This platform's parsing category is three routes over that ladder. Each has a model family behind it, each family ships open weights, and each model page carries its complete working contract.

Text out at volume

The print route is plain OCR done at scale: clean machine-printed pages in, recognized text out. Its engine class is the two-stage detector-plus-recognizer, and the current generation of that class is PP-OCRv6 from Baidu's PaddlePaddle team: a family in three sizes, 1.5M, 7.7M, and 34.5M parameters, a single model covering 50 languages, Apache 2.0 weights. The publisher's own benchmark puts its medium tier at 86.2 detection Hmean and 83.2 recognition accuracy, strongest on printed text, which is precisely what a print lane exists for. Invoices, receipts, order forms, and born-digital backfiles are this route's profile; the print lane page carries the platform's own measured tier verdict and the exact request.

Structured parse to Markdown

The parse route is the document-parsing job proper: PDFs and page images go in, and what comes back is Markdown with its tables, formulas, and reading order rebuilt. The capability this platform evaluated is GLM-OCR from Z.ai, a 0.9-billion-parameter parser that tops its publisher's benchmark table and serves from vLLM and SGLang when self-hosted. Its model card defines the task exactly: fixed parsing prompts for text, formulas, and tables, plus a schema-driven extraction mode for named fields. Tables are the make-or-break output here, and merged cells are the loudest pain in community threads, which is why a full guide in the block below works that single problem. The evaluation, the benchmark record with its versions, and the exact request a hosted lane would take are all on the parse-mode page.

Archival fidelity

The archival route is for the documents every other route quietly gives up on: scanned books, historical print, anything with aged type. Old print is a distinct problem class. The long s looks like an f to a modern normalizer, ligatures merge letters, and multi-column pages break reading order. The open marker project publishes its own category scores, and its old-scans row reads 43.2 against 99.7 for clean pages: more than half the accuracy gone on the hard class. This route runs the dots.ocr family from the rednote lab, MIT-licensed, with a verbatim-fidelity flag that preserves what is printed rather than modernizing it, and the lane's default model was chosen through the platform's own paired bake-off over historical book pages instead of a spec-sheet read. The archival lane page carries that bake-off, the diplomatic mode, and the job route that full-resolution pages need.

Choosing by document class

The fastest route to a decision is to name the dominant document, not the vendor.

Your documentsThe routeWhy
Machine-printed pages at volume: invoices, forms, backfilesText outDetection-recognition engines are fast, cheap per page, and strongest on clean print
Reports, papers, manuals going into RAG or an agentStructured parseThe pipeline needs structure: tables, headings, reading order, not raw text
Scanned books, historical print, citation-grade transcriptsArchival fidelityOld type breaks normalizers; the job is verbatim accuracy, not speed
A mix of all threeSplit the streamRoute by page class; one lane can hand another the pages it fails

Two honesty notes belong next to that table. First, quality claims in this market need their benchmark version attached: the same parser scores differently across OmniDocBench releases, and an unversioned number cannot be trusted on its face. On the benchmark's own v1.6 board, the open families sit in a tight band at the top, PaddleOCR-VL-1.6 at 96.34, MinerU2.5-Pro at 95.75, GLM-OCR at 95.22, with the dots family at 90.77, and every one of those numbers moves with the next release. Second, no open model wins everything: chart understanding and semantic formatting remain weak spots across the open field, and the olmOCR-bench old-scans scores, 48.2 for the current dots model against 40.9 for its predecessor, show both that the class is hard and that it is improving. The acceptance test that matters is your own pages against a candidate, not a leaderboard row.

The parsing catalog on this platform

This section states the offering at offering level, because the SKU table on this page is machine-generated from the model registry, and the registry decides what serves.

Two routes have registry rows and sit staged. Staged means the lane is built, wired through the gateway, and measured there; its row and its rate are visible in the catalog, and serving begins when the card-2 wiring wave, the specialty fleet's own flip for these rows, turns them on. The models index shows every row's current state at any moment. Nothing here adds up to a launch-date promise.

The third route, structured parse, has no registry row. It exists as the written GLM-OCR evaluation this platform carries, including the exact request a hosted lane would take, and a row would travel over the chat route family if the capability lands. No rate exists for it, and none is promised here.

Billing is uniform across the category. Parsing meters by the page, the unit this category brings to the platform, paid from the prepaid wallet; a call that arrives after the balance is gone is refused with a named error.

Any single key is revocable the moment it leaks, and a revoked key stops spending at once. Spending caps per key sit on the roadmap, not in the product; the wallet is the only bound that ships today. A request the gateway turns away before it is relayed is never metered, so refusals cost nothing. The pricing page is where each rate from the registry renders; a rate lives there, and a change shows there first, which is why no number is typed here. The bill-shock guide, listed in the block below, works through the routines that stop a metered account from surprising you.

Running the models yourself

Every family behind these routes ships open weights, so the weights are not what a hosted lane sells. What it sells is the serving around them: an endpoint that stays up through a page-batch spike, meters every request by the page, and leaves the model-ops work on someone else's desk. PP-OCRv6 is Apache 2.0 with a plain pip install. GLM-OCR is MIT with official Ollama and vLLM paths. The dots family is MIT with vLLM support. The local road is real for all three, and for a parser that tops benchmark tables at under a billion parameters, it is often a laptop-scale road.

Running it yourself wins when the documents must not leave your boundary, when volume is high and steady enough to justify a machine, or when fine-tuning matters. The hosted lane earns its keep when you would rather not staff for the rest of the job: keeping GPU serving alive at month end, upgrading the inference stack each time a new release moves the benchmark numbers, and watching for silent accuracy drift on your own document classes. The break-even arithmetic for that trade belongs in a spreadsheet, not a hunch, and the bill-shock guide below walks it.

Getting started

  1. Request an invitation through the console. The beta is invite-only for now; the wallet, API keys, and full spend history live there, and an account opened today is ready the moment a parsing row switches on.
  2. Watch the pricing page. When the staged rows begin serving, their rates are already rendering there from the registry, and the evaluated parse route would publish its rate the day a row lands.
  3. Read the lane that matches your documents. Every model page carries its route's measured results plus the exact request to copy: print, parse, or archival.
  4. Run your own acceptance test. The benchmark that decides anything is your document pile against a candidate lane; the tables above tell you which lane to point at which pile.

Everything else the platform serves, chat, speech, transcription, embeddings, and rerank, is mapped on the models index, all drawing from one wallet.

Guides

Questions

What is a document parsing API?
It is an HTTP service that takes documents in, page images, scans, and PDFs, and returns text in a shape a program can use. The term covers a ladder of outputs. At the bottom sits plain OCR: the service reads the characters on the page and hands back raw text. Above that sits structured parsing: the service also reads the layout and returns Markdown or JSON whose tables, formulas, and reading order are rebuilt. A document parsing API is the general name for both, and the practical question for a buyer is which of those outputs the job actually needs.
Is document parsing the same thing as OCR?
OCR is one part of parsing. Optical character recognition reads the marks on a page and outputs text, nothing more. Parsing takes that further: it finds the paragraphs, tables, and headings, puts them in order, and writes a structured file. The two terms get used loosely in the same search results because modern models do both in one pass, but the outputs differ in what downstream code can do with them. Raw text feeds a search index. A structured parse feeds a RAG pipeline, a database, or an agent that needs to know what is a table cell and what is a paragraph.
Which parsing route handles old scanned books?
The archival route. Old print is its own problem class: aged paper, uneven ink, a long s that reads as an f to modern eyes, ligatures, and multi-column layouts whose reading order breaks naive extraction. On the open marker project's own category benchmark, old scans score 43.2 against 99.7 for clean pages, which is the size of the gap in plain numbers. This platform's archival lane runs the dots.ocr model family for exactly this class, with a verbatim-fidelity flag that leaves original spelling and typography as printed instead of modernizing them. The lane is built and staged; it begins serving with the platform's specialty fleet rollout.
Which route converts PDFs to Markdown for RAG?
The structured parse route: PDFs and page images go in, and Markdown with tables and reading order comes back out. This platform has evaluated GLM-OCR, the 0.9-billion-parameter open-weights parser from Z.ai, for that job and written the evaluation up as a model page. There is no registry row for it yet, so nothing answers calls under that alias and no rate exists. The guides listed with this page include two deeper treatments: one on converting PDFs to Markdown for retrieval pipelines, and one on extracting tables with merged cells, the single loudest table pain in community threads.
What does a document parsing API cost on this platform?
Parsing routes bill by the page. The spend comes off a prepaid wallet, and the balance caps what can be spent: once it empties, an arriving call is refused with a named error instead of overrunning the deposit. This page and the rest of the content layer carry no rates at all. The machine layer generates each rate out of the model registry and displays it on the pricing page, so that page is where a rate lives and where a change lands first. For the evaluated parse route there is no rate at all yet, because there is no registry row; a row would publish its rate the day it lands.
Can I call these parsing routes today?
Not yet, and this page does not pretend otherwise. Two of the three routes, print and archival, are built, wired through the platform gateway, and measured there; they sit staged in the catalog with their rows present, and the specialty fleet wave is what switches them on. The third, the structured parse route, is an evaluation with no registry row and no promised date. Anyone who wants an account in place for that day can request an invitation through the console now, and all three families ship open weights, so nothing stops a local setup meanwhile.