Do I have to rewrite my Firecrawl SDK calls?

No. Change the base URL and keep the existing code. The SDK's request building and response parsing already match fastCRW's shape.

Will my crawl polling code keep working?

Yes. POST /v1/crawl returns a job id and GET /v1/crawl/{id} returns the same status fields and accumulated data entries, so existing poll loops continue to work without changes.

Can I run fastCRW and Firecrawl side by side during migration?

Yes. Because the contract is identical, you can route a percentage of traffic to each base URL and compare responses field by field before cutting over.

What does "Firecrawl-compatible" mean for migration?

Short answer: In migration terms, "Firecrawl-compatible" means you change exactly one thing in your code — the base URL — and everything else (endpoint paths, auth header name, request body keys, response wrapper shape) stays the same. A migration that would normally take days of client refactor becomes a one-line config change.

The one-line migration

Concretely, migrating from Firecrawl Cloud to fastCRW Cloud is:

- BASE_URL = "https://api.firecrawl.dev"
+ BASE_URL = "https://api.fastcrw.com"

The auth header name (Authorization: Bearer ...) does not change. The request body for POST /v1/scrape, /v1/crawl, /v1/extract, /v1/map, and /v1/search uses the same field names. The response is still wrapped in {"success": true, "data": {...}} so callers reading response.data.markdown or response.data.links need no changes.

What does change

API key: fastCRW issues its own keys — the header name and scheme are identical, but the secret value is new. Rotate via env var, not code.
Optional self-hosting: migration unlocks an option Firecrawl users do not have — point the same client at http://localhost:3000 running the AGPL-3.0 binary, with no auth required by default. Same endpoints, same request and response shapes.
Extra response fields: responses include additive fields like renderDecision and creditCost. Existing clients ignore them; new clients can use them for cost telemetry.

How fastCRW does it

Every endpoint listed in the compatibility matrix ships under /v1/ with the Firecrawl-shaped contract. Detailed per-endpoint request/response examples live under the API reference. The self-hosted binary is AGPL-3.0 and ~50 MB RAM idle, so the same code path works against a managed endpoint or a local one.

Frequently asked

Do I have to rewrite my Firecrawl SDK calls?: No. Change the base URL and keep the existing code. The SDK's request building and response parsing already match fastCRW's shape.
Will my crawl polling code keep working?: Yes. POST /v1/crawl returns a job id and GET /v1/crawl/{id} returns the same status fields and accumulated data entries, so existing poll loops continue to work without changes.
Can I run fastCRW and Firecrawl side by side during migration?: Yes. Because the contract is identical, you can route a percentage of traffic to each base URL and compare responses field by field before cutting over.

← CRW docs home