Skip to main content
If you are already running against Firecrawl Cloud (api.firecrawl.dev), migrating to ZapFetch requires three changes and no code refactoring. ZapFetch is wire-compatible with both the /v1/* and /v2/* Firecrawl endpoints, so your existing SDK calls, request bodies, and response-parsing logic all continue to work exactly as they are. The only things that change are where you point your client and which key you pass.

​
Why migrate?

  • USD billing, metered by usage. No commits, no minimums, no surprise overages. Every response tells you how many credits remain. See the Billing page for plan details.
  • Same SDKs, same schemas. You keep using firecrawl-py and @mendable/firecrawl-js. No vendor-specific client, no lock-in.
  • Both v1 and v2 endpoints supported. Whichever version your current Firecrawl SDK talks, ZapFetch accepts it — no version pinning required.
  • Run both in parallel during migration. Your Firecrawl Cloud key keeps working on api.firecrawl.dev while you test ZapFetch on api.zapfetch.com. Migrate traffic gradually if you prefer.

​
Migration steps

1

Get a ZapFetch API key

Sign in to the ZapFetch Console with GitHub, Google, or email. Open Dashboard → API keys and click Create key. Copy the UUID key — it is shown once.
ZapFetch API keys are UUID strings, not fc- prefixed Firecrawl Cloud keys. If your existing config validates the fc- prefix, relax that check before switching traffic.
2

Swap the base URL

Point your SDK or HTTP client at https://api.zapfetch.com.
- curl -X POST https://api.firecrawl.dev/v1/scrape \
+ curl -X POST https://api.zapfetch.com/v1/scrape \
    -H "Authorization: Bearer YOUR_ZAPFETCH_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{ "url": "https://example.com", "formats": ["markdown"] }'
3

Replace the API key

Swap your Firecrawl key for the ZapFetch key you copied in Step 1. If you store credentials in an environment variable, only the value changes — the variable name can stay the same.
- FIRECRAWL_API_KEY=firecrawl-key-here
+ FIRECRAWL_API_KEY=zapfetch-uuid-key-here

​
Smoke test

Run one scrape to confirm the migration is working: 
curl -X POST https://api.zapfetch.com/v1/scrape \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://example.com", "formats": ["markdown"] }'
You should receive an HTTP 200 with a data.markdown field and a credit-usage object (creditsUsed, remainingCredits) in the response envelope. If you see both, the migration is complete.

​
FAQ

​
Is there full feature parity?

Yes. Both /v1/* and /v2/* endpoints — scrape, crawl, search, map, and extract — are fully supported. Request and response schemas match the Firecrawl spec. If you encounter a behavioral difference, treat it as a bug and file it via the Console.

​
How does ZapFetch pricing compare?

ZapFetch is credit-based and billed in USD. The current plans are outlined on the Billing page. Pricing is subject to change; the source of truth is always console.zapfetch.com/dashboard/billing.

​
Can I run Firecrawl and ZapFetch in parallel?

Yes. Your Firecrawl Cloud key continues to work on api.firecrawl.dev, and your ZapFetch key works on api.zapfetch.com. You can shadow traffic to ZapFetch for testing before cutting over fully, or run both indefinitely if you have a reason to.

​
What about rate limits?

ZapFetch returns a standard 429 Too Many Requests with a Retry-After header when you exceed your plan’s rate limit — the same shape the Firecrawl SDK already handles. Your existing retry and backoff logic works unchanged.