Scraping API Pricing: How Credit Multipliers Set Real Cost

A credit is a private currency. Each vendor decides what one credit buys, so "250,000 credits for $49" on one API and "250,000 credits for $49" on another can represent very different amounts of scraping.

Three things differ between vendors even when plan prices look identical:

• What a feature costs in credits. Rendering is 5 credits on some APIs and 10 on others.
• What the default is. If rendering is on unless you turn it off, every request you forget to configure costs the rendered rate.
• What gets billed. Some vendors count 404 responses as successful, some add surcharges for specific domains, and none of them can know whether the 200 page they returned is a challenge screen your parser cannot use.

So comparing price per credit tells you very little. Compare price per usable record on your own URL mix.

Figures below come from each vendor's own documentation or pricing page as of September 2026. They change, so check the vendor's current docs before relying on them.

Sources: sparkproxy.io/docs/scraping-api, scrapingbee.com documentation and pricing, docs.scraperapi.com credits and request costs, docs.zenrows.com pricing.

Two readings stand out. First, the core ladder of 1, 5, 10 and 25 is close to an industry convention, so the big differences are at the edges: the top anti-bot tier, geo pricing and domain surcharges. Second, ScraperAPI's domain surcharges mean a Google results page costs 25 credits before you add any parameter. If your workload is mostly search pages, that one row decides the comparison.

SparkProxy also charges +5 each for a JavaScript scenario (clicks, scrolling, form fills) and for screenshot or PDF output, so a rendered screenshot costs 10.

Everything in this guide reduces to one expression, applied separately to each class of URL you scrape:

Cost per usable record = (credits per request x price per credit x requests per record) / usable rate

• Credits per request is the base cost plus every multiplier and add-on you enable. Rendering, premium routing, country targeting and domain surcharges all land here.
• Price per credit is plan price divided by plan credits. On SparkProxy's published plans that is $49 / 250,000 = $0.196 per 1,000 credits on Starter, $0.099 on Growth ($99 / 1,000,000), $0.083 on Pro ($249 / 3,000,000) and $0.075 on Scale ($599 / 8,000,000).
• Requests per record is how many fetches produce one output row. A product that needs a listing page, a detail page and a reviews page is 3, not 1.
• Usable rate is the fraction of billed responses your parser can actually use. A 200 response containing a challenge page is billed and useless.

The formula looks obvious written down. It is rarely used, because most estimates skip the last two terms, and those are the two that are hardest to learn from a pricing page.

The most expensive credit line is usually one nobody chose.

Rendering on by default. Both SparkProxy and ScrapingBee render JavaScript unless you pass render_js=false. That is a sensible default for success rates and an expensive one for static pages. A catalogue of 600,000 server-rendered product pages costs 600,000 credits with rendering off and 3,000,000 with it left on. Same data, five times the credits.

Geo targeting added everywhere. Where country targeting carries a charge (+5 on SparkProxy), set it only on targets that actually vary by country. A US-only retailer does not need country_code=US on every request.

Premium routing as a blanket setting. Premium or residential routes cost 10 to 25 credits. Teams often switch them on after the first block and never switch them off for the targets that never needed them.

Domain surcharges you did not know applied. On vendors that price by domain, a job that adds a search engine or social network to its URL list can change cost per request by an order of magnitude without any parameter changing. ScraperAPI publishes a domain multiplier tool and an account endpoint for checking this before a run.

A useful habit: write the parameters for each target class into a config file with its credit cost in a comment. When cost per request is visible in code review, defaults stop hiding.

"Pay only for successful requests" is a common promise and a reasonable one. It does not mean you pay only for data you can use.

Vendors decide success at the HTTP layer. A 200 response is successful. ZenRows also counts 404 and 410 as successful, and ScraperAPI bills 200 and 404, on the reasonable grounds that the request completed. SparkProxy refunds credits automatically when a job fails with a server-side error or returns 530 after its automatic retries.

What no API can judge is whether a 200 page is the page you wanted. Common billed-but-unusable responses:

• A challenge or "verify you are human" interstitial served with status 200.
• A soft block that returns an empty product grid or a "no results" template.
• A consent or region-selection page instead of content.
• A page rendered before the data loaded, because the wait condition was wrong.

Each of those costs full credits. Your parser should classify them explicitly and your cost model should include them through the usable rate. If you cannot measure the usable rate, you cannot forecast the bill. Our guide to detecting when your scraper is blocked lists the signals worth checking.

Here is the formula applied to a plausible monthly workload of 1,000,000 pages. Every volume, percentage and usable rate below is an illustrative assumption chosen to show the method, not a measurement. Credit costs use SparkProxy's published rates.

Now add re-fetches for unusable responses. Assume 2% of the static pages, 4% of the listings and 8% of the protected pages come back billed but unusable and must be fetched again: 12,000 + 60,000 + 200,000 = 272,000 credits. The total becomes about 4,872,000 credits, which needs the Scale plan (8,000,000 credits at $599). Pro's 3,000,000 would not cover it.

