Questions people actually ask

No. A free account starts with 1,000 credits, gets 250 more every month, and needs only a working email address. We send a six-digit code to confirm it, and that is the entire signup.

It keeps going. You start with 1,000 credits, and 250 more arrive on the 1st of every month for as long as the account exists, banking up to 1,000 if you do not use them. ScrapingBee's comparable free tier is a single 1,000-credit balance that is not replaced once it is spent.

Upgrade while signed in to your key portal, or pay with the same email address, and you keep the same API key, so nothing changes in your code. A paid plan starts its own monthly allowance, and the free balance does not carry over, so there is no point saving it up first. One-time bonus credits from a promo code stay with the key. If you cancel a paid plan, your key keeps working to the end of the period you paid for, then drops back to the free tier, starting again at 1,000 credits with 250 more each month. If a payment fails, the plan keeps working for 72 hours while you fix it in PayPal, and we email you each day.

Yes. The demo on the home page runs a real scrape against any URL you give it, on the same engine the API uses. No key is asked for, and the page it fetches is not stored.

The base URL and the key. Change https://app.scrapingbee.com/api/v1/ to https://api.webfetch.io/v1/, use a webfetch key, and the rest of the request is unchanged: every parameter keeps its name, type and default, and the credit table is identical. Read Wf- response headers instead of Spb-.

The two proxy parameters map to different pools. ScrapingBee's premium_proxy is residential; ours routes static ISP proxies, addresses registered to internet providers that sites trust more than datacenter IPs. Their stealth_proxy is a separate pool with anti-bot hardening (they do not publish the proxy type); ours routes ISP exits in a browser hardened against headless detection. See the full comparison.

The AI extraction parameters (ai_query, ai_extract_rules, ai_selector), scraping_config, and the Google Search endpoint. Sending one is reported in Wf-Unknown-Parameters rather than silently ignored, so a call that depends on one fails visibly.

Plans are billed monthly in advance through PayPal. Cancel any time; access continues to the end of the period already paid for, then the key drops back to the free tier, starting again at 1,000 credits. Partial months are not prorated.

A failed request is never billed in the first place, so there is nothing to refund there. Outside of that: a normal cancellation is not refunded for the unused part of the current period, and an account closed for an acceptable-use breach also ends without a refund for the remainder of the period. See the terms of service.

The price you sign up at is the price you keep, for as long as your payment method stays active and the subscription does not lapse. Cancel, or leave a failed payment unfixed for 72 hours, and the lock goes with it; rejoining later is at the price of the day.

On a paid plan, no: the monthly allowance resets on the 1st. On the free tier, yes, up to a point: the balance carries over and grows by 250 each month, but stops growing at 1,000. Bonus credits from a signup promo code are separate: one-time, spent only after the free balance or the monthly allowance runs out, and they survive a month boundary until used. Remaining bonus balance is reported in Wf-Bonus-Credits.

A concurrency ceiling per plan: 5 on the free tier, 25 on Starter, up to 400 on Business+. It is a per-key ceiling on simultaneous in-flight requests, and a render_js=false call never holds a slot at all because it never launches a browser.

Yes. The free tier is best effort. When paid traffic is heavy and open capacity falls to the share held back for paying customers, a free request gets HTTP 503 with code free_tier_busy and a Retry-After header, usually 30 seconds. Nothing is charged, and it never happens the other way round: paid plans are not turned away to make room for free traffic.

Yes, independent of your plan's concurrency. Requests to a single target host are capped per key and across all callers combined, so pointing many keys at one site to get around the limit does not work and is itself a breach of the acceptable use policy.

A bandwidth ceiling measured on the wire, not on the returned document, so the assets a page loads count toward it: 5 MB through the stealth pool, 25 MB everywhere else. A page that reaches it still returns what was captured, billed normally, marked Wf-Truncated. Ordinary pages are nowhere near either ceiling.

Yes, with respect_robots=false. It needs an account, needs the acceptable use policy accepted on that key first, and every use of it is logged per request. It does not create permission you did not otherwise have. The responsibility for that decision moves onto the key that made it.

No. The response body is streamed back to you and discarded; we do not retain it. A screenshot you ask for is the exception: it is stored for 30 days at an unguessable link, so you can download it. We keep the request's URL, host and outcome, and the IP address it came from, for up to 45 days, for billing and abuse handling. See the privacy page for the complete table.

Tuxxin LLC, which also operates webshot.site, the screenshot service webfetch's own screenshot parameter falls back to. More on the about page.

Email [email protected] with the target host, timestamps with a timezone, and a sample of the requests. We act against the responsible key, and you can ask to have your domain refused for every customer rather than just the one that hit you.