Drop-In Firecrawl-Compatible API Checklist

By the fastCRW team · API surface, endpoints, and pricing verified 2026-05-18 · fastCRW launch pricing expires 2026-06-01 · Verify independently before migrating.

Disclosure: We build fastCRW, so this checklist is vendor-authored. We've written it so you can run it against any tool — including ours — and we mark fastCRW's real divergences plainly. The point is to give you a test, not a verdict.

What a drop-in Firecrawl-compatible API actually means

A genuinely drop-in Firecrawl-compatible API is one where you keep your existing code, swap the base URL and API key, and your pipeline keeps working. No new SDK, no re-mapped request bodies, no rewritten response parsing. If a vendor advertises "Firecrawl-compatible" but you still have to change function calls or rewrite how you read the response, that is API-inspired, not drop-in — and the difference shows up as a migration project rather than a config change.

The phrase gets stretched a lot, so it helps to fix a strict definition before you evaluate anyone. Drop-in compatibility has four layers, and a tool can pass one while failing the next:

• Transport parity: same base path shape (/v1/scrape, /v1/crawl, /v1/map, /v1/search), same HTTP methods, same auth header.
• Request parity: the same request body keys (formats, maxDepth, maxPages, jsonSchema) are accepted and mean the same thing.
• SDK reuse: the official Firecrawl SDK works unchanged after you point it at the new api_url.
• Response parity: the response envelope and field names match closely enough that your downstream code reads the same keys.

This page is the verification checklist. It is deliberately not a vendor ranking — for "is X a good Firecrawl alternative," see our Firecrawl alternatives guide. For the canonical, field-level compatibility reference, see Firecrawl API compatibility. This post sits between them: a repeatable test you run before you commit to migrating.

The drop-in compatibility checklist

Run these checks against any candidate API. Each one is a yes/no you can answer in an afternoon with curl and your existing SDK.

1. Endpoint parity — which /v1 routes exist

List the endpoints your pipeline actually calls, then confirm each exists with the same path and method. The core Firecrawl surface most pipelines use is four routes:

The trap here is the long tail. Firecrawl Cloud also exposes specialty endpoints — multi-URL batch extract, an agentic endpoint, deep research. If your code calls one of those, a tool that only implements the core four is not drop-in for you, even if it is for everyone else. Inventory your real call sites, not the full Firecrawl docs.

2. SDK reuse — does the official Firecrawl SDK work unchanged

This is the single highest-value check, because it collapses the other three into one observable test. Point the official Firecrawl SDK at the candidate's base URL, run your existing test suite, and see what breaks. If the SDK constructs the same requests and parses the same responses without a code change, you have transport, request, and response parity in one shot. If you have to fork the SDK or hand-roll an HTTP client, you do not have a drop-in API. See how the Firecrawl SDK base-URL swap works for the exact lines to change.

3. Response-field and error-envelope divergence to expect

This is where "compatible" quietly leaks. Two APIs can accept identical requests and return semantically identical data while naming fields slightly differently or wrapping errors in a different envelope. Before you migrate, diff a real response from both APIs on the same URL and check:

• Does the success envelope put data under the same top-level key your code reads?
• Are markdown, HTML, and metadata fields named identically?
• On a failure (bad URL, unsupported format), is the error shape — status code plus body — close enough that your error handling still triggers?

Be honest with yourself about which fields you actually consume. Most pipelines read markdown and a couple of metadata fields; if those match, minor divergence elsewhere is harmless. The migration risk is concentrated in the three or four fields your code branches on.

4. Credit and limit mapping

Compatibility is about behaviour, but billing and limits decide whether the migration is worth it. Map the candidate's credit costs and crawl caps to your usage. Confirm how maxDepth, maxPages, and formats are metered, and whether JSON extraction costs more than a plain scrape — it usually does, and that single fact can dominate an extraction-heavy bill. Don't hard-code anyone's price table from a blog post; check the live pricing page and your own projected volume.

Running the checklist against fastCRW

Here is the checklist applied to fastCRW, with the wins and the divergences stated at the same volume.

Endpoints present

fastCRW implements the core four — /v1/scrape, /v1/crawl (async BFS, returns a job ID, with GET/DELETE on /v1/crawl/:id), /v1/map, and /v1/search — plus /mcp for the streamable MCP transport and an unauthenticated /health check. crawl accepts maxDepth and maxPages (limit and max_pages are accepted aliases), with a maxDepth cap of 10 and a maxPages cap of 1000. auto selects the renderer and falls back chrome → lightpanda → http; chrome is opt-in in the default Docker Compose. Firecrawl's engine parameter is accepted as an alias.

