Firecrawl Extract Deep Dive: Schemas, Cost, and the Dual-Billing You Need to Plan For

By the fastCRW team · Pricing notes verified 2026-05-18 · Confirm on firecrawl.dev before relying on cost figures.

Disclosure: fastCRW is a Firecrawl-compatible scraper built by the author. This post covers both the engineering of structured extraction and its economics, because for extraction the two are inseparable.

Why extract is the endpoint that decides your bill

Scrape and crawl give you content. Extract gives you data — a page turned into a typed JSON object you can write straight to a database or feed to a tool call. It's the endpoint behind lead enrichment, price monitoring, catalog ingestion, and most agent "fill this struct from the web" tasks. It is also, on Firecrawl, the endpoint with the pricing structure teams most consistently underestimate. Get the economics wrong here and the engineering elegance won't save the budget.

Two ways to ask for structure

Schema-driven — you provide a JSON Schema and the engine fills it:

{
  "url": "https://shop.example.com/p/8842",
  "formats": ["json"],
  "jsonOptions": {
    "schema": {
      "type": "object",
      "properties": {
        "title":  { "type": "string" },
        "price":  { "type": "number" },
        "currency": { "type": "string" },
        "in_stock": { "type": "boolean" },
        "rating": { "type": "number" }
      },
      "required": ["title", "price"]
    }
  }
}

Prompt-driven — you describe what you want in natural language and let the model infer the shape. Faster to prototype, less deterministic. Use prompt-driven for exploration; lock to a schema for production so the output is validate-able and your downstream code can trust it.

Schema design patterns that hold up in production

• Mark only truly-required fields required. Over-requiring forces the model to hallucinate a value rather than admit absence. A missing optional field is data; a hallucinated required field is a silent bug.
• Use enums for closed sets. "status": {"enum": ["in_stock","out_of_stock","preorder"]} beats a free-string field every time for downstream logic.
• Prefer flat over deeply nested. Extraction accuracy degrades with nesting depth. If you need a tree, consider two scoped extractions over one giant schema.
• Type numerics as numbers, not strings. Let the engine do the parsing/cleaning ("$1,299.00" → 1299.0) instead of post-processing strings yourself.
• Add a confidence or source field when accuracy matters, so downstream code can route low-confidence rows to review.

The economics: plan for dual billing

This is the part that matters more than any schema tip. On Firecrawl, AI-powered extraction is widely reported to run on a separate token-based subscription, distinct from the per-page credit pool you buy with your plan. The practical consequence reported across public discussions: a team on the Standard plan ($83–99/mo) that also needs extraction pays Standard plus an extraction add-on of roughly $89/mo — a combined ~$172–188/mo minimum before any usage-based growth. Multiple HN/Reddit threads describe the resulting bills as "egregiously expensive."

Why this trap is so easy to fall into: extraction is exactly the feature that the most committed users adopt. Pure markdown ingestion may never touch extract; agents, enrichment, and monitoring touch it on nearly every call. So the dual-billing surfaces precisely for the workloads that scale hardest — and the per-page credit forecast you built quietly understates the real bill.

The same data, a different cost model

fastCRW takes a deliberately different stance: structured JSON extraction is part of the scrape call, under the same 1-credit-per-page model. There is no separate extract product and no second subscription. You request the JSON format with a schema on the normal scrape endpoint; the credit is the same credit as a plain scrape. For an extraction-heavy pipeline this isn't a rounding difference — it can roughly halve the monthly bill versus the Standard-plus-extract floor, and it removes an entire line item from your forecast.

# fastCRW — extraction is just a scrape with a JSON format
from firecrawl import FirecrawlApp
crw = FirecrawlApp(api_key="key", api_url="https://your-fastcrw-host")

doc = crw.scrape_url("https://shop.example.com/p/8842", params={
    "formats": ["json"],
    "jsonOptions": {"schema": product_schema}
})
data = doc["data"]["json"]  # typed object, same per-page credit as a plain scrape

Migrating extract calls off Firecrawl

If your code calls a dedicated Firecrawl extract endpoint, the migration is to re-express it as a scrape requesting the JSON format/schema. This is usually a simplification, not extra work: one endpoint instead of two, one credit model instead of plan-plus-subscription. Validation checklist:

1. Run the same schema against 20+ representative pages on both backends.
2. Compare field fill-rate (how often each field is populated) — this catches schema/site mismatches faster than spot-checking.
3. Compare value accuracy on a labeled sample for the fields your business logic depends on.
4. Confirm error behavior on pages where extraction legitimately can't find the data (you want a clean null/absent field, not a hallucinated value).

