Scrapfly is a scraping API with an unusually explicit cost model: proxies, headless browsers, anti-bot bypass and geo-targeting, all metered in credits whose price per request depends on what you turned on.
What it costs
| Plan | Price/month | Credits | Per 1,000 (floor) |
|---|---|---|---|
| Free | $0 | 1,000 | — |
| Discovery | $30 | 200,000 | $0.150 |
| Pro | $100 | 1,000,000 | $0.100 |
| Startup | $250 | 2,500,000 | $0.100 |
| Enterprise | $500 | 5,500,000 | $0.091 |
| Custom | $1,200–$30,000+ | negotiated | — |
⚠️ The per-1,000 column above is a floor, not a price
From their own documentation: "Scrapfly bills in API credits", and the credits a single request consumes vary with the features it uses — JavaScript rendering, proxy type, and targeting options.
So "200,000 credits" is not 200,000 requests. It is 200,000 credits, and a request costs somewhere between one and many depending on how hard the target is. A plain HTML fetch and a JS-rendered fetch through a residential proxy in a specific country are the same API, the same plan, and very different prices.
Social platforms sit at the expensive end of that range: they need JavaScript rendering, and they are aggressive about blocking datacentre IPs, which pushes you toward the residential proxy tier.
This is the same structural point as Oxylabs, where the multiplier is published per target site, and Xpoz, where it is published per platform. Three of the fourteen competitors in this family have a multiplier inside the plan, and a comparison table showing only plan prices is wrong for all three in the same direction: it flatters them.
We publish the floor and label it as a floor. Nobody can publish the real number without knowing your request mix — including them, which is why they documented the mechanism instead of a price.
What a credit does not buy
The page, not the field. Same trade as ScrapingBee and ScraperAPI: you get HTML and own the parsing, eleven times over if you want eleven platforms in one shape.
Who it's for
Scrapfly is strong when the target is hard — anti-bot defences, aggressive blocking, geo-restricted content. The cost model is explicit about charging more for difficulty, which is more honest than a flat rate that quietly fails on hard targets.
It is the wrong purchase if you want structured social metrics, and the wrong purchase if you need to forecast a bill precisely, because the unit moves with your configuration.
Where it is better than us
Hard targets. Anti-bot bypass is their specialty and not something we sell.
Transparency about the multiplier. They documented that credits vary by feature. All three competitors with a multiplier published the mechanism themselves — this category is, to its credit, mostly honest about this.
Any URL. Eleven platforms against the web.
The legal part
General scraper, so the target choice and the compliance question are the buyer's. Not better or worse than our model — a different place for the same question.
We publish where we think the line is and a removal route.
Who measured this
We did, we compete in this category, and the number to distrust is our own per-1,000 column — not because the division is wrong, but because the denominator is not a request.
What we run is an hourly archive of what's rising. What we sell is parsed JSON in one shape, billed per call with a per-endpoint cost owned by one database row — so the cost of a request does not change with how you configured it.
Plan prices and credit counts read from scrapfly.io/pricing on 2 October 2026 — primary source, read directly from the page. The statement that credits vary by feature (JavaScript rendering, proxy type, targeting) is theirs, from the same source. The per-1,000 column is our arithmetic and is a floor, because a request can consume more than one credit. Verify before deciding.