ScreenshotNeo

BlogGuides

How Web Scraping API Pricing and Costs Are Calculated

Learn how scraping APIs meter requests, rendering, proxies and retries, then estimate monthly cost per successful usable result.

By the ScreenshotNeo team1 October 20268 min read

Web scraping API cost is usually a metered unit multiplied by usage, plus charges for the resources needed to obtain each result. That unit may be a successful response, API credit, extracted record or bandwidth amount. JavaScript rendering, residential proxies, geographic targeting, anti-bot work, extraction and large responses can add to the bill.

To estimate your real spend, calculate cost per successful usable result, not only cost per attempted request. Model at least three workloads: mostly static pages, a mixed workload and difficult JavaScript or anti-bot pages.

What does a web scraping API charge for?

Every provider defines its own meter. “Per request” is not a universal pricing unit.

Billing unit What it measures Question to ask
Successful response A page returned successfully Are rate limits, timeouts and blocked responses free?
API credit A variable number of credits consumed by each request How many credits does a browser or anti-bot request use?
Extracted record Rows or items returned by an extraction job Is the page fetch bundled with record pricing?
Bandwidth Data transferred through a proxy or API Are response bodies, assets and proxy traffic metered separately?
Subscription quota A monthly allowance of calls, credits or records What happens when the quota is exhausted?

Bright Data’s Web Scraper API, for example, describes record pricing alongside residential proxy bandwidth, JavaScript rendering, automated proxy management and validation. ScraperAPI uses credits, and its documentation notes that anti-bot protection consumes a resource-intensive bypass mechanism that increases the cost per scrape. These models cannot be compared fairly until you know the provider’s exact unit.

The cost components behind one scrape

Base request or page charge

A simple HTTP fetch is generally the least expensive operation. The API sends a request, receives the response body and returns it to you. Prices may vary by target difficulty or request tier.

Zyte publishes example prices of $0.13, $0.23, $0.44, $0.70 and $1.27 per 1,000 HTTP response-body requests for its Simple through Advanced tiers (Zyte, 2026). Use provider-specific figures as examples rather than an industry average.

Browser rendering

When a page needs JavaScript execution, the service must start or allocate a browser, load scripts, wait for rendering and often perform additional network work. Zyte’s published browser-rendered examples are $1.01, $2.01, $4.02, $8.04 and $16.08 per 1,000 requests (Zyte, 2026).

Use browser rendering only for pages that require it. A static endpoint, server-rendered HTML or an API response usually costs less and completes faster.

Proxy type and geography

Datacenter, residential and mobile proxies have different infrastructure costs. A residential IP or an extended geographic location can add a surcharge. Geographic targeting can also affect success rate, latency and retry volume.

Anti-bot and CAPTCHA handling

Protected targets may require fingerprint management, browser actions, challenge handling or a more expensive bypass route. A low nominal request price can become expensive if many attempts fail and your system retries them.

Extraction, screenshots and network captures

Automatic extraction, custom attributes, screenshots, actions and network captures are commonly priced as add-on features or higher request tiers. Confirm whether each feature is included in the base call or consumes additional credits.

Response size and bandwidth

Large HTML documents, embedded data and downloaded assets can increase bandwidth charges. If you need only selected fields, prefer extraction or a response mode that avoids transferring unnecessary content.

A practical monthly cost formula

Use this model for a first estimate:

monthly cost =
  (successful pages × base unit price)
  + rendering surcharge
  + proxy/geolocation surcharge
  + extraction or screenshot charges
  + bandwidth charges
  + retry and failed-attempt costs
  + subscription or minimum commitment

Define each variable using your provider’s pricing page. If the provider meters credits, convert every request type into credits before multiplying by volume.

Worked scenario

Suppose you fetch 100,000 pages per month:

  • 60,000 static pages
  • 30,000 JavaScript-rendered pages
  • 10,000 protected pages using residential or geographic routing
  • 5% additional attempts caused by retries

Do not multiply 100,000 by one headline price. Assign a unit price to each segment, add the 5,000 retry attempts according to their actual request type, then include bandwidth and extraction charges. Your result is a range until you measure the page mix and success rate.

How to estimate cost with your own data

  1. Inventory request types. Group URLs into static, JavaScript, geographic, residential and protected categories.
  2. Record the billing unit. Store requests, credits, records, transferred bytes and successful usable results separately.
  3. Measure retries. Count the original attempt and every retry. Record the error class that caused it.
  4. Track response quality. A 200 response containing a block page is not a usable result.
  5. Run three scenarios. Model mostly static, mixed and mostly JavaScript or anti-bot traffic.
  6. Recalculate after a sample. A representative sample of URLs is more reliable than a provider’s cheapest advertised tier.
# Minimal cost worksheet
pages = 100000
static_share = 0.60
browser_share = 0.30
protected_share = 0.10
retry_rate = 0.05

static_pages = pages * static_share
browser_pages = pages * browser_share
protected_pages = pages * protected_share
retry_attempts = pages * retry_rate

# Replace these with your provider's units or prices.
static_unit = 0.00013       # example: $0.13 per 1,000
browser_unit = 0.00101      # example: $1.01 per 1,000
protected_unit = 0.0        # measure separately

estimated = (
    static_pages * static_unit
    + browser_pages * browser_unit
    + retry_attempts * static_unit
)
print(f"Estimated base cost: ${estimated:.2f}")

