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

A document parsing API turns documents a program cannot read into text it can. Page images, scans, and PDF pages are the inputs. 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 family is built around those three routes. This page states where each one stands. The honest answer comes first: two of the three serve traffic today. Print and archival went live on October 26, 2026, confirmed by that day's requests, and both rows are on the public list. The third is a written evaluation with no catalog row. What follows is the framework for choosing a route. It covers what the independent benchmarks say about the models behind them, and what the open-weights road looks like for each.

Last verified: 2026-09-25

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 it writes a file that reflects the page's structure. Paragraphs come in reading order, tables are rebuilt cell by cell, formulas appear as LaTeX-style text, and headings stay headings. The market folded the two jobs together because of a new model class. Vision-language models read layout and text in a single pass, which made the combined job cheaper than stitching two engines together. The OmniDocBench benchmark from opendatalab exists to score exactly this combined task. 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 agent needs to know what is a table cell and what is a caption. A verbatim transcript is text as printed, spelling and typography quirks included. It 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. The family comes in three sizes, 1.5M, 7.7M, and 34.5M parameters. A single model covers 50 languages, and the weights are Apache 2.0. The publisher's own benchmark puts its medium tier at 86.2 detection Hmean and 83.2 recognition accuracy. That is 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. It 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. That is why a full guide in the block below works that single problem. The evaluation and the benchmark record with its versions sit on the parse-mode page. The exact request a hosted lane would take is there too.

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. Its old-scans row reads 43.2 against 99.7 for clean pages. More than half the accuracy is gone on the hard class. This route runs the dots.ocr family from the rednote lab, MIT-licensed. A verbatim-fidelity flag preserves what is printed rather than modernizing it. The lane's default model was chosen through the platform's own paired bake-off over historical book pages. That bake-off, not a spec-sheet read, is the basis. 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.

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 scores 96.34, MinerU2.5-Pro 95.75, GLM-OCR 95.22, and the dots family 90.77. 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. The olmOCR-bench old-scans scores, 48.2 for the current dots model against 40.9 for its predecessor, show two things. The class is hard, and 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. The model table on this page is machine-generated from the platform's own model data, and that data decides what serves.

Two of the three routes, print and archival, are built and measured, and their rates are set. Both appear in the public models index and on the pricing page, live since 26 October 2026. The models index is the live catalog. Nothing here adds up to a launch-date promise.

The third route, structured parse, is not currently offered. It exists as the written GLM-OCR evaluation this platform carries, including the exact request a hosted lane would take, and a lane 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 listed rate renders. A rate lives there, and a change shows there first. That is why no number is typed here. The bill-shock guide, listed in the block below, works through those routines. They 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 stays up through a page-batch spike. It meters every request by the page, and it 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. 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. It also wins 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. That job means keeping GPU serving alive at month end. It means upgrading the inference stack each time a new release moves the benchmark numbers. And it means watching for silent accuracy drift on your own document classes. The break-even arithmetic for that trade belongs in a spreadsheet, not a hunch. 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 works across every lane on the list.
2. Read rates on the pricing page. The print and archival routes serve, on the public list since October 26, 2026; their rates render there. The evaluated parse route has no rate, because no hosted lane exists.
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 is mapped on the models index. Chat, speech, transcription, embeddings, and rerank, all drawing from one wallet.