Data Extraction APIs: How They Work + Top Options

Search for a data extraction API and Google puts two different industries on one results page. Half the links parse PDFs, invoices, and contracts; the other half turn live web pages into JSON. Both sell the same promise, one request in and structured data out, and both call themselves what you searched for.

The differences that matter are quieter: how you steer the extraction, what a page really costs once you read the pricing page properly, and where your data travels. Those three questions sort the field below into six options worth shortlisting.

The short list

Tool	Reads	You steer with	Pricing model	Runs on
Diffbot	Live web pages	Its fixed ontology (automatic)	Monthly credit pool; 1 credit per page extract, 2 via proxy	Their cloud
Firecrawl	Live web pages	Your prompt or JSON schema (/extract)	Credits; free tier, Hobby $16–19/mo for 5,000 credits	Their cloud
Octoparse Open API	Output of scrapers configured in Octoparse	No-code scraper config + 23 REST endpoints	Free trial, then paid plans	Their cloud
Reducto	PDFs and images	Your JSON schema + parsing options	Usage-based	Their cloud
Sapling	Raw text (emails, invoices, resumes)	Field names in the request	Usage-based	Their cloud
Magpie	Live web pages, fetched locally	JSON Schema through your own LLM key, or 27 zero-LLM verticals	Free CLI (AGPL-3.0-or-later or commercial); Desktop $49/mo after 5 free runs	Your machine

Ranking is by what each option is best at, not an overall winner. The buying decision starts with your input type, so the mechanics come first.

How a data extraction API works

Strip the marketing and every option runs the same four-stage pipeline. One endpoint accepts your input, which is a URL, an uploaded file, or raw text. The service acquires and parses it: rendering JavaScript for pages, running OCR for scanned PDFs, or just reading the text you sent. A structuring stage turns that into fields, using a fixed ontology, your JSON schema, or a prompt. The response returns typed JSON, and the better ones attach provenance, a citation for each value showing where it came from.

The four stages hide the two decisions you’ll actually make.

How the model knows what to extract. Diffbot sends a single GET request with your token and a URL, renders the page, classifies it into its own types (product, article, image), and returns the objects it finds. You never write rules; you also never choose fields. Schema-driven tools work the other way: Firecrawl’s /extract takes a prompt or schema, Reducto fills your schema and cites the source span for every value, and Sapling’s extract endpoint pulls fields you name out of unstructured text, quoting the span each value came from. Fixed ontology means zero config and their field names. Your schema means your field names and your job to write it well.

How you wait. Web-page extraction is synchronous; one request, one response. Document extraction is often asynchronous because OCR is slow: Exabase’s extract endpoint returns immediately, and you poll or catch a webhook; Extend’s POST /extract_runs answers with a PROCESSING status you check later. If your pipeline can’t handle callbacks, that alone narrows the list.

What breaks is predictable. A login wall comes back as a login wall. A JavaScript shell comes back empty unless the service renders pages, which is why per-page credits vary. And when the target site redesigns, ontology-based services absorb the change; schema-and-prompt services drift until you notice the nulls.

Two industries, one search: buy by input type

The document family (Reducto, OpenParser, Talonic, Sapling, Exabase, Extend) competes on OCR quality, table handling, and per-field citations. Pick from it when your source already exists as a file or a text blob: invoices, contracts, support tickets, resumes.

The web family (Diffbot, Firecrawl, Octoparse, DataBlue) competes on rendering, anti-bot pressure, and per-page economics. Pick from it when the source is a live site that can redesign tomorrow.

Few services do both well, and I wouldn’t bet a pipeline on the ones claiming to. If your real requirement is bulk page fetching with proxy rotation and unblocking, that’s a different purchase, and the web scraping APIs comparison covers that ground. For the document side specifically, the document data extraction guide goes deeper, and the wider field is mapped in the data extraction pillar guide.

The options

1. Diffbot: best for reading pages without writing rules

Diffbot’s Extract reads a page the way it claims a person would: render, classify, return structured objects. One GET request with your token and the URL. Pricing is credit-based across every plan; a page extract costs one credit, two if Diffbot routes through a proxy, and exporting an entity from their Knowledge Graph costs 25.

Pros:

• Zero per-site configuration; the ontology is maintained for you
• Renders JavaScript, so SPA content comes back populated
• Classification handles page types you didn’t anticipate

Cons:

• You get Diffbot’s fields, not a schema of your choosing
• Credit pools make the entry price a sales conversation rather than a number on the page
• Niche page types fall outside the ontology and come back thin

2. Firecrawl: best for feeding LLM pipelines

Firecrawl scrapes, crawls, and maps sites, and its /extract endpoint structures the result against your prompt or JSON schema. The pricing page lists Hobby at $19/month, or $16 billed annually, for 5,000 credits; third-party writeups put the free tier around 1,000 credits a month and Standard near $83/month for 100,000. Read the fine print before you do the math on pages: structured extraction, PDF parsing, and browser interaction each consume more than the base one-credit scrape.

Pros:

• One service covers scrape, crawl, map, and extract, which keeps your stack short
• Your schema, your field names, versioned output
• A workable free tier for prototyping against 50 to 100 pages

Cons:

• Credit burn varies by feature, so cost forecasting is approximate
• Schema quality is entirely on you; a vague schema returns vague JSON
• Your URLs and extracted content transit their cloud

3. Octoparse Open API: best when a no-code team and developers share one pipeline

Octoparse is a visual scraper builder; the Open API is the programmatic door into what it produces. Their docs advertise 23 REST endpoints with an OpenAPI 3.0 spec and a free trial without a credit card. The intended shape is a data team configuring scheduled scrapers in Octoparse’s cloud, then code or tools like Airbyte, dbt, or Airflow pulling results into Snowflake or BigQuery.

Pros:

• Non-developers own the scraper configuration; developers own the plumbing
• Scheduled runs mean the data refreshes without a cron job on your side
• Warehouse-native integrations skip a transformation step

Cons:

• The API retrieves results; it doesn’t parse. Extraction logic lives in their cloud, configured through their UI
• Two abstractions to learn: their builder and their API
• Trial ends, and the useful endpoints sit behind paid plans

4. Reducto: best for documents with tables

Reducto’s Extract endpoint takes a schema and returns typed JSON, with a citation for every value tracing it back to the document. The parse stage exposes real knobs: figure summarizing, table output formats, chunking controls. It’s built for the documents where layout is the hard part, financial PDFs being the canonical example.

Pros:

• Per-value citations make downstream auditing cheap
• Table handling is a first-class feature, not a fallback
• Parsing options are exposed in the API rather than hidden behind “smart mode”

Cons:

• Documents only; it won’t fetch or read a web page
• Files upload and process asynchronously, so you’re polling or catching webhooks
• Another third party receiving your documents, which matters for contracts and financials

5. Sapling: best for text you already have

Sapling’s data extraction endpoint pulls fields you name out of unstructured text and returns typed JSON. Their docs use invoices, emails, resumes, support tickets, and contracts as the examples, and the design point is that there’s no template to train: describe the fields per request, get back the ones the document actually states, each grounded with a quoted span.

Pros:

• No fetching, no OCR; you send text and get fields, which keeps latency low
• Grounded values let you verify without opening the original
• Field definitions live in the request, so new fields need no retraining

Cons:

• Text-in only; whatever produced the text is your problem
• If the source never states a field, you get nothing back, by design
• Long documents can bury fields the model fails to notice

The local option: an api for data extraction on your own machine

Every option above is hosted. Magpie is not a hosted API, and that’s the plain limit: there is no endpoint to POST a URL to from your backend. It’s a local CLI plus an MCP server (13 tools, bound to 127.0.0.1) so AI agents on your machine can drive it.

What it gives you is the same structuring stage the hosted services sell: extraction against a JSON schema through your own LLM key, with seven providers to choose from including Ollama, which keeps the whole pipeline offline. Twenty-seven zero-LLM verticals return typed records with no model call at all, read from the source’s own API or structured data (JSON-LD, RSS), and a self-healing selector cache re-synthesizes selectors when a site redesigns.

The licensing mirrors the split personality: the CLI is free under AGPL-3.0-or-later (or a commercial licence), and the Desktop app gives you 5 free runs per install before a $49/month licence.

