Key Takeaways:
- A document extraction API gives you labeled fields, tables and line items from a PDF, scan or email. OCR gives you characters and leaves the meaning to you.
- Template-based and AI-driven extraction are different products. Templates break when a supplier moves the total, AI extraction reads layouts it has never seen.
- Judge vendors on field-level accuracy against your own documents. The number on the datasheet was measured on theirs.
- Parseur ships a developer API and a web app your operations team can run, so nobody has to build the review tool.
- Parseur is EU-hosted, with data processed and stored in the European Union and never used to train AI models.
A document extraction API is a service that takes a file such as a PDF, a scanned image or an email and returns structured data such as JSON or CSV. Unlike raw OCR, which returns plain text and leaves you to find the meaning in it, a document extraction API identifies and preserves structure: key-value pairs, tables, line items and labeled fields.
Three neighbours get mistaken for it. Public data APIs hand you a dataset somebody else already assembled. Web scraping APIs go and fetch what lives on a web page. OCR engines? Characters, no structure. A document extraction API works on your documents, the ones already sitting in an inbox, and turns them into data a system can act on. Some vendors sell the same thing under the name document understanding API, or ship it as a document extraction SDK. Different label, same job. Still working out which problem you have? We put document parsing and web scraping side by side.
According to Research and Markets, the intelligent document processing market, which includes document extraction APIs, is valued at about $3.01 billion and is projected to grow at a CAGR of 31.7%. That number is really a count of invoices, statements and forms, and every one of them has to be read by something. In a lot of companies that something is still a person with a second monitor and a numeric keypad.
Quick examples:
- PDF invoice → JSON with header fields and a line-item array
- Onboarding form → labeled key-value pairs (name, address, signature)
- Bank statement → transaction table exported to CSV
Five Kinds of Vendor Wearing the Same Label
Search "document extraction API" and you get a dozen vendors who share a category and almost nothing else. They are not really competing with each other, because they are built for five different jobs. Every one of them will win their own demo, so the row matters more than the pitch. Work out which row you are in before you book a single call.
| Kind of vendor | Examples | Built for | What you still build yourself |
|---|---|---|---|
| Cloud building blocks | Google Document AI, Azure Document Intelligence, AWS Textract | Teams already standardized on that cloud who want extraction as one service among many | Ingestion, review screens, exception handling, retries, ERP posting |
| AP automation platforms | Rossum, Nanonets | Finance teams who want the whole invoice workflow, not just the fields | Little to build, if their workflow is close enough to yours |
| Developer-first parsing APIs | Mindee, Veryfi, Parseur | Engineers who own the workflow and want clean JSON out of it | Varies by vendor. Parseur ships the review app |
| AI-native document parsers | LlamaParse, Reducto | RAG and agent pipelines that need faithful structure more than business fields | Field mapping, validation, anything workflow-shaped |
| Enterprise IDP suites | ABBYY, Hyperscience, UiPath | Regulated, high-volume operations with human review and legacy systems | Little to build. The work moves into configuration and rollout |
Two caveats on that table. First, the rows blur: several vendors sit in two. Second, Parseur is in row three because that is the job it is built for, emails and operational documents into structured JSON with an app your ops team can actually run. If your documents are engineering drawings, row four is a better fit than we are, and we would rather tell you now than during a trial.
Template-Based vs AI-Driven Extraction (Only One of Them Scales)
Template-based extraction finds a field by its position on the page. AI-driven extraction finds it by what it means. That is the whole difference, and it decides how much work you sign up for.
A template says: the invoice number lives 40mm from the top, 120mm from the left. Fast, deterministic, lovely. It holds right up to the morning a supplier redesigns their invoice, at which point it returns the wrong value, or nothing, and someone opens a ticket. Two hundred suppliers, two hundred templates, one engineer who understands them.
AI-driven extraction reads the document the way a person does. It finds the total because it sits under a line called "Amount due", bottom right, formatted as currency, and equal to the sum above it. Move it, restyle it, translate the whole invoice into German. Still findable.
Parseur runs two AI engines and no templates: the Text AI engine for emails and text documents, the Vision AI engine for PDFs, scans and images. You describe the fields you want and extraction adapts per document rather than per layout, so setup is minutes of field definition instead of weeks of template building.
The trade-off is real. AI extraction is probabilistic where a template is deterministic, which is why confidence scores exist, and why the evaluation section below spends more time on exception handling than on accuracy claims.
How a Document Extraction API Works, in Five Stages
Vendors differ in the details, but the document extraction pipeline has the same shape everywhere.
Why this stopped being optional: volume. Dream Factory cites the widely quoted projection that global data would reach 175 zettabytes by 2025, a date now behind us, and the share of it arriving as documents rather than database rows has not shrunk. Manual keying does not scale into that. Neither does a wall of templates.
Step 1: Ingestion
Whatever the vendor calls it, this is the document ingestion API: upload over HTTP, email forwarding, or a webhook from another system. Email matters more than it sounds. A large share of business documents never touch a file picker, they arrive as attachments from a supplier who has never heard of your portal.
Step 2: AI OCR and layout analysis
AI OCR converts image and scanned content into machine-readable text. Layout analysis then works out reading order, text blocks, lines, words and where each sits on the page. This is the step that separates a modern engine from a 2010 one: it produces a structural map, not just characters.
Step 3: Parsing
- Key-value pairs: labels matched to values, such as "Invoice Number: 12345".
- Tables and line items: rows and cells reconstructed, including merged cells, spans and tables that continue across a page break.
- Classification: working out what the document is before deciding which fields to look for.
Step 4: Post-processing
Dates, currencies and vendor names are normalized into consistent formats. The result is validated against a JSON Schema or Pydantic model so a malformed payload never reaches your ERP.
Step 5: Delivery
The API returns the result synchronously for small files, or asynchronously with a webhook callback for anything larger. Retries and idempotency are what keep that reliable at volume. Ask about both before you sign, not after the first silent Friday night.
Show Me the JSON
Vendor pages talk about "structured output" without ever showing one. Here is the shape a supplier invoice should come back in, and the shape worth making every vendor match:
{
"document_type": "invoice",
"supplier": { "name": "", "tax_id": "", "supplier_id": "" },
"invoice": {
"invoice_number": "",
"invoice_date": "",
"due_date": "",
"currency": "",
"po_number": ""
},
"amounts": { "subtotal": 0, "tax": 0, "freight": 0, "total": 0 },
"line_items": [
{
"description": "",
"sku": "",
"quantity": 0,
"unit_price": 0,
"line_total": 0
}
],
"confidence": { "invoice_number": 0.98, "total": 0.99, "line_items": 0.91 }
}
Two things in there do most of the work. line_items is an array, not a blob of text, which is what makes two-way and three-way matching possible. confidence is per field, which is what lets you decide automatically whether a human needs to look.
How to Choose a Document Extraction API Without Trusting the Demo

Every vendor wins their own demo, because every vendor picked the documents in it. The only evaluation that predicts production is the one you run on yours.
1. Build the test set before you talk to anyone
Pull 200 to 500 real documents out of your last three months, weighted the way your inbox actually is:
- ~70% your common supplier formats
- ~20% long-tail suppliers you see once a quarter
- ~10% the ones that break things: bad scans, handwritten notes, multi-page tables, credits, foreign currency, two POs on one invoice
Run the identical set through every candidate. Never let a vendor choose the sample.
2. Score fields, not documents
Document-level accuracy hides the failures that cost you money. Score each field separately and weight it by how much a mistake hurts:
| Field | Why it matters |
|---|---|
| Invoice number, supplier ID | Duplicate detection and matching break without them |
| Total, tax, currency | Wrong here means wrong payments |
| PO number | The hook for two-way and three-way matching |
| Line-item quantity and unit price | Where most engines actually fail |
| Dates | Cheap to fix, expensive to miss |
3. The number to track is straight-through processing
Count the documents that go from arrival to posted with nobody touching them. At 5,000 documents a month, the gap between 90% and 96% straight-through is 300 documents someone opens by hand. That is not a metric, it is a job description.
4. Line items are where it breaks
Header fields are easy. Every engine on the shortlist will find the invoice number. Throw multi-page tables, repeated headers, wrapped descriptions, freight and discount rows, per-line tax, negative credits and mixed units at it before you believe a single number.
5. Ask who cleans up the exceptions
File size limits, async processing, webhook retries, idempotency, rate limits, SDK coverage, and what happens to a low-confidence field. Then ask who reviews the exceptions. If the answer is "your engineers, in a tool you build", the price on the datasheet is not the price. Parseur's own numbers for that list live in the API documentation, and the answer to the last question is the web app, not your sprint.
What a Document Extraction API Really Costs
Pricing shapes differ more than the marketing suggests, and the shape matters more than the rate.
- Per page: cheapest on short documents, punishing on long ones. A 40-page contract costs 40 times a one-page receipt for the same single set of fields.
- Per document: predictable per file, but premium features like custom models, handwriting or query-based extraction are often billed on top.
- Subscription by volume: a flat monthly rate for a document allowance, page count irrelevant.
Parseur uses the third. A long PDF and a short email cost the same, which keeps the bill predictable when your document mix is not. Current tiers are on the pricing page.
The cost nobody quotes is the engineering around the API: post-processing logic, a review interface, retry handling, monitoring for extraction drift. That bill is usually bigger than the API bill, and it is the part Parseur's web app exists to delete.
Parsing a PDF Into JSON With the Parseur API

The whole PDF extraction API path, upload to webhook, in five steps.
Base URL: https://api.parseur.com/
1. Authenticate
Find your API key in the API section of your Parseur account and send it in the Authorization header on every request:
Authorization: <YOUR_API_KEY>
Full details are in the Authentication Guide.
2. Find or create a mailbox
A mailbox is the container that holds your documents and the fields you want extracted. Create one in the app, then list your mailboxes to get the ID:
curl -X GET "https://api.parseur.com/parser" \
-H "Authorization: <YOUR_API_KEY>" \
--compressed
The mailbox ID also appears in the mailbox URL in the app, and in the id field of the create-mailbox response.
3. Upload a document
cURL:
curl -X POST "https://api.parseur.com/parser/<MAILBOX_ID>/upload" \
-H "Authorization: <YOUR_API_KEY>" \
-F "file=@./invoice.pdf" \
--compressed
Python:
import requests
url = "https://api.parseur.com/parser/<MAILBOX_ID>/upload"
headers = {"Authorization": "<YOUR_API_KEY>"}
files = {"file": open("invoice.pdf", "rb")}
response = requests.post(url, headers=headers, files=files)
print(response.json())
Node.js:
import fetch from "node-fetch"
import fs from "fs"
const url = "https://api.parseur.com/parser/<MAILBOX_ID>/upload"
const headers = { Authorization: "<YOUR_API_KEY>" }
const formData = new FormData()
formData.append("file", fs.createReadStream("./invoice.pdf"))
const response = await fetch(url, { method: "POST", headers, body: formData })
console.log(await response.json())
Documents can also arrive by email forwarding instead of upload. See Upload Emails and Documents for both routes.
4. Get your data back
Configure a webhook on the mailbox and the parsed JSON lands on your endpoint the moment processing finishes. In production this is the right default: no polling, no cron, no documents lost between checks.
Alternatives when a webhook is not an option:
- Automation platforms: Zapier, Make, n8n or Power Automate.
- Polling:
GET /document/{id}for the parsed JSON. - Exports: CSV, JSON or Excel downloads from the mailbox.
5. Validate and tune
The Parseur dashboard shows document and webhook logs, so you can see exactly what was extracted and what was delivered. When a field comes back wrong, fix it there instead of patching around it in your codebase.
What Parseur Extracts, and What It Still Cannot
Parseur is a document extraction API built around one idea: the document should not need preparing before the software can read it. It has processed more than 100 million documents since 2016.
- Key-value pairs and forms: names, addresses, totals, invoice numbers and reference IDs into labeled fields.
- Tables and line items: invoice lines, bank statement transactions, shipping manifests, including tables that run across several pages. AI table extraction covers how that works.
- Scans and photographs: the Vision AI engine reads scanned and photographed documents directly, not just digital PDFs.
- Emails and attachments: a Parseur specialty. The email itself is a document, and so is everything attached to it.
- Layout elements: headings, paragraphs and selection marks where you need them.
Where it is still hard: dense handwriting and signatures. Those are unsolved across the whole category, and any vendor claiming otherwise should be asked for the benchmark.
Most document extraction software stops at the API and leaves the rest to you. Parseur ships both halves: the API for your side, and a web app where the operations team defines fields, reviews documents and corrects results without filing a ticket or waiting on a sprint.
Where teams use it
- Accounts Payable - invoices, receipts and purchase orders into structured JSON, then straight into the ERP.
- Financial Operations - bank statements and transaction reports into CSV or JSON for reconciliation.
- Operations and Logistics - packing slips, bills of lading and delivery notes.
- Email automation - ingest the message and its attachments, extract, deliver by webhook.
Security, GDPR and EU Data Residency
Parseur is EU-hosted: customer data is processed and stored in the European Union, and the hosting data center is ISO 27001 certified. That is a data residency commitment, which is a different and stronger thing than a GDPR compliance badge.
Parseur is aligned with EU GDPR, UK GDPR, California CCPA/CPRA and Singapore PDPA. Customer documents are never reused to train Parseur's AI models and are never sold. Retention is configurable, so documents can be deleted automatically on a window you set. SOC 2 Type II and HIPAA compliance programs are in progress, which means neither is certified today.
If residency is a hard requirement, never accept "EU hosted" without asking where four specific things happen: inference, temporary cache, backups, and logs containing document content. An EU database sitting in front of a US inference endpoint is not EU residency, and it is a common shape. Our 12 questions that test a no-training claim runs the same exercise for model training.
Document Extraction APIs and LLMs: Never Hand Over the Raw PDF
Language models are extraordinary at reasoning and unreliable at reading a PDF. Point one at a scanned invoice and it will return a total that is not on the page, with perfect composure. A document extraction API produces the ground truth. The model works on top of it.
The division of labor that works: the API pulls invoice number, dates, totals and line items with confidence scores, then the model does the things models are good at, turning "01/03/25" into 2025-03-01, tagging the document type, mapping fields into your internal taxonomy. Schema validation sits under both and catches what neither notices alone.
An AI agent needs the same discipline. It is only as good as the data handed to it, and a hallucinated line item becomes a real purchase order with a real payment behind it. For the wider picture, the complete guide to data extraction APIs is the pillar this page sits under.
Now Go Break Some Vendors
The best document extraction API is not the one with the longest feature list, it is the one that survives your ugliest 10% of documents without a person in the loop. Build the test set, score the fields that cost money when they are wrong, and count how many documents come out the other end untouched. Run it against us too, in whatever order you like.
Everything else is a datasheet.
Last updated on