The figures in this worksheet are illustrative conversions of Zyte’s published examples, not a quote for your workload. Replace them with current provider rates before making a budget.

Do failed requests consume credits?

There is no universal answer. Zyte states that only successful responses are charged and that rate-limiting and unsuccessful responses are free. Other providers may consume credits for every request, including a failed or blocked attempt. Read the provider’s definition of “successful,” especially for timeouts, CAPTCHA pages, empty results and HTTP errors.

Log these fields for every call:

  • HTTP status and provider error code
  • Whether the response contained usable data
  • Credits or units consumed
  • Proxy class and geographic route
  • Browser-rendering and extraction flags
  • Retry count and final outcome

Cost per successful result

Compare providers with this metric:

cost per usable result = total provider charges / usable results

A service charging $1 per 1,000 attempts is not cheaper than one charging $2 per 1,000 attempts if the first returns half as many usable pages and requires repeated retries. Include engineering time when a provider requires custom browser orchestration, proxy rotation or challenge handling.

Performance and reliability trade-offs

Choice Typical effect Use it when
HTTP fetch Lowest latency and resource use The content is server-rendered and lightly protected
Headless browser Higher latency and cost JavaScript is required to produce the data
Datacenter proxy Lower proxy cost, variable blocking risk The target accepts datacenter traffic
Residential or mobile proxy Higher cost and often slower Target access depends on residential reputation
Wide concurrency Higher throughput, possible rate limits The target and provider quotas allow it

Set concurrency from provider limits and target behavior. Excessive parallelism can trigger rate limits, increase retries and raise total cost. Cache stable pages, use conditional refresh policies where supported and avoid rendering assets you do not need.

Common pricing mistakes

  • Comparing different units: a record price, page price and credit price are not interchangeable.
  • Ignoring browser share: a small percentage of rendered pages can dominate spend.
  • Ignoring proxy geography: residential and extended-location traffic may have separate rates.
  • Counting HTTP 200 as success: a block page can be a successful transport response but a failed scrape.
  • Forgetting retries: timeout and challenge retries can exceed the original workload.
  • Budgeting from a headline tier: add-ons, minimum commitments and overage rates may change the total.
  • Using old prices: provider prices and affiliate terms change; recheck them before publication or purchase.

Troubleshooting a cost estimate

The invoice is higher than the request count

Check whether the provider meters credits, records, bandwidth or retries. Break the invoice down by request type and compare it with your logs.

Browser jobs consume more credits than expected

Confirm whether rendering, actions, screenshots, network captures or extraction are separate chargeable features. Remove browser mode from pages that work with HTTP.

Most calls return data but usable-result cost is high

Inspect blocked pages, empty records and stale content. Improve URL classification, reduce retries and measure success by validation rules rather than status code alone.

Geographic requests are slow and expensive

Separate geographic traffic from the rest of the workload. Use the narrowest required location and test whether a datacenter route meets the target’s access requirements.

Costs spike after a target changes

A site redesign may introduce JavaScript rendering, larger responses or stronger bot controls. Reclassify the affected URLs and update the scenario model.

Or skip the browser setup

When your requirement is a clean screenshot rather than extracted records, ScreenshotNeo provides a single GET request for PNG, JPEG, WebP or PDF output. Its cost model is straightforward: only clean shots are billed; bot checks or CAPTCHAs, blank pages, timeouts, failed loads and cache hits cost nothing, and each response identifies the result with X-Page-Verdict and X-Billed headers.

ScreenshotNeo removes cookie and consent banners, newsletter popups and chat widgets before capture. Its MCP server gives Claude, Cursor and other MCP clients the take_screenshot, get_page_info and capture_pdf tools. Plans include 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000 shots.

See the ScreenshotNeo API documentation for the available options.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp
import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

Create a free ScreenshotNeo account to get 1,000 screenshots each month with no card.

ScreenshotNeo options that affect planning

ScreenshotNeo includes full-page capture with lazy images loaded, CSS-selector element capture, dark mode, 12 device presets, custom viewports, retina scale, PDF paper sizes and page ranges, custom CSS and JavaScript, click actions, hide selectors, selector or network-idle waits, request and resource blocking, custom headers and cookies, user-agent and Authorization values, timezone and geolocation, transparent backgrounds, image resizing, chosen cache TTLs, signed links, asynchronous jobs with signed webhooks, bulk capture for up to 100 URLs per call and a usage API.

FAQ

Is a cheaper per-request price always better?

No. Compare cost per successful usable result after retries, rendering, proxy and extraction charges.

When should I use browser rendering?

Use it when JavaScript is necessary to produce the content. Keep static pages on a simple HTTP path.

How should I budget for protected websites?

Run a representative sample, measure success rate and retry rate, and price residential or geographic traffic separately.

Are scraping API prices stable?

No. Provider rates, quotas and affiliate terms can change. Recheck current documentation before committing to a budget.

What should I monitor in production?

Track units consumed, usable results, response size, browser share, proxy class, geographic route, retries and cost per usable result.

Checklist for comparing providers

  • What exactly is the billing unit?
  • Are unsuccessful attempts free?
  • How are browser-rendered requests priced?
  • What do residential, mobile and geographic routes cost?
  • Do anti-bot features consume extra credits?
  • Are extraction, screenshots and network captures add-ons?
  • Is bandwidth included?
  • What are concurrency, rate limits and overage rules?
  • Is there a minimum commitment or volume discount?
  • Can the provider expose per-request usage and verdict data?