Four observations from this table apply to almost any workload:

1. The protected tenth is more than half the bill. 10% of pages consume 54% of subtotal credits. Cost reduction work belongs there first.
2. Re-fetches concentrate where credits are already expensive. Of the 272,000 re-fetch credits, 200,000 come from the protected class.
3. One wrong default doubles the bill. Leave rendering on for the static catalogue and that row rises from 600,000 to 3,000,000 credits, taking the subtotal to 7,000,000.
4. Testing the render assumption pays. If half the listing pages turn out to work without rendering, that row falls from 1,500,000 to 900,000 credits.

Divide by output rows to see the real unit price. If the 1,000,000 pages yield 400,000 finished records, the effective cost is roughly $599 / 400,000, about $1.50 per 1,000 records, against a headline of $0.075 per 1,000 credits. Neither number is wrong. They answer different questions, and only the second one belongs in a budget.

The cheapest configuration that returns usable data varies by page, not only by site. A tiered request tries the cheap route first and escalates only when the response fails your usability check.

import requests

API = "https://scrape.sparkproxy.io/api/v1"
HEADERS = {"X-API-Key": "YOUR_API_KEY"}

TIERS = [
    {"render_js": "false"},                           # 1 credit
    {"render_js": "true"},                            # 5 credits
    {"render_js": "true", "premium_proxy": "true"},   # 25 credits
]

def looks_usable(html: str) -> bool:
    lowered = html.lower()
    return 'itemprop="price"' in lowered and "verify you are human" not in lowered

def fetch(url: str):
    spent = 0
    for params in TIERS:
        r = requests.get(API, headers=HEADERS, params={"url": url, **params}, timeout=180)
        spent += int(r.headers.get("X-Credits-Used", 0))
        if r.ok and looks_usable(r.text):
            return r.text, spent
    return None, spent

Escalation is not free. A page that needs the top tier costs 1 + 5 + 25 = 31 credits instead of 25, because it paid for two failed attempts first. So escalation wins when most pages succeed at a lower tier and loses when most pages need the top one.

The break-even is easy to compute. With a share p of pages needing the top tier and the rest succeeding plain, escalation costs roughly (1 - p) x 1 + p x 31 credits per page, against 25 for sending everything to the top tier. Escalation stays cheaper while p is below about 80%. Once you know a target class sits above that, start it at the tier it needs and skip the cascade.

Better still, remember the result. Store the tier that worked per URL pattern and start there next run.

Every estimate above depends on three numbers you can only get from your own targets: the tier each URL class needs, the usable rate at that tier, and requests per record. Free credits exist for exactly this. SparkProxy gives 1,000 with no card, enough for a few hundred plain samples or a couple of hundred rendered ones.

A sampling run that produces the inputs for the formula:

import csv, random

def sample(url_class: str, urls: list[str], n: int = 100):
    rows = []
    for url in random.sample(urls, min(n, len(urls))):
        html, credits = fetch(url)          # the tiered fetch from the previous section
        rows.append({"class": url_class, "url": url,
                     "usable": html is not None, "credits": credits})
    usable = sum(r["usable"] for r in rows)
    spent = sum(r["credits"] for r in rows)
    print(f"{url_class}: usable {usable}/{len(rows)}, "
          f"{spent / max(usable, 1):.1f} credits per usable page")
    return rows

Run it per URL class, not per site. A single site often has static category pages, rendered search pages and protected checkout-adjacent pages, each with different economics. Sample at a gentle rate, too, so the test reflects normal operation rather than a burst.

Keep the output. Re-run the sample monthly or whenever the cost per usable page drifts, because targets change their defences without notice and the multiplier you measured in March may not hold in June.

Once you have credits per month, three more checks decide the plan.

Headroom. Credits on monthly plans generally reset each cycle. Size for your expected month plus a buffer for re-fetches and one-off backfills, rather than for your average month exactly. The worked estimate above landed at about 4.9 million credits, so an 8 million plan leaves reasonable room. A workload at 2.9 million on a 3 million plan does not.

Concurrency. Credits cap how much you scrape per month. Concurrency caps how fast. If a job must finish inside a window, work out the parallelism it needs. For example, 1,000,000 rendered pages in 24 hours is about 11.6 requests per second. If a rendered request takes around 8 seconds end to end (an assumption, measure yours), that needs roughly 93 requests in flight, which rules out SparkProxy's Starter (50 concurrent) and fits Growth (100), even if Starter's credits were enough.

Tier cliffs. Price per credit falls as plans grow: on SparkProxy's ladder, from $0.196 per 1,000 on Starter to $0.075 on Scale. If you sit just above a tier boundary, compare the cost of the larger plan against trimming the workload, for example by turning off rendering for static classes, which is often enough to drop a tier.

For readers comparing credits with flat proxy plans at very high volumes, the thread-based arithmetic is in how many proxies you need for scraping, and the underlying billing models are explained in datacenter proxy pricing models.