[Fast]
C
R
W
Docs/Docs / Compatibility

Compatibility Matrix

What fastCRW aligns with in Firecrawl-style workflows, and what still differs.

Published
March 11, 2026
Updated
March 11, 2026
Category
docs
Request-shape compatibilityKnown differences called outNo drop-in overclaim

What "Compatible" Means Here

fastCRW is built around Firecrawl-compatible workflows, not a blanket "drop-in replacement" claim. The goal is to preserve the core request mental model so migrations are manageable, while still documenting the places where behavior differs.

Supported alignment

AreaStatus
/v1/scrape, /v1/crawl, /v1/map route shapeSupported
limit, maxPages, max_pages for crawl capsSupported
Numeric waitFor for JS renderingSupported
cssSelector, xpath, chunkStrategy, filterModeSupported

Known differences

AreaCurrent behavior
Screenshot outputNot supported in this release
success semanticssuccess: false when target returns HTTP 4xx/5xx with minimal content; success: true with warning when target returns error status but has real content
JS waitingNumeric delay only; no selector-based wait primitive in cloud docs
extract formatAccepted as alias for json. Use formats: ["json"] with jsonSchema for structured extraction
SDKsRaw HTTP examples only, no official language SDK package

Treat this page as the source of truth during migrations.

Migration Checklist

If you are moving an existing Firecrawl-style integration:

  1. verify scrape, crawl, and map request bodies against real targets,
  2. confirm how your code interprets success, warning, and target-side HTTP statuses,
  3. remove dependencies on unsupported features such as screenshots,
  4. and compare output quality, not just endpoint shape.

Compatibility at the request level is useful, but output semantics and operational behavior matter just as much.