A live run on 2026-10-16 against a Guardian article, using the zero-LLM article vertical:

magpie scrape "https://www.theguardian.com/technology/2026/oct/16/elon-musk-reveals-worlds-first-flying-car-spacex" --vertical article --format json

{
  "url": "https://www.theguardian.com/technology/2026/oct/16/elon-musk-reveals-worlds-first-flying-car-spacex",
  "title": "Elon Musk reveals 'world's first flying car' at Tesla event | Tesla | The Guardian",
  "vertical": "article",
  "record": {
    "authors": ["Mark Sweney"],
    "datePublished": "2026-10-16T11:53:04.000Z",
    "dateModified": "2026-10-16T12:50:20.000Z",
    "headline": "Elon Musk reveals 'world's first flying car' at Tesla event",
    "publisher": "The Guardian"
  }
}

Output trimmed (the full record includes an image URL). One request, typed fields, zero tokens.

The other limits belong in the same paragraph as the pitch. Magpie respects robots.txt and throttles itself; it detects bot challenges and reports them rather than defeating them, and there’s no proxy network, so you’re scraping from your own IP at your own bandwidth. For a local-first alternative to the hosted options, the cloud vs local comparison lays out the trade.

What an extract api actually costs

Hosted pricing is per credit, and credits are not pages. Firecrawl’s Hobby plan buys 5,000 credits, but a structured extraction can cost several, so the real page count is lower than the headline. Diffbot charges one credit per page extract and two through a proxy, with monthly pools sized by plan. Usage-based document pricing (Reducto, Sapling) scales with pages processed and options enabled.

Budget per 1,000 pages, not per month. A plan that looks like $16/month supports a few hundred extractions once you apply the real credit rates, and volume is exactly where the local option inverts the math: Magpie’s marginal cost is your LLM tokens, and its zero-LLM verticals cost nothing at all on pages that publish structured data, which most news sites and product pages do. The wider cost breakdown lives in the web scraping cost guide.

How to choose

Match the tool to the input and the constraint, in that order.

• Documents (PDFs, scans, email text): Reducto if tables and citations matter, Sapling if you already hold the text.
• Web pages, managed, no config budget: Diffbot.
• Web pages feeding an LLM application: Firecrawl; start on the free tier and watch the extract credit rate.
• Mixed team with non-developers owning scrapers: Octoparse.
• Data that can’t leave your machine, or volume where per-credit pricing stings: Magpie locally, CLI for scripts and the MCP server for agents.

If an API turns out to be the wrong shape entirely and you want something you click, the data extraction tools comparison is the next read.

That last row is also a compliance statement. Hosted extraction means your URLs, your documents, and the extracted values all transit someone else’s cloud, under their retention policy. Regulated data doesn’t get to take the tour.

Data extraction API FAQs

What is a data extraction API?

A service that takes unstructured input, such as a page URL, a PDF, or raw text, and returns structured JSON through one endpoint: typed fields, sometimes with a citation per value. You steer it with a fixed ontology, your own schema, or a prompt.

How is this different from scraping APIs?

Web scraping APIs concentrate on fetching pages at scale: proxy rotation, JavaScript rendering, unblocking. Extraction APIs concentrate on structure. The categories overlap, and several products sell both halves, so judge them on the half you’re actually bad at doing yourself.

Are data extraction APIs legal?

Extracting publicly available data is generally lawful in the US, but the boundaries sit at login-walled content, personal data under GDPR, and copyright in the extracted material. Check robots.txt and terms of service for your targets. This is orientation, not legal advice.

Can I build my own?

For one known site, yes: a fetcher, a parser, and an LLM call with a JSON schema is an afternoon. Hosted APIs earn their price on breadth, meaning any site or document without new code, and on uptime. Magpie sits between: general-purpose and self-healing, but running where you run it.

Where I’d start

Documents with tables, Reducto; text blobs, Sapling. Web pages feeding an app, Firecrawl’s free tier, then Hobby if the extract credit rate survives contact with your volume. Web pages with no appetite for schema maintenance, Diffbot. And if the data is regulated, priced out by per-credit plans, or just not allowed to leave the building, run Magpie locally and start with the verticals: most news and product pages hand over typed records without a single token spent.