Migration guide
A ScrapingBee alternative that takes the same parameters
Most alternatives ask you to rewrite your integration against a different parameter vocabulary, then discover halfway through that the feature you relied on has no equivalent. Webfetch implements ScrapingBee's request surface deliberately, name for name and default for default, so the migration is a base URL and a key.
The whole migration
There is no second step. Parameter names, types, defaults and credit costs are unchanged, so the code around the call does not move either.
Before
curl "https://app.scrapingbee.com/api/v1/\
?api_key=$KEY\
&url=https%3A%2F%2Fexample.com\
&render_js=true\
&extract_rules=%7B%22title%22%3A%22h1%22%7D"After
curl "https://api.webfetch.io/v1/\
?api_key=$KEY\
&url=https%3A%2F%2Fexample.com\
&render_js=true\
&extract_rules=%7B%22title%22%3A%22h1%22%7D"
Response headers change prefix, from Spb- to Wf-, and carry the
same values: Spb-cost becomes Wf-Cost,
Spb-initial-status-code becomes Wf-Initial-Status-Code,
Spb-resolved-url becomes Wf-Resolved-Url, and
Spb-auto-cost becomes Wf-Auto-Cost. If you read those, that is
the one find-and-replace the move needs. Webfetch adds a few of its own, such as
Wf-Screenshot-Url and Wf-Proxy-Pool, listed in
the documentation.
Same credits, 38 to 40% less
Credit allowances are matched exactly, so the number of pages a plan buys does not change and neither does your capacity planning. Only the invoice moves.
| Credits per month | ScrapingBee | Webfetch | You keep |
|---|---|---|---|
| 250,000 | ScrapingBee Freelance $49.00 |
Pro $29.99 |
$19.01 /mo |
| 1,000,000 | ScrapingBee Startup $99.00 |
Scale $59.99 |
$39.01 /mo |
| 3,000,000 | ScrapingBee Business $249.00 |
Business $149.99 |
$99.01 /mo |
| 8,000,000 | ScrapingBee Business+ $599.00 |
Business+ $359.99 |
$239.01 /mo |
Credit costs per request are identical too: 1 raw, 5 rendered, 10 premium proxy, 25 premium with rendering, 75 stealth. Nothing about your per-call arithmetic changes. Every plan is price locked for life, so the figure you sign up at is the figure you keep for as long as the subscription runs.
Where the two actually differ
Compatibility is the point, so most rows would read "the same" and are left out. These are the places a decision could turn.
| Webfetch | ScrapingBee | |
|---|---|---|
| Free tier | 1,000 credits to start, then 250 every month, banking up to 1,000, no card | 1,000 credits once, as a trial |
| Concurrency | Matched tier for tier: 25, 50, 100, 200, 400 | 50, 100, 200, 400 |
| Per-minute rate cap | None. Concurrency bounds the instant, the monthly allowance bounds the total | None published |
premium_proxy |
Static ISP proxies: addresses registered to internet providers rather than hosting companies, which sites trust more than datacenter IPs | Residential |
stealth_proxy |
ISP exits in a browser hardened against bot detection, named in Wf-Proxy-Pool |
A separate pool for the hardest sites, with anti-bot hardening. The proxy type is not published |
| Price lock | Locked for the life of the subscription | Not offered |
| Per-scan bandwidth ceiling | 5 MB stealth, 25 MB otherwise, published, and named in Wf-Max-Bytes when a scrape reaches it |
Not published |
| MCP server | Built in, so an agent can call it as a tool directly | Offered |
| AI extraction | ai_query, ai_extract_rules and ai_selector are not implemented |
Offered |
| Dedicated scraper endpoints | One general endpoint; no per-site APIs | Google, Amazon, YouTube and others |
| Company | A new product from Tuxxin LLC, an IT company in business for nearly 16 years, whose founder has been part of several successful startups | Established, with a track record |
The AI extraction and dedicated-endpoint rows are theirs, not ours. If your integration depends on AI extraction or on a dedicated Google endpoint, ScrapingBee does something we do not, and switching would cost you that. We would rather you knew before you moved than after.
What carries over unchanged
Every one of these keeps its ScrapingBee name, type and default.
Rendering
render_js, wait, wait_for, wait_browser, window_width, window_height, block_resources, block_ads, device
Extraction
extract_rules with shorthand, selector_type, nesting, type: list, table_json, table_array and clean
Browser actions
js_scenario with click, fill, scroll_x, scroll_y, evaluate, infinite_scroll and strict
Proxies
premium_proxy, stealth_proxy, country_code, own_proxy, session_id
Output shapes
return_page_source, return_page_text, return_page_markdown, json_response, screenshot, screenshot_full_page, screenshot_selector
Request plumbing
cookies, forward_headers, forward_headers_pure, timeout, transparent_status_code, tag, and GET /v1/usage
mode=auto and max_cost work the same way too, and add
Wf-Auto-Attempts so you can see which routes were tried.
Before you move anything
Run one call side by side
Take a URL your integration already scrapes, send it to both, and diff the bodies. A free key costs an email address, so this is a ten-minute check, not a project.
Point a staging key at us
Change the base URL in one environment and leave production alone. The parameters do not change, so there is nothing to port and nothing to roll back but a string.
Move when the diff is boring
Keep both keys live through the cutover. Failed calls cost nothing on our side, so a parallel run costs only what actually succeeds.
Try it against a page you already scrape
1,000 free credits, then 250 a month, no card. If the output does not match what you get today, you have lost ten minutes.