Accuracy and reliability notes

Structured extraction quality depends on the page, the schema, and the model — not just the vendor. Independent testing of LLM-extraction scrapers generally shows strong results on standard content pages and degradation on hardened e-commerce/social and heavily dynamic apps. Practical guardrails that apply regardless of backend:

• Validate every extracted object against the schema in your own code; never trust the field is correct just because it's present.
• Track fill-rate over time as a regression signal — a sudden drop usually means the target site changed its markup.
• Keep schemas tight and scoped; broad "extract everything" schemas are both more expensive and less accurate.
• For business-critical fields, sample-audit against ground truth periodically.

The self-host angle for extraction-heavy work

Because fastCRW's engine is an open-core single ~6MB Rust binary (AGPL-3.0, unlimited self-host requests), an extraction-heavy pipeline can run with no per-page meter and no extract subscription at all on your own infra — while keeping the same Firecrawl-compatible API. Sensitive enrichment data (the kind extraction pipelines often handle) also never leaves your infrastructure in that mode. You can prototype on the managed cloud and pull the heavy extraction workload in-house later with a base-URL change, not a rewrite.

The one-line takeaway

Extract is where scraping turns into usable data — and on Firecrawl it's where the bill quietly doubles via a separate subscription. Plan that line item explicitly before you adopt, design tight validated schemas, and remember that a Firecrawl-compatible engine that folds extraction into one credit model (or removes the meter entirely via self-host) changes the economics of the exact workload you're most likely to scale.

Modeling the true cost of extraction at scale

The dual-billing structure means extraction cost does not scale like scraping cost, and conflating them is the central forecasting mistake. Model it as two independent terms:

• Per-page term: the credit (or self-host server cost) to fetch the page. Scales with page count, predictable.
• Extraction term (Firecrawl): a separate token-based subscription that scales with extraction volume and schema complexity, with its own floor (~$89/mo reported) and its own growth curve. This term is invisible in a credit-only forecast and is exactly the one that surprises teams.

The practical consequence: two pipelines scraping the same number of pages can have wildly different bills purely based on how many of those pages they extract structure from. A monitoring pipeline that scrapes 100k pages but extracts on none pays the credit term only. An enrichment pipeline that extracts on all 100k pays both — and the second term often exceeds the first. Forecast them separately or the forecast is fiction. On a single-credit Firecrawl-compatible engine the second term collapses into the first, which is why the architectural choice here is worth more than any schema micro-optimization.

Extraction quality engineering, beyond the schema

Schema design is necessary but not sufficient for reliable extraction. The operational practices that separate a demo from production:

1. Golden dataset. Hand-label 50–100 pages with the correct extracted values. Every backend, model, or schema change is regression-tested against it. Without this you are flying blind on accuracy.
2. Fill-rate dashboards per field. Track how often each field is populated over time. A sudden drop almost always means the target site changed its markup — this is your earliest, cheapest signal of silent breakage.
3. Confidence routing. For business-critical fields, route low-confidence or schema-violating extractions to a review queue instead of writing them straight to the system of record.
4. Idempotent re-extraction. Key extracted records by source URL + content hash so a re-run updates rather than duplicates, and unchanged pages are skipped entirely — the same recurring-cost lever that dominates every ingestion workload.
5. Schema versioning. Store the schema version alongside each extracted record so a schema change does not silently make old and new rows incomparable.

The decision, framed honestly

Extraction is the endpoint where the engineering and the economics are inseparable, so the decision must weigh both. If your pipeline extracts on a minority of pages and you value Firecrawl's ecosystem, the dual-billing may be tolerable — price it explicitly and proceed. If you extract on most pages (the normal case for agents, enrichment, monitoring, and catalog ingestion), the separate subscription is structurally the largest line in your bill, and a Firecrawl-compatible engine that folds extraction into one per-page credit — or removes the meter entirely via a self-hosted single ~6MB AGPL-3.0 binary, keeping sensitive enrichment data on your own infra — is not a marginal saving but a different cost class. Architect the extraction layer to be backend-neutral now, and that decision stays reversible as your extraction volume grows into the range where it dominates everything else.

Sources

• Firecrawl extract docs and pricing: docs.firecrawl.dev · firecrawl.dev/pricing (verified 2026-05-18)
• fastCRW repo: github.com/us/crw

Related: Firecrawl pricing explained · Firecrawl /scrape deep dive