Compare scraping APIs by cost per delivered 1,000 usable records, not by the advertised per-request price. That single unit exposes what headline pricing hides: failure rates, retries, JavaScript rendering multipliers, and proxy premiums that can push effective cost well past the number on the pricing page.
Here's the fast version before we get into the math:
- Pay-as-you-go (PAYG) fits spiky, unpredictable workloads where you don't want to pay for idle capacity.
- Subscription credits work when your volume is steady enough to forecast, but they can waste money on bursty jobs.
- Self-hosted / DIY only pays off once you have real scale and an ops team to keep proxies and headless browsers running.
- Hidden cost drivers to watch: rendering multipliers, premium or residential proxy fees, and whether failed requests still burn credits.
Key Takeaways
Delivered cost, not the advertised per-request price, determines which scraping API is actually cheapest for your specific workload and failure profile.
| Point | Details |
|---|---|
| Use delivered cost as the unit | Divide total spend by successful records and multiply by 1,000 to compare providers fairly. |
| Match model to workload shape | PAYG suits bursty traffic, subscriptions suit steady volume, self-hosting suits high predictable scale with in-house ops. |
| Multipliers drive the real bill | Rendering, premium proxies, and stealth modes can multiply effective cost several times over the base rate. |
| Ask about failure billing upfront | Confirm whether 403s, timeouts, and CAPTCHAs consume credits before signing a contract. |
| Gyrence reduces billing surprises | Typed failure responses and workspace spending caps let teams measure delivered cost accurately without guesswork. |
Table of Contents
- Web Scraping API Pricing Models Compared
- What Is Cost per Delivered Record, and Why Does It Matter More Than Price per Request?
- How Do JavaScript Rendering and Proxy Tiers Multiply Your Bill?
- Is Self-Hosted Scraping Cheaper Than a Managed API?
- What Should You Ask a Scraping API Vendor Before You Buy?
- How Do You Test Delivered Cost Before Committing to a Plan?
- How Gyrence Keeps Delivered-Cost Math From Becoming Guesswork
- Does Where Your Target Sites Are Hosted Change Your Scraping Bill?
- Do Scraping APIs Get Cheaper at Higher Volume?
- How Does Data Freshness Affect Scraping API Pricing?
- What Does Scraping Actually Cost at Different Volumes?
- Picking the Right Plan Shape for Your Team
- Try Gyrence for Predictable Scraping API Pricing
- Sources
- FAQ
Web Scraping API Pricing Models Compared
Every vendor pricing page reduces to one of three billing shapes, and picking the wrong one is the most common way teams overspend.
Pay-as-you-go bills per request or per credit consumed, with no monthly floor. There's no commitment, so it suits workloads that spike unpredictably: a lead-gen tool that scrapes 500 pages one week and 50,000 the next. The tradeoff is that per-unit pricing on PAYG tends to run higher than the per-unit rate inside a subscription tier, because you're not prepaying for volume.
Subscription credit plans sell a monthly allowance, typically with tiers that step up in price as the credit pool grows. Market pricing guides put entry-level plans around $29 to $99 a month, scaling to $699 to $999 or more for higher-volume tiers. These plans make budgeting predictable, but unused credits usually don't roll over, and a workload that swings from 10,000 to 200,000 requests month to month will either overpay in slow months or blow through the cap in busy ones. Free tiers exist on most platforms, but they cap request volume and often deprioritize your jobs in the queue, so treat them as a trial, not a production plan.
Self-hosted scraping replaces per-request billing with capitalized infrastructure: compute instances, proxy bandwidth, and the engineering hours to keep parsers alive when target sites change their markup.
Here's how to choose in practice:
- Unpredictable, bursty traffic → PAYG, because you only pay for what you use when you use it.
- Stable, forecastable monthly volume → subscription credits, provided you've tested the multipliers that apply to your actual targets.
- Very high, sustained volume with an existing ops team → self-hosted, since the fixed costs finally get amortized enough to beat metered pricing.
What Is Cost per Delivered Record, and Why Does It Matter More Than Price per Request?
The number that actually predicts your bill is the delivered-cost formula:
delivered_cost = total_spend ÷ successful_records × 1,000
total_spend is everything you paid, including retries and rendering surcharges. successful_records is the count of results you could actually parse and use, not the number of requests you fired. That gap between "requests sent" and "records usable" is where advertised pricing quietly falls apart, and it's the core comparison unit vendors rarely publish themselves.
That gap widens fast once you add retry multipliers, JavaScript rendering surcharges, or residential proxy premiums on top of the base failure rate, since each of those stacks on the denominator or the numerator independently. A parsing failure, where the page loads fine but the extraction schema returns nothing usable, does the same damage as an outright 403: it still counts against successful_records even though you were billed for the request.
How Do JavaScript Rendering and Proxy Tiers Multiply Your Bill?
Rendering and proxy choice are the two biggest levers on effective price, and vendor documentation is often vague about exactly where they apply.
- Plain HTTP requests against static HTML typically bill at the base rate, call it 1×.
- Headless browser rendering for JavaScript-heavy pages commonly runs 5× the base credit cost.
- Premium or datacenter-rotating proxies add another multiplier, often around 10×.
- Stealth modes built to beat aggressive bot detection can stack multipliers as high as 75× a plain request in vendor credit tables.
Session-based billing changes the math again. If a job needs to log in, hold cookies, and paginate through a dozen pages, some providers bill that as one session rather than per page. Session billing frequently beats per-page billing for exactly those login-and-paginate jobs, though it can round up on short jobs that finish in under a minute.
Before committing to a plan, run this checklist:
- Test whether your target actually needs rendering; plenty of "modern" sites still serve full HTML without JavaScript.
- Split your target list by rendering requirement and route each group to the cheapest mode that works.
- Confirm whether proxy tier is automatic or something you control per request.
Pro Tip: Run the same 100-URL sample through both a plain-HTTP call and a rendered call before committing to a plan. The delta tells you your real multiplier exposure faster than any pricing page.
Is Self-Hosted Scraping Cheaper Than a Managed API?
Rarely, once you count every line item honestly. The sticker price of running your own scraper looks cheap until you total compute, bandwidth, and the engineering hours spent fixing broken selectors.
A mid-size self-hosted setup running headless Chrome at scale needs a compute instance in the range of an AWS c5.4xlarge, priced around $490 a month, plus residential proxy bandwidth that can add a comparable amount depending on volume, plus the recurring cost of a developer patching parsers every time a target site redesigns its markup.
| Cost component | Small workload (~50k records/mo) | Large workload (~2M records/mo) |
|---|---|---|
| DIY compute + proxies | Modest instance, low proxy spend | Multiple instances, heavy proxy bandwidth |
| DIY engineering time | A few hours monthly on fixes | Near full-time maintenance role |
| Managed API | Metered per-record billing | Volume-tier subscription pricing |
The non-monetary trade-offs matter as much as the dollar figures. DIY scraping means you own every outage, every CAPTCHA wall, and every schema change. A managed API shifts that operational risk into a predictable variable cost, which is the real trade you're making, not just the invoice total.
What Should You Ask a Scraping API Vendor Before You Buy?
Ask these questions in every trial or RFP, and treat vague or evasive answers as a red flag:
- Do 403s, timeouts, or CAPTCHA pages consume credits, or only fully successful responses?
- Are internal retries billed separately, and can you see retry counts in your usage logs?
- What's the exact multiplier for JavaScript rendering and for premium or residential proxies, in writing, not a sales call estimate?
- Are refunds available for failed runs, and can you export per-request billing data to audit it yourself?
Vendors that dodge the 403-and-CAPTCHA question specifically tend to be the ones where your effective cost per delivered record runs highest, because that's exactly where hidden credit burn hides.
How Do You Test Delivered Cost Before Committing to a Plan?
Here's a pseudocode version of the formula you can drop into a spreadsheet or a quick script:
delivered_cost = (requests * price_per_1k / 1000)
- (1 + retry_multiplier)
- (js_multiplier if rendering_needed else 1) / (requests * (1 - failure_rate) * (0 if refund_failures else 1 + failure_rate_adjustment))
This single expression is the difference between a plan that looks cheap on a pricing page and one that's actually cheap on your invoice.
To test it for real:
- Pick 100 to 200 representative URLs from your actual target list, not a vendor's demo set.
- Run the same sample through two providers in parallel and classify every response as success, soft failure, or hard block.
- Plug the results into the formula above and compare cost per 1,000 delivered records, not the advertised rate card.
Static pages with no bot protection will show almost identical costs across providers. Bot-protected job boards or e-commerce sites will show wide gaps, since that's exactly where retry and stealth multipliers kick in.
How Gyrence Keeps Delivered-Cost Math From Becoming Guesswork
Gyrence's five primitives, Search, Traverse, Fetch, Extract, and Map, plus a hosted MCP endpoint, exist because most billing surprises come from vendors that hide what actually happened on a failed call.
- Every call returns a typed, discriminated-union response, including failure cases, so you can classify successes and failures programmatically instead of guessing from logs.
- Spending caps at the workspace level stop a runaway crawl from producing a surprise invoice.
- Extract runs schema-guided, LLM-powered parsing with no separate AI extraction charge, which removes one common source of hidden multiplier math.
- Content-type-aware routing avoids paying a rendering premium on pages that never needed it.
Technical details on request/response shapes and billing behavior live in the Gyrence documentation, which is worth reading before you run your own delivered-cost comparison.
Does Where Your Target Sites Are Hosted Change Your Scraping Bill?
Geography affects cost in ways that rarely show up on a pricing page's headline numbers. Scraping targets hosted or geofenced in regions far from your provider's proxy infrastructure often need premium proxy routing to appear as a local visitor, and that routing usually carries its own multiplier on top of the base rate.
Sites that geoblock by country or serve region-specific content, retail platforms, ticketing sites, local news, force you into residential or mobile proxies rather than cheaper datacenter IPs, since a datacenter IP from the wrong region gets blocked or served a stripped-down version of the page. Residential proxy bandwidth in regions with less proxy-network density, parts of Southeast Asia and Africa, for example, tends to cost more per gigabyte than bandwidth in the United States or Western Europe, simply because there's less residential IP supply for providers to route through.
There's also a latency cost that shows up as failure rate rather than a line item. Requests routed through distant proxy pools time out more often, and every timeout either burns a credit outright or triggers a retry that burns two. If your target list skews international, budget extra headroom in your failure-rate assumption before you run the delivered-cost formula, rather than assuming the domestic failure rate you tested with will hold everywhere.
Do Scraping APIs Get Cheaper at Higher Volume?
Almost every vendor pricing page includes volume discounts, but the mechanics matter more than the discount percentage itself.
Subscription tiers step down the per-unit price as the credit pool grows, which is why entry plans in the $29 to $99 range carry a noticeably higher per-record cost than the $699 to $999-plus tiers built for high-volume customers. That's standard SaaS tiering economics: fixed platform costs get spread across more usage.
The catch is that bulk discounts assume you'll actually use the volume you're paying for. A subscription tier priced for 5 million monthly requests only beats PAYG if you consistently hit something close to that number; fall short regularly and you're paying for headroom you never use. Before upgrading a tier for the bulk discount, check your last three months of actual usage, not your projected usage, against the tier's included volume.
Platform operators running enterprise-scale jobs typically negotiate custom terms outside the published tiers entirely, including per-target service-level agreements and dedicated proxy pools. That negotiation only makes sense once volume is large and predictable enough to justify a sales conversation instead of a self-serve signup.
How Does Data Freshness Affect Scraping API Pricing?
Real-time or near-real-time monitoring costs more than batch scraping, and the reason is architectural, not arbitrary markup. A job that checks a page once a day can run on a shared queue with relaxed timing. A job that needs to catch a price change within minutes needs dedicated polling infrastructure, faster retry logic, and often webhook delivery, all of which cost the provider more to run and get passed through in pricing.
Monitoring-style products, the kind that watch a set of URLs continuously and alert on change, typically bill differently from one-off extraction: either a per-monitor subscription fee layered on top of request costs, or a premium credit rate for high-frequency polling tiers. If your use case is "check this competitor's pricing page every 15 minutes," expect a materially higher bill than "scrape this page once a week," even though the per-request mechanics look identical on paper.
The practical move is matching polling frequency to actual business need rather than defaulting to the tightest interval available. Checking a job board every hour instead of every five minutes can cut monitoring costs sharply without missing anything that matters, since job postings don't update at the pace ticket inventory does. Map your freshness requirement to the actual decision it feeds before picking an interval.
What Does Scraping Actually Cost at Different Volumes?
Three volume bands cover most real projects, and each one changes which pricing model wins.
A solo developer building a price-monitoring side project might scrape 20,000 to 50,000 pages a month against a handful of e-commerce sites. At that volume, PAYG or a free tier usually covers it, and the entry-tier subscription plans in the $29 to $99 range are overkill unless rendering multipliers push effective usage higher than the raw page count suggests.
A small data team running lead enrichment across 500,000 to 2 million records a month sits squarely in mid-tier subscription territory. This is where the delivered-cost formula earns its keep: two providers advertising similar headline rates can differ by 30% or more in real cost once you factor in each one's failure rate and rendering multiplier on your actual target mix.
A platform operator ingesting web data for an AI agent product at 10 million-plus requests a month is the scenario where self-hosting starts to pencil out, but only if the target sites are stable enough that engineering maintenance stays low. Volatile targets, sites that change markup often or add bot protection, tend to keep the managed-API math favorable even at high volume, because the maintenance cost of DIY scales with target fragility, not just request count.
Picking the Right Plan Shape for Your Team
Solo developers should start on a free tier or PAYG and actually measure delivered cost before assuming they need more. Most side projects never hit the volume where subscription credits pay off.
Small teams with steady, forecastable workloads can make real budget sense of subscription credits, but only after testing which multipliers apply to their specific targets. A stable-looking workload can still surprise you if half your URLs need rendering.
Platform operators at real scale should negotiate enterprise terms directly, with per-target SLAs written into the contract rather than assumed from a pricing page.
Try Gyrence for Predictable Scraping API Pricing
Gyrence gives you a fixed cost per call instead of a bill that swings with hidden rendering surcharges and retry counts you can't see until the invoice arrives.
The five composable primitives, Search, Traverse, Fetch, Extract, and Map, along with the hosted MCP endpoint, mean you can build exactly the pipeline you need without paying for capability you don't use, and every response comes back typed so you know immediately whether a call succeeded, failed, or needs a retry. Extract's schema-guided LLM parsing carries no separate AI charge, which removes one of the multiplier surprises this article walked through. Workspace-level spending caps mean a misconfigured crawl can't quietly rack up a five-figure invoice overnight.
If you're evaluating providers using the delivered-cost formula above, run your test sample through the Gyrence console and compare the number you get against your current provider's invoice. You can also review request and response schemas in the Gyrence docs before you commit any URLs to a trial, or start with the single-API approach to web data access if you're building an ingestion pipeline from scratch.
Sources
- Compare Scraping APIs by Cost per Delivered Record, Not Request Price - DEV Community
- Scraping API Credits: 1 Request Can Cost 75 | HProxy
- Tendem
FAQ
How much does it cost to scrape APIs?
Entry-level plans commonly start around $29 to $99 a month, scaling to $699 to $999 or more for high-volume tiers, but actual cost depends heavily on failure rate and rendering multipliers on your specific targets.
Is web scraping illegal in the US?
Scraping publicly accessible data is generally permitted, but legality depends on what you scrape, how you access it, and whether you violate a site's terms of service; consult a legal professional for guidance specific to your use case.
Is there a free API for web scraping?
Most providers, including Gyrence, offer a free tier or trial credits, but free tiers typically cap request volume and may deprioritize queued jobs, so treat them as evaluation tools rather than production infrastructure.
Are scraping APIs legal?
Scraping APIs themselves are legal tools; the legality question applies to how you use them against specific target sites, their terms of service, and applicable data protection law in your jurisdiction.
Why does cost per request understate real scraping costs?
Per-request pricing ignores failed calls that still consume credits, retry attempts, and rendering multipliers, which is why cost per delivered 1,000 records gives a more accurate comparison across providers.