Migrate from Firecrawl to fastCRW in 10 Minutes — Drop-In Guide

Verdict

Migrating from Firecrawl to fastCRW takes about 10 minutes because fastCRW exposes a Firecrawl-compatible REST API — the same base request shape on /v1/scrape, /v1/crawl, /v1/map, and /v1/search. For most teams the move is a base-URL swap: keep the firecrawl-py SDK, point FirecrawlApp at https://api.fastcrw.com (or your self-host URL), and your call sites stay the same.

The compatibility matrix below maps every endpoint, including where fastCRW ships a native equivalent under a different route.

Who this is for

• Teams already on Firecrawl wanting a lighter runtime — fastCRW is a single static Rust binary with no Redis, Node, or container orchestration.
• Teams hitting Firecrawl's managed pricing — fastCRW Standard is $69/mo for 100k credits versus Firecrawl Standard at $83/mo for 100k credits.
• Teams that need self-hosting — fastCRW is AGPL-3.0; the self-host build is $0/1k scrapes in license terms.

The one capability fastCRW doesn't match is Firecrawl's hosted /v1/agent (Spark models) runtime. Everything else has a native equivalent: batch scraping on /v2/batch/scrape, research fan-out on /v1/search/research/papers, built-in anti-bot (12-signal detection, UA rotation, stealth fingerprints, residential-proxy egress), screenshots on the /v2 surface, and multi-URL /v1/extract up to 50 URLs per request.

Before and after: the base-URL swap

The core of this migration is one constructor argument. Here is a typical Firecrawl scrape:

# Before — Firecrawl
from firecrawl import FirecrawlApp

app = FirecrawlApp(api_key="fc-YOUR_KEY")
result = app.scrape_url(
    "https://example.com",
    params={"formats": ["markdown"]},
)
print(result["markdown"])

The fastCRW version changes the base URL and the key, nothing else:

# After — fastCRW (Firecrawl-compatible)
from firecrawl import FirecrawlApp

app = FirecrawlApp(
    api_key="crw_live_YOUR_KEY",
    api_url="https://api.fastcrw.com",  # or your self-host URL
)
result = app.scrape_url(
    "https://example.com",
    params={"formats": ["markdown"]},
)
print(result["markdown"])

If you call the HTTP API directly, the swap is just as small:

# Before — Firecrawl
curl -X POST https://api.firecrawl.dev/v1/scrape \
  -H "Authorization: Bearer fc-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "formats": ["markdown"]}'

# After — fastCRW
curl -X POST https://api.fastcrw.com/v1/scrape \
  -H "Authorization: Bearer crw_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "formats": ["markdown"]}'

Pin the SDK with pip install "firecrawl-py>=1,<2" so you stay on the v1 shape (FirecrawlApp, scrape_url(..., params=...)) that fastCRW targets.

Endpoint mapping table

This table maps every Firecrawl route to its fastCRW equivalent so you can audit the move before you make it. Unsupported features are marked honestly. (Endpoint surface verified 2026-05-22; re-verify the live route list before quoting.)

Firecrawl endpoint / param	fastCRW equivalent	Migration note
POST /v1/scrape	POST /v1/scrape	Same request shape. Costs 1 credit (any renderer, including chrome).
POST /v1/crawl	POST /v1/crawl	Async → returns a job id. Costs 1 credit per page.
GET /v1/crawl/{id}	GET /v1/crawl/{id}	Same job-status contract. DELETE /v1/crawl/{id} cancels.
POST /v1/map	POST /v1/map	Same shape. Costs 1 credit.
POST /v1/search	POST /v1/search	Costs 1 credit per query.
POST /v1/extract (single URL)	POST /v1/extract	Self-host: your own configured LLM key. Cloud: managed LLM, paid plans. Base scrape credit + LLM token cost, settled from real usage. Single url returns { data }.
POST /v1/extract (multi-URL)	POST /v1/extract with urls: [...]	Native multi-URL extraction, up to 50 URLs; returns a per-URL results array.
POST /v1/batch/scrape	POST /v2/batch/scrape	Same batch semantics on the /v2 surface; or iterate /v1/scrape concurrently, or use /v1/crawl for site-wide jobs.
formats: ["screenshot"]	formats: ["screenshot"] on /v2	Served by the /v2 surface as a base64 data URL (screenshot@fullPage included), not by native /v1.
POST /v1/deep-research	GET /v1/search/research/papers	Different shape (query+k params, arXiv/OpenAlex/Semantic Scholar fan-out) — a native research primitive, with the highest ArXivQA recall of any tested tool (61.0% vs Firecrawl 53.3%).
engine param	renderer param (engine accepted as alias)	Renderers: auto, http, lightpanda, chrome.
limit / maxPages on crawl	maxPages (limit, max_pages are serde aliases)	Also accepts maxDepth for depth control.
Fire-engine anti-bot	Built-in anti-bot stack	12-signal block detection, UA rotation, stealth fingerprints, and residential-proxy egress ship natively in the open core — not a Fire-engine-branded product, but not a fallback either.
LLM extraction provider	fastCRW managed LLM (no key to supply)	formats: ["json"] extraction supports these two providers.
GET /v1/health style check	GET /health	Liveness probe.

Step-by-step migration

The numbered steps below mirror the howToSteps schema for this page.

1. Audit your Firecrawl endpoint usage

Grep your codebase for Firecrawl calls. List which routes you hit — scrape, crawl, map, search, extract — and flag any screenshot output, which moves to the /v2 surface. Those flagged calls are the only ones that need rework.

2. Provision a fastCRW API key

Visit fastcrw.com, sign up, and copy your key (it starts with crw_live_). The Free tier ships 1000 one-time lifetime credits that never reset. If you self-host the AGPL-3.0 build, you can skip this — auth is optional in self-host mode.

3. Point your SDK at the fastCRW base URL

Set api_url="https://api.fastcrw.com" on FirecrawlApp (or your self-host URL). This is the load-bearing change — your scrape_url, crawl_url, and search call sites stay identical.

4. Pin the SDK version

Run pip install "firecrawl-py>=1,<2". The v1 SDK shape — FirecrawlApp, scrape_url(..., params=...) — is what fastCRW's Firecrawl-compatible surface targets. Pinning prevents a future v2 SDK from shifting the contract under you.

5. Run your test suite and adjust diverged fields

Run your existing tests against fastCRW. The request shape matches, but response field names and error envelopes have minor divergences (notably parts of the metadata object). Adjust any code that reads those specific keys. Most call sites need no change.

6. Replace unsupported feature calls

Point any formats: ["screenshot"] call at the /v2 surface — it returns the image as a base64 data URL. Native /v1/extract accepts a urls array (up to 50 URLs per request) and returns a results array, so a batched extract needs no rewrite.

7. Verify in the playground, then cut over

Test your target URLs in the playground across all four overlap endpoints. Confirm the response shape works for your parser before you flip production traffic.

What does not carry over

Be explicit with your team about these divergences before you migrate:

• Screenshots are a /v2 format. formats: ["screenshot"] is served by /v2/scrape, not by native /v1.
• /v1/extract billing. It accepts a urls array (up to 50 URLs per request) and returns a results array. Billed as 1 scrape credit per URL plus the LLM token cost for that request, settled from real usage — self-host via your own configured LLM key, Cloud via the managed LLM (paid plans).
• No /v1/agent. Firecrawl's hosted Spark-model agent runtime has no fastCRW equivalent. Deep-research has a native equivalent in /v1/search/research/papers.
• Anti-bot is native, not Fire-engine-branded. fastCRW ships 12-signal block detection, UA rotation, stealth fingerprints, and residential-proxy egress in the open core; in fast mode, fastCRW p90 is 4348ms — the lowest of the three tools tested.
• Stateless. No persistent browser sessions.
• LLM extraction runs on fastCRW's managed LLM on Cloud, or your own configured LLM key on self-host.
• Response field names and error envelopes diverge slightly. The API is compatible, not byte-identical.

Performance and pricing context

On Firecrawl's public scrape-content-dataset-v1 (1,000 URLs, 819 labeled; diagnose_3way.py, 2026-05-08), fastCRW reached 63.74% truth-recall of 819 labeled URLs versus Firecrawl's 56.04%, with a p50 of 1914 ms versus Firecrawl's 2305 ms across 3,000 requests with 0 errors. In fast mode, fastCRW p90 is 4348ms — the lowest of the three tools tested, below Firecrawl's 6937ms. In recall mode, the chrome-stealth fallback recovers the 34 URLs neither Firecrawl nor Crawl4AI can reach. Read the methodology before quoting these numbers.

On price, fastCRW Standard is $69/mo for 100k credits versus Firecrawl Standard at $83/mo for 100k credits; the AGPL-3.0 self-host build is $0 in license terms. Hobby is $13/mo.

Related

• Firecrawl alternative comparison
• Migrate from Jina Reader
• Migrate from Tavily
• fastCRW public benchmark
• fastCRW scrape docs
• fastCRW pricing