SDK reuse and tooling

fastCRW is Firecrawl-compatible REST and is drop-in after a base-URL swap — the common case is changing api_url in the Firecrawl SDK and keeping your code. There is also an MCP package, crw-mcp@0.6.0, and a Python SDK, crw, whose CrwClient() runs a self-contained local engine. So the "swap base URL, keep the SDK" test passes for the scrape/crawl/map/search surface most pipelines exercise.

Honest divergence — read this before you migrate

fastCRW is not byte-for-byte Firecrawl, and pretending otherwise would defeat the purpose of a checklist. The real divergences:

• Response fields and error envelopes have minor divergence from Firecrawl. Diff your consumed fields before cutover.
• No multi-URL batched /v1/extract. /v1/extract exists on the managed cloud only — a single-URL, 5-credit convenience wrapper over /v1/scrape with formats: ["json"]. There is no /v1/batch/scrape; for many URLs you iterate /v1/scrape concurrently or use /v1/crawl.
• No /v1/agent (Spark) and no /v1/deep-research. If your code calls either, fastCRW is not drop-in for that path.
• Screenshot output is not supported — a request for formats: ["screenshot"] returns HTTP 422.
• Stateless per request — no persistent session/state — and LLM extraction supports OpenAI and Anthropic providers only (the managed /v1/search answer path uses a managed LLM separately).

None of these touch the four core endpoints; all of them matter if your pipeline depends on the specialty surface. That is exactly what the endpoint-inventory step in the checklist is for.

Where Firecrawl genuinely wins

A compatibility checklist is only useful if it tells you when not to switch. Firecrawl wins these outright, and they are reasons to stay:

• Specialty endpoints. Multi-URL batch extract, the agentic endpoint, and deep research are real Firecrawl-cloud features with no fastCRW equivalent. If your pipeline depends on them, fastCRW is not a drop-in replacement for that part of your stack.
• Screenshots. Firecrawl returns screenshot output; fastCRW returns HTTP 422. If you capture page images, that is a hard gap.
• Heavy anti-bot. Firecrawl's cloud anti-bot paths handle hostile targets fastCRW does not, since fastCRW ships no Fire-engine anti-bot.
• Ecosystem and maturity. Firecrawl is the category reference — more tutorials, more community examples, longer track record.

How this differs from our firecrawl-alternatives guide

It is worth being explicit about the division of labour across our three Firecrawl pages, so you land on the right one:

• This page is pure compatibility verification — a yes/no test you run before migrating any tool.
• Firecrawl alternatives is the vendor ranking — "is X a good Firecrawl alternative," weighing tools against each other.
• Firecrawl API compatibility is the canonical, field-level reference this checklist links up to when you need the exact request/response detail.

Migrating once the checklist passes

If the four checks pass for your call sites, the migration is genuinely small:

1. Swap the base URL and key. Point the Firecrawl SDK's api_url at fastCRW and supply your key. Keep your code. Our migration walkthrough covers the exact steps and the short field-divergence list to validate.
2. Map credit costs and crawl limits. Confirm your maxDepth/maxPages usage fits the caps (10 / 1000) and that your extraction volume costs what you expect — check /pricing against your projected traffic.
3. Self-host for $0, or use managed. The engine is a single static Rust binary under AGPL-3.0; self-hosting is $0 per 1,000 scrapes (you pay only your server), versus a hosted Firecrawl range of roughly $0.83–5.33 per 1,000 scrapes (competitor prices verified 2026-05-18). The same compatible API runs in both modes, so the escape hatch stays open either way.

The reason to standardize on the compatible surface is that the decision becomes reversible: write your client once against the Firecrawl-compatible shape, and switching backends is a config value, not a rewrite — in either direction.

Sources

• Firecrawl docs and pricing: docs.firecrawl.dev · firecrawl.dev/pricing (verified 2026-05-18).
• fastCRW repo and packages: github.com/us/crw · crw-mcp@0.6.0 (npm) · crw (PyPI) · fastcrw.com.

Related: Firecrawl API compatibility · Firecrawl SDK base-URL swap · Firecrawl alternatives · Migrate the Firecrawl SDK to crw