You Probably Don’t Need What You Think You Need
Someone on your team says “we need to extract data from PDFs.” That sentence means two completely different things depending on what happens next.
If the next step is “feed it into a chatbot” or “build a knowledge base,” you need document parsing. Take a PDF, convert it into clean text or markdown, chunk it, embed it, stuff it into a vector database. The document’s structure matters only insofar as it produces better chunks.
If the next step is “get the invoice number, line items, and total into our database,” you need structured extraction. The document’s content matters. Specific fields matter. Types matter. Getting back a blob of markdown and then prompting an LLM to find the invoice number is a Rube Goldberg machine.
LlamaParse does the first thing well. Iteration Layer Document Extraction does the second. This post is about understanding the difference — not about which product is “better.” They solve different problems.
What LlamaParse Actually Does
LlamaParse is a document parsing service by LlamaIndex. It takes PDFs, Word documents, slides, spreadsheets, and other file types, then converts them into clean markdown, plain text, or structured JSON chunks. The output is optimized for feeding into LLMs — specifically for retrieval-augmented generation (RAG) pipelines.
It offers four processing tiers:
- Fast — basic text extraction, lowest cost, good for simple documents
- Cost Effective — better layout handling with moderate cost
- Agentic — uses an LLM to interpret complex layouts, tables, and figures
- Agentic Plus — highest quality, best at handling charts, diagrams, and multi-column layouts
Each tier trades cost for quality. The Agentic tiers use vision models to understand what they’re looking at — a chart isn’t just pixels, it’s data the model can describe in text. For RAG pipelines, this matters. Better parsing means better chunks, which means better retrieval, which means better answers from your chatbot.
LlamaParse is good at this. It handles tables, multi-column layouts, headers, footers, and embedded images better than most PDF-to-text tools. If you’ve ever tried to parse a financial report with pdftotext and gotten a garbled mess of columns, you understand why something like LlamaParse exists.
But here’s the thing: the output is always document content in a consumable format. Markdown. Text. JSON representations of the document structure. It’s never “the tenant name is John Smith, the monthly rent is $2,400, the lease ends on 2027-03-31.”
The Gap Between Parsing and Extraction
Say you have a lease agreement and you need the tenant name, property address, monthly rent, and lease dates in your database. Here’s what the LlamaParse workflow looks like:
- Send the PDF to LlamaParse. Get back markdown.
- Take that markdown and prompt an LLM: “Extract the tenant name, property address, monthly rent, lease start date, and lease end date from this text.”
- Parse the LLM’s response — which is unstructured text or maybe JSON if you asked nicely and the model cooperated.
- Validate the types. Is the rent actually a number? Is the date in a format your database accepts? Is the address complete?
- Handle failures. The LLM hallucinated a field. The markdown lost a table. The date format is ambiguous.
Steps 2 through 5 are your code. Your prompts. Your validation logic. Your error handling. LlamaParse did its job in step 1 — it gave you clean text. Everything after that is on you.
This is fine if you’re building a RAG pipeline anyway. The markdown goes into your vector store, and when a user asks “what’s the monthly rent in the lease agreement?” the retrieval system finds the relevant chunk and the LLM answers. No structured extraction needed.
But if you’re building an automated workflow — lease data into a property management system, invoice data into an ERP, contract terms into a compliance database — that intermediate LLM step is unnecessary complexity. You’re paying for two LLM calls (LlamaParse’s Agentic parsing plus your extraction prompt), handling two failure modes, and writing glue code that shouldn’t need to exist.
Schema In, Structured Data Out
The Iteration Layer Document Extraction API skips the intermediate step. You define a schema describing the fields you want, send the document, and get typed JSON back.
import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });
const result = await client.extract({
files: [{ url: "https://example.com/lease-agreement.pdf" }],
schema: {
fields: [
{ name: "tenant", type: "text" },
{ name: "landlord", type: "text" },
{ name: "property_address", type: "address" },
{ name: "monthly_rent", type: "currency_amount" },
{ name: "lease_start", type: "date" },
{ name: "lease_end", type: "date" },
{ name: "security_deposit", type: "currency_amount" },
],
},
});That’s it. No markdown intermediate. No extraction prompt. No type validation on your side.
The address field comes back decomposed — street, city, region, postal code, country — not as a raw string you have to parse. The currency_amount fields come back as numbers with proper decimal handling, not as “$2,400.00” strings. The date fields come back in ISO format, not as “March 31st, 2027” that you have to wrangle into a Date object.
Every extracted field includes a confidence score — a 0-to-1 value indicating how certain the model is about the extraction. Low confidence on a field? Route it to human review. High confidence across the board? Process it automatically. That threshold is yours to set, but the signal is there without you building your own confidence estimation.
Every field also includes source citations — the verbatim text from the document that the value was extracted from. An auditor can check the citation against the original without re-reading the entire document.
None of this exists in the LlamaParse workflow. There’s no schema definition. No typed fields. No confidence scores per field. No source citations. Because LlamaParse isn’t trying to solve this problem — it’s solving the “turn this document into text an LLM can read” problem.
Where LlamaParse Fits
LlamaParse is the right tool when:
- You’re building a RAG pipeline. Documents go into a vector store, users query them conversationally. LlamaParse’s markdown output is exactly what you need for chunking and embedding.
- You need document content, not specific fields. You want to read a research paper, summarize a report, or let users search across a corpus. The entire content matters, not individual data points.
- You’re already in the LlamaIndex ecosystem. LlamaParse integrates tightly with LlamaIndex’s ingestion pipeline, node parsers, and index types. If you’re using LlamaIndex for your RAG stack, LlamaParse is the natural parsing layer.
- You process documents with complex visual elements. Charts, diagrams, multi-column academic papers — LlamaParse’s Agentic tiers handle these well, converting visual information into text descriptions that enhance retrieval quality.
For these use cases, LlamaParse is a solid choice. Trying to use a structured extraction API for RAG preprocessing would be like using a scalpel to cut firewood. Wrong tool.
Where Iteration Layer Fits
The Document Extraction API is the right tool when:
- You need specific fields in your database. Invoice number, line items, total, due date. Tenant name, rent amount, lease term. Patient name, diagnosis code, medication list. Defined fields, typed values, structured output.
- You process multiple file formats beyond PDFs. DOCX, XLSX, CSV, JSON, HTML, Markdown, and plain text are parsed natively — not OCR’d. A spreadsheet is read as structured data, not photographed and interpreted.
- Confidence scores drive your automation. High-confidence extractions go straight through. Low-confidence extractions get routed to a human. The API gives you the signal; you set the threshold.
- You need multi-file extraction. Up to 20 files per request, treated as a single document. A loan application that spans a bank statement, pay stub, and tax return — one request, one schema, one response. No client-side merging.
- You’re building agent-powered workflows. Every Iteration Layer API ships as an MCP server. Claude, Cursor, and other MCP-compatible clients can call the extraction API as a tool — no integration code needed.
The “Why Not Both” Scenario
Some pipelines genuinely need both. You might use LlamaParse to ingest a corpus of contracts into a knowledge base for conversational search, and use Iteration Layer to extract specific terms from individual contracts when a user triggers a review workflow.
That’s not a failure of either tool. That’s two tools doing what they’re each good at. The knowledge base needs clean text. The review workflow needs structured fields. Different outputs for different consumers.
The mistake is using one where you need the other. Feeding LlamaParse output into an LLM to extract fields is a workaround, not a solution. It works, but it’s slower, less reliable, harder to debug, and more expensive than purpose-built structured extraction. Similarly, using a structured extraction API to populate a vector store would be absurd — you’d get precise fields when you need full document content.
Pick the Right Tool
If your documents feed a chatbot, a search index, or an LLM-powered Q&A system — look at LlamaParse. It does RAG preprocessing well.
If your documents feed a database, an ERP, a CRM, or any system that needs specific typed fields — check the Document Extraction docs. Define a schema, get structured JSON back, and skip the intermediate parsing-then-prompting dance.
The TypeScript and Python SDKs handle authentication and request construction. Iteration Layer runs on EU infrastructure (Frankfurt), which matters if your data residency requirements rule out US-hosted services.
Sign up for a free account — no credit card required — and try your actual documents against a schema. The confidence scores and source citations alone might change how you think about document processing pipelines.