Can I point an existing Firecrawl SDK at fastCRW?

For Firecrawl v2 SDK migrations, point the SDK at https://api.fastcrw.com and validate the documented differences on your workload.

Are response fields exactly the same?

No. The compatibility layer preserves the common shape where practical, but warnings, metadata, unsupported options, and error semantics can differ.

Does compatibility cover the crawl polling pattern?

Yes for the v2 compatibility surface: POST /v2/crawl returns a job id and GET /v2/crawl/{id} returns status plus paginated results.

What is a Firecrawl-compatible API?

Short answer: A Firecrawl-compatible API preserves the core request model enough to migrate existing Firecrawl integrations with limited code changes. For fastCRW, new projects should start with native /v1; existing Firecrawl v2 SDK projects should use the /v2 compatibility layer and validate behavior before production traffic moves.

Which endpoints are covered

A useful migration surface covers the common scrape, crawl, map, search, extract, batch, and parse workflows. In fastCRW, the recommended native routes are /v1/*; Firecrawl v2 SDK compatibility lives under /v2/*.

POST /v1/scrape — single-URL extraction returning markdown, html, links, or structured JSON.
POST /v1/crawl — multi-page crawl, started as a job and polled via GET /v1/crawl/{id}.
POST /v1/scrape with formats:["json"] — CRW-native structured extraction for self-hosted engines.
POST /v1/map — sitemap-style URL discovery for a domain.
POST /v1/search — web search with optional inline scrape of each result.

What "compatible" really means

Compatibility is not just URL parity. Before a production migration, validate:

Request body mapping: field names, defaults, aliases, and unsupported options.
Response wrapper mapping: top-level envelopes, warnings, metadata, and error semantics.
Auth header parity: the same Authorization: Bearer ... scheme on the hosted variant.
Error handling: status codes and error JSON shape so retry logic behaves correctly.

How fastCRW does it

fastCRW exposes native /v1 routes at https://api.fastcrw.com and a Firecrawl v2 compatibility layer under /v2. See the compatibility matrix and the full API overview. The Rust binary itself is AGPL-3.0 and runs at ~50 MB RAM idle, so the same engine is available self-hosted at http://localhost:3000.

Frequently asked

Can I point an existing Firecrawl SDK at fastCRW?: For Firecrawl v2 SDK migrations, point the SDK at https://api.fastcrw.com and validate the documented differences on your workload.
Are response fields exactly the same?: No. The compatibility layer preserves the common shape where practical, but warnings, metadata, unsupported options, and error semantics can differ.
Does compatibility cover the crawl polling pattern?: Yes for the v2 compatibility surface: POST /v2/crawl returns a job id and GET /v2/crawl/{id} returns status plus paginated results.

← CRW docs home