Scrape.do vs ScraperAPI — Tested Head-to-Head
Last updated: November 2, 2026 · Data snapshot: November 2, 2026 (trailing 30-day window) · Weekly refresh
Table 1 — Head-to-head (same targets, same day, same run origin)
Success = HTTP 200 AND validator substring present. Est. $/1k successful = claimed list price per 1k ÷ measured success rate. Cloudflare-target column: median latency on the protected page (success count in parentheses).
| Provider | Success rate | Median latency | p95 | Cloudflare-target median | Est. $/1k successful | Claimed entry pricing |
|---|---|---|---|---|---|---|
| Scrape.do | 100% | 2642ms | 9960ms | 9867ms (3/3) | $0.11 | 1,000 free successful calls; Hobby $29/mo ≈ $0.11/1k; Business $249/mo ≈ $0.07/1k |
| ScraperAPI | 100% | 2111ms | 5923ms | 3807ms (3/3) | $0.49 | $49/mo for ~100k credits (claimed) |
Table 2 — Real product pages, repeated 3 days (2026-10-23, 2026-10-24, 2026-10-25)
Same 6 requests per target per day, 3-day repeat, success = HTTP 200 AND product-content validator (product name/price element present). Declared cost = vendor-published credit rules (multipliers not invoice-verified).
| Provider | Real target | Success (3d) | Day medians (ms) | 3d median | Declared cost (3d) |
|---|---|---|---|---|---|
| Baseline (no scraper API) | 商品列表页 · static | 18/18 | 506.5 / 521.5 / 587 | 521.5ms | — (direct) |
| Baseline (no scraper API) | 商品详情页 · static | 18/18 | 260 / 273.5 / 664.5 | 273.5ms | — (direct) |
| Baseline (no scraper API) | 真实电商详情页 · JS-render | 0/18 | — / — / — | — | — (direct) |
| ScraperAPI | 商品列表页 · static | 18/18 | 2471 / 2682 / 2316 | 2471ms | $2.38 (486 cr) |
| ScraperAPI | 商品详情页 · static | 18/18 | 3134.5 / 1274.5 / 1544.5 | 1544.5ms | $2.38 (486 cr) |
| ScraperAPI | 真实电商详情页 · JS-render | 0/18 | — / — / — | — | $2.38 (486 cr) |
| Scrape.do | 商品列表页 · static | 18/18 | 957 / 2488 / 2549 | 2488ms | $0.0060 (54 cr) |
| Scrape.do | 商品详情页 · static | 18/18 | 2106 / 1109 / 1390.5 | 1390.5ms | $0.0060 (54 cr) |
| Scrape.do | 真实电商详情页 · JS-render | 0/18 | — / — / — | — | $0.0060 (54 cr) |
Key findings
- Across 36 validator-checked requests on the same targets (including a Cloudflare-protected page), ScraperAPI posted the lowest median latency at 2111ms.
- On our honest cost metric — claimed list price per 1k ÷ measured success rate — Scrape.do is cheapest at $0.11 per 1k successful responses. Pricing claims vary wildly in structure (credits, tiers, GB); the per-successful-request view is the only one we consider comparable.
- On the Cloudflare-protected target specifically, ScraperAPI resolved in a median of 3807ms vs 9867ms for Scrape.do — and all tested providers fetched the protected page successfully in every attempt.
- Caveats we won't hide: single day, tiny volume (18 requests per provider), one run origin, and claimed pricing parsed from vendor pages. Treat this as a spot-check of advertised capability, not a load test — we re-run weekly and trends will earn their own page.
Frequently asked questions
Is Scrape.do cheaper than ScraperAPI?
On our honest cost metric (claimed list price per 1k requests ÷ measured success rate): $0.11 vs $0.49 per 1k successful responses in the 2026-10-26 run. Both delivered Scrape.do 100% / ScraperAPI 100% success on the same targets, so on this target set the price gap is the story. Pricing structures differ (credits vs flat per-request) — always recompute against your own success rate.
Can Scrape.do and ScraperAPI bypass Cloudflare?
On our Cloudflare-protected demo target, every provider returned validated content on every attempt (3/3, 3/3), with medians of Scrape.do 9867ms / ScraperAPI 3807ms. Caveat: this is one lightly-protected demo page, not a hardened production site — a real deployment behind Cloudflare Bot Management can behave very differently.
Does an HTTP 200 response count as success here?
No. Success requires the validator substring to be present — the page must contain the expected content. A 200 that returns a block/interstitial page counts as a failure in every number on this page. This is why our success rates can differ from vendor dashboards that count HTTP status only.
How small is this test and why should I trust it?
36 validator-checked requests total (18 per provider), one run origin, one day, same targets for everyone including a direct-connection baseline in the raw data. It is a spot-check of advertised capability — not a load test. We publish the harness targets, validators, and raw JSON, and re-run weekly; judge the method, then the numbers.
Can they scrape a real e-commerce product page (JD.com item page)?
Not in our 3-day test: 0/54 validated successes across every provider and every day, including the direct baseline. The dominant failure is not a blocked status code — the page answers HTTP 200 and the product DOM simply never arrives in the rendered output. "Passes the shield" and "returns the content you wanted" are different claims; always pilot against your target before committing volume.
Do you pay for failed JS-render requests?
On declared pricing rules: yes for ScraperAPI, and the multiplier hurts — its JS render costs 25 credits, so 3 failed days on one JD item page burned 486 credits ≈ $2.38 declared for zero successful product pages. The same failures on Scrape.do's flat per-request pricing cost $0.0060 (render is the same price). We have not verified either against an invoice — read your plan's failure-billing terms before scaling renders.
How we measure
Cohort: Actors scanned from the public Apify Store API (popularity-sorted top 5,106, 3,898 scraping-related matches) on 2026-11-02. For each Actor we take publicActorRunStats30Days: TOTAL, SUCCEEDED, FAILED, ABORTED, TIMED-OUT over the trailing 30 days. Failure rate = FAILED / TOTAL — a run the user cancelled (ABORTED) or that exceeded its timeout budget (TIMED-OUT) is not counted as a failure; both are small relative to TOTAL in this cohort.
Bench harness: fixed 4-target set (static / static / regular site / Cloudflare-protected demo page), 18 requests per provider per run, serial with 1s gaps, run from our network (the no-key baseline in the raw data reflects local conditions; commercial APIs fetch from their own infrastructure). Success requires the validator substring — a 200 with a block page counts as a failure. Raw JSON: site snapshot; harness code ships with the repo.
Scenario harness (Table 2): two static product pages (books.toscrape catalog + detail) and one JS-heavy real e-commerce product page (JD.com item), 6 requests per target per day on 3 consecutive days, 30s timeout + 1 retry, runs from the same origin. JS targets built with each provider's render mode (ScraperAPI: render=true, 25 credits; Scrape.do: render=true, same price). The no-key baseline fetches directly (no JS rendering) — it is there to show what the target returns to a plain client, not to compete.
Failures have many causes (bad input, target changes, platform incidents) — a high failure rate is a signal, not a verdict. Display threshold for tables is ~500 runs/30d; ranking threshold is 1,000 runs/30d — entries between the two appear in tables but not in ranked statements. License: CC BY 4.0 — cite TopScraper with the data snapshot date.
Conclusion
Claimed pricing pages are marketing; this table is a measurement — small, but repeatable, and we repeat it weekly. When a provider's dashboard shows 100% everywhere, the differences that matter move to latency and cost per successful request: at 2 providers we can already rank both.
The 3-day scenario repeat (Table 2) adds the part single-day benchmarks hide: what a provider does when a real target fights back — and what that costs you per failed attempt.
Next: more providers enter the harness as we register them; per-provider detail pages carry the full per-target breakdowns and the methodology note.