Olostep vs ScraperAPI: Cost Per Successful Page

A credit is not a request, and it is not a page. It is a unit of account that each vendor defines privately, then sells to you in bulk. Two vendors can quote credits that differ threefold in price and still land within pennies of each other per page, or quote near-identical credit prices and differ by 6x on your actual workload. The credit price tells you nothing until you know how many credits that vendor charges for the page you want.

Here is the same page priced three ways. A product page that needs a headless browser and sits behind Cloudflare:

ScraperAPI's credits are 3.32x cheaper. The page costs 6.32x more. Both figures are correct, and only the second one is a price.

This is the whole reason a side-by-side plan table is useless for scraping APIs. Four other posts on this blog already lay those tables out, including ScraperAPI alternatives and ZenRows vs ScraperAPI, so this one does something different: it gives you the conversion function, applies it to Olostep and ScraperAPI, and then hands you the script to apply it to your own request log.

Cost per 1,000 successful pages needs exactly five numbers. Three of them come off the vendor's price list. The other two come from your own traffic, and those are usually the ones that decide the answer.

Input 1: price per credit, at list. Plan price divided by included credits. Straightforward, and the only number most buyers look at.

Input 2: plan utilisation. Credits you will actually burn, divided by credits the plan includes. Both vendors sell credits in blocks, and both reset the block: ScraperAPI's pricing FAQ states that "your ScraperAPI credit balance resets when your subscription renews" and unused credits do not roll over. Olostep's credits sit in lots with an expiry_date, visible through GET /user/credits/info, and its top-up packs are documented as "valid for 6 months". Stranded credits are a real cost, so the effective price per credit is plan price divided by credits consumed, not credits included.

Input 3: credits per billed attempt. This is the weight, and it is where the two vendors diverge most. It depends on the target domain class, the parameters you send, and whether the target has anti-bot protection turned on today.

Input 4: billed attempts per page you keep. Not every billed response is a page you want. ScraperAPI bills 404s. ScraperAPI also bills requests your own client cancelled, if it cancelled them too early. Retries that fail are free on both vendors, but retries that succeed are billed, so a flaky target raises this term above 1.0.

Input 5: the page you keep is not always a page you can use. A 200 response with an empty product grid is a billed success and a useless record. Only your own content assertion can tell the difference, which is why this input never appears in a vendor comparison table.

Write the five as p (price per credit), u (utilisation), w (credits per billed attempt), a (billed attempts per kept page), and y (share of kept pages that pass your assertion). The cost of 1,000 pages you can use is:

C1k = 1000 * (p / u) * w * a / y

Everything below is an exercise in filling those five slots honestly.

Olostep is the younger of the two, and its model is close to flat. Prices below are USD, read from olostep.com/pricing and docs.olostep.com on 9 October 2026.

Top-up packs, "valid for 6 months": 10,000 credits for $20, 250,000 for $200, 2,000,000 for $1,000. That last one is $0.500 per 1,000, so a top-up on the biggest pack still costs more per credit than the Scale subscription.

The credit weights are short enough to quote in full. From the Scrape feature docs: "Scrape costs 1 credit by default. If you also pass parsers, the costs vary by parser (1-5 credits). If you use LLM extract, it costs 10 credits." The Batch docs add "Batch costs 1 credit per URL". The Search docs put a search at 5 credits plus the standard scrape rate per page returned, and give a worked line: "Search + 5 scraped pages (1 credit each) | 10". The Answers endpoint is 20 credits per request.

What is not in that list matters more than what is. There is no JavaScript surcharge, no residential surcharge, no anti-bot surcharge, and no domain class. The trial tier's own description says "All requests are JS rendered + utilizing residential IP addresses", and the site's FAQ confirms the bundling: "One request equals one webpage or one PDF processed. We do not charge separately for bandwidth, proxies, or data usage. All infrastructure costs are included in the price per request." The country parameter is documented in the request schema as "Residential country to load the request from" and appears in no pricing table.

On input 4, the same FAQ states: "No, Olostep does not charge for failed requests. You are only billed for successful requests." Two useful properties fall out of the API shape. The scrape response carries credits_consumed, described in the API reference as the source of truth, alongside cost_usd, "Estimated cost in USD for this request ... Calculated from credits consumed and your plan rate, 99% accurate". A vendor that hands you a dollar figure per request has removed input 1 and input 2 from your spreadsheet. Nobody else in this comparison does that.

curl -sS "https://api.olostep.com/v1/scrapes" \
  -H "Authorization: Bearer $OLOSTEP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url_to_scrape":"https://example.com/product/8841","formats":["markdown"]}' \
  | python -c "import json,sys; d=json.load(sys.stdin); print(d.get('credits_consumed'), d.get('cost_usd'))"

The failure surface is documented and short: dns_resolution_failed and invalid_url return 400, tls_error returns 502, and a scrape that exceeds the roughly 55-second wait budget returns 504 scrape_poll_timeout, which the docs call "safe to retry". Olostep's own reliability claims, which I have not measured, are "99.5% uptime" and "up to 70% cheaper" on its homepage FAQ, and "99% reliability, the highest on the market" in its llms.txt. Treat all three as marketing until you have run your own sample.

ScraperAPI's model is the opposite design: cheap credits, heavily weighted. Prices below are USD monthly, read from scraperapi.com/pricing on 9 October 2026. The annual column is the same plan "billed annually", which works out to 10% off.

Free tier: 1,000 credits with a maximum of 5 concurrent connections, plus a 7-day trial carrying 5,000 credits and no card.

Now the weights, quoted from the Credits and Requests costs page. Domain classes: normal flat requests cost 1, e-commerce (Amazon, Walmart, eBay) costs 5, SERP (Google and Bing, "applies to all subdomains") costs 25, and social media (LinkedIn) costs 30. Anti-bot bypass is a separate table, all at 10 per scrape: Cloudflare, Cloudflare Turnstile, Datadome, PerimeterX/Human, Akamai. Parameters then stack on top: premium=true is 10, render=true is 10, screenshot=true is 10, ultra_premium=true is 30, premium with render is 25, and ultra_premium with render is 75. Free parameters are wait_for_selector, country_code, session_number, device_type, output_format, keep_headers and autoparse.

Two of those entries deserve a pause. autoparse=true is free, so structured extraction on supported targets adds no weight at all, which matters for the per-record division later. And country_code is free, which is unusual and genuinely good, but free is not the same as available. The pricing table gates the country list by plan: Hobby and Startup read "Geotargeting: US & EU only", and "Geotargeting: Global" starts at Business. A parameter that costs zero credits on a plan that will not serve your country is worth nothing, and that distinction is invisible to any credit calculation. Keep it on the capability checklist, not in the weight table.

On input 4, the docs are precise in a way few vendors are: "We only charge for successful requests (200 and 404 status codes) and for requests that have been cancelled from your side before giving us enough time to finish them (70 seconds)." A 404 is a billed credit that yields no page. A client timeout set below 70 seconds converts your own impatience into a line on the invoice. That second clause is priced out in detail in SparkProxy vs ScraperAPI, so this post takes it as a given and moves on.

ScraperAPI also removes most of the guesswork about input 3, which is worth more than any pricing page. Every response carries an sa-credit-cost header, and there is a documented lookup endpoint that prices a URL plus parameter set before you send a single real request:

curl -sS "https://api.scraperapi.com/account/urlcost?api_key=$SCRAPERAPI_KEY\
&url=https://www.wikipedia.org/&render=true"

One more clause that rarely makes it into comparisons. The same docs page carries this note: "Accounts that have custom deal with discounted pricing, will have a higher credit cost per request for our Ultra Premium domains to meet our minimum pricing of $3 per one thousand requests without rendering and $7 with rendered pages." That is a published floor in dollars, not credits. However good your enterprise discount, Ultra Premium traffic cannot go below $3 or $7 per 1,000 requests. For scale, 75 credits on the Startup list rate is $11.17 per 1,000 requests, so the floor sits well under list and is aimed at large discounted accounts.

With both models quoted, the function writes itself. Weight the classes by your own traffic shares to get the mean credits per attempt:

w_bar = sum over classes of ( share_i * credits_i )

Then feed the five inputs:

effective price per credit  =  plan_price / credits_consumed        (not / credits_included)
cost per billed attempt     =  effective price per credit * w_bar
cost per kept page          =  cost per billed attempt * a
cost per usable page        =  cost per kept page / y
C1k                         =  1000 * cost per usable page

Three notes on using it honestly.

The plan choice is part of the formula, not an input to it. You pick the smallest plan whose included credits cover attempts * w_bar, and the utilisation term then penalises you for the headroom you bought and did not use. A vendor with coarse plan steps loses here even when its per-credit price looks better.

The a term is asymmetric between these two vendors and you cannot average it away. On ScraperAPI, dead URLs are billed, so a rises with the staleness of your URL list. On Olostep, published policy says failures are not billed, so a stays at 1.0 for dead URLs and rises only when a retry eventually succeeds.

The y term is yours alone. Set it from a content assertion, never from a status code. A page that returns 200 with a bot-check interstitial is the single most expensive outcome in scraping, because it is billed, it passes every naive check, and it poisons your dataset.

Here is a mix shaped like real retail-intelligence work rather than a vendor's favourite benchmark: 100,000 target pages a month, four classes.

The ScraperAPI column takes the additive reading of the docs: base domain class, plus 10 for the anti-bot bypass, plus 10 for render=true. That reading is an assumption, flagged again in the unverified section below, and the urlcost endpoint settles it for your exact URLs in one call.

Now the plan step. ScraperAPI needs 998,000 credits, so Startup at $149 and 1,000,000 credits fits with 99.8% utilisation. Olostep needs 100,000 to 148,000, so Standard at $99 and 200,000 credits fits at 50.0% to 74.0% utilisation.

The last row is the number the whole post exists to produce. $1.02 against $1.54, on this mix, with everything sourced. The gap is 1.5x, and here is why that is much smaller than it looks:

• Per credit, Olostep is 3.32x more expensive ($0.000495 against $0.000149).
• Per page, ScraperAPI spends 9.98x more credits (9.98 against 1.00).
• Multiply those and the marginal advantage to Olostep is 3.0x.
• The actual bill ratio is only 1.51x, because Olostep's plan steps leave half the Standard block unused while ScraperAPI's Startup block is 99.8% consumed.

Utilisation claws back half of Olostep's structural advantage, and that is the finding a headline-price table cannot show you. It also means the answer is not monotonic in volume. Hold the class mix fixed, change only the number of pages, and the winner changes twice:

At 300,000 pages ScraperAPI wins outright, and not because its weights improved. Its 3,000,000-credit Business plan happens to absorb 2,994,000 credits at 99.8% utilisation, while Olostep's ladder steps straight from 200,000 to 1,000,000 and strands most of a $399 plan. Push to 600,000 and it flips back hard, because now ScraperAPI overshoots into a $975 plan at 57% utilisation and Olostep's Scale block finally earns its price.

The formula is not a verdict. It is a function you evaluate at your own volume, and it has discontinuities exactly where the plan ladders do.

One capability check overrides all of that arithmetic, and it is the sort of thing a spreadsheet misses. The 5,000 country-pinned pages in my mix assume the plan can reach that country. ScraperAPI's Startup plan cannot, unless the country is in the US or the EU, because global geotargeting starts at Business. So if those pages need, say, Brazil or Japan, Startup is off the table on capability rather than on credits, and the comparison has to be re-run against Business at $299:

The same workload, the same weights, the same vendor, and the gap moves from 1.5x to 3.0x on a single feature flag. Always resolve capability before cost, because a cheaper plan that cannot serve the request is not a data point.

Pages are an engineering unit. Records are the business unit, and the conversion is two more terms: records parsed per page, and the share of those records that survive validation.

cost per useful record = cost per usable page / ( r * v )

Take the rendered product class from the mix above. A category page yields 42 product rows, and 94% of them pass a validation that requires both a parseable price and a non-empty SKU. That is 39.48 useful records per page.

The ratio is 6.32x, identical to the per-page ratio, and that is the point worth sitting with. The record divisor r * v is a property of the target page and your parser, not of the vendor. It cancels out of any vendor comparison. What it does decide is whether the project is worth running at all: at 39.48 records a page, a million-record refresh costs $12.50 on one vendor and $79.30 on the other, and both are cheap. At 1.2 records a page, which is what entity enrichment looks like, the same million records cost $412 and $2,607, and the choice of vendor starts to matter a great deal.

One caveat keeps r * v from cancelling perfectly. ScraperAPI lists autoparse=true as a no-extra-cost parameter, so structured output on its supported targets adds nothing to w. Olostep's parsers are documented at 1 to 5 credits, so choosing a parser can multiply its weight by up to five, and LLM extraction is a flat 10 credits, which is a 10x weight on a vendor whose entire advantage is a weight of 1. If your pipeline relies on LLM extraction rather than deterministic parsers, recompute: 10 credits at $0.000495 is $0.00495 a page, which is more expensive than ScraperAPI's 21-credit rendered page.

The mix above is mine. Yours is in your logs. This is the whole method as runnable arithmetic, with no network calls and nothing to install:

PLANS = {
    # name: (monthly USD, included credits)
    "olostep_standard":   (99,   200_000),
    "olostep_scale":      (399,  1_000_000),
    "scraperapi_startup": (149,  1_000_000),
    "scraperapi_business":(299,  3_000_000),
}

# credits per billed attempt, per traffic class, from each vendor's published tables
WEIGHTS = {
    "olostep":    {"plain": 1, "rendered_protected": 1,  "serp": 5,  "geo_rendered": 1},
    "scraperapi": {"plain": 1, "rendered_protected": 21, "serp": 25, "geo_rendered": 11},
}

MIX = {"plain": 55_000, "rendered_protected": 28_000, "serp": 12_000, "geo_rendered": 5_000}

DEAD_URL_SHARE = 0.03   # 404s: billed on ScraperAPI, unbilled on Olostep
ASSERTION_PASS = 0.97   # your own content check on 200 responses


def normalise(vendor, plan, mix, bills_dead_urls):
    price, included = PLANS[plan]
    weights = WEIGHTS[vendor]
    attempts = sum(mix.values())
    credits = sum(n * weights[c] for c, n in mix.items())
    if credits > included:
        raise ValueError(f"{plan} holds {included:,} credits, mix needs {credits:,}")
    kept = attempts * (1 - DEAD_URL_SHARE)
    billed_attempts = attempts if bills_dead_urls else kept
    billed_credits = credits * (billed_attempts / attempts)
    usable = kept * ASSERTION_PASS
    return {
        "w_bar": credits / attempts,
        "utilisation": billed_credits / included,
        "eff_price_per_credit": price / billed_credits,
        "per_1k_usable": 1000 * price / usable,
    }


for vendor, plan, bills_dead in [
    ("olostep", "olostep_standard", False),
    ("scraperapi", "scraperapi_startup", True),
]:
    r = normalise(vendor, plan, MIX, bills_dead)
    print(f"{plan:<22} w_bar={r['w_bar']:5.2f}  util={r['utilisation']:6.1%}  "
          f"$/credit={r['eff_price_per_credit']:.6f}  $/1k usable={r['per_1k_usable']:.3f}")

Run as written, that prints:

olostep_standard       w_bar= 1.48  util= 71.8%  $/credit=0.000690  $/1k usable=1.052
scraperapi_startup     w_bar= 9.98  util= 99.8%  $/credit=0.000149  $/1k usable=1.584

Two deliberate differences from the table in the previous section. The script takes Olostep's SERP weight at the pessimistic end of the published 1-to-5 range, which is why w_bar reads 1.48 rather than 1.00. And it divides by the assertion pass rate, so its figures are cost per 1,000 usable pages rather than per 1,000 successful ones: $1.052 against $1.021, and $1.584 against $1.536, which is the same numbers divided by 0.97. Keeping both views is useful, because the successful-page figure is what you reconcile against an invoice and the usable-page figure is what you budget with.

Replace MIX with a GROUP BY over your own request log, bucketed by the classes your vendors actually price differently, and set ASSERTION_PASS from a content check rather than a status code. The raise is deliberate: if the mix overflows the plan, the comparison is invalid until you step up a tier, and silently overflowing is how teams end up surprised by a mid-month upgrade. For the measurement side of that assertion rate, what is proxy success rate and how to measure it covers the instrumentation.

Credits cap how many pages you may fetch this month. Concurrency caps how fast. These two ceilings are set independently by both vendors, and on one plan they are wildly out of proportion.

Pages per hour is concurrency * 3600 / mean_latency_seconds. Neither vendor publishes a per-class latency distribution, so latency is a parameter you measure, not a figure you look up. At three plausible values:

Now divide each plan's monthly page allowance by its own hourly ceiling, which asks a question nobody puts on a pricing page: how long can this plan run flat out before the credits are gone?

Olostep's 150-slot ceiling on a $9 plan is decorative. The plan holds 5,000 pages, so at 150 concurrent requests and a 4-second mean you exhaust the entire month in a bit over two minutes. The concurrency figure is real and useful for burst work, and it is not a throughput budget. ScraperAPI's ladder is proportioned the other way: Hobby's 20 threads will take most of a working day to spend 100,000 credits, which suits a scheduled nightly job and frustrates anything interactive.

The practical reading is that concurrency and credits should be sized against different things. Credits are sized against monthly volume. Concurrency is sized against your deadline, and against how much parallelism the target tolerates before it starts blocking you, which is a separate exercise covered in understanding concurrent connections in proxies.

Exceeding the ceiling is free on both vendors, and that is exactly why it is dangerous. ScraperAPI's pricing FAQ is explicit: "If you exceed your ScraperAPI limits, you'll get a 429 response asking you to bring your concurrency back within your plan's limit and try again. There's no extra charge for going over, the request is simply turned away rather than queued."

Turned away rather than queued is the operative phrase. The vendor does not hold your request, so your client has to, and a client that retries a 429 immediately converts a throttle into a spin that burns CPU and target goodwill without moving a single page. The cost lands as wall-clock, which never shows up on the invoice and always shows up in the delivery date.

Olostep's published failure surface is different in shape. Its scrape endpoint has a documented wait budget of roughly 55 seconds, after which it returns 504 scrape_poll_timeout, described as "safe to retry". Its batch endpoint sidesteps the problem entirely by being asynchronous: up to 10,000 URLs per batch, "around 5-8 minutes, regardless of batch size", 1 credit per URL, with results retrieved afterwards. New accounts are capped at 100 items per batch until you ask for the limit to be lifted, which the docs state plainly.

Those are two different operating models rather than two speeds. ScraperAPI's synchronous endpoint plus a hard thread count wants a client-side semaphore and a backoff policy. Olostep's batch endpoint wants a job queue and a webhook handler, and its own docs note that webhook deliveries are retried up to 5 attempts over about 30 minutes with exponential backoff, with your handler expected to answer 2xx within 30 seconds per attempt. Pick the one that matches the orchestration you already have, because rewriting the orchestration costs more engineering time than either plan costs in a year. If you are building the retry layer from scratch, retry and backoff strategies for web scraping and proxy timeouts and retry logic cover the patterns.

Nine inputs to the formula above are not resolvable from published documentation. Listing them is part of the method, because an unflagged assumption in a cost model is worse than a missing one.

How ScraperAPI's weights compose. The domain class, the anti-bot bypass and the parameter surcharges live in three separate tables on the same docs page, and no sentence states the arithmetic that joins them. A rendered page behind Cloudflare could be 1 + 10 + 10 = 21, or 20, or 11. I used 21 and labelled it. The urlcost endpoint resolves it exactly, per URL, before you spend anything.

Olostep's per-parser credit cost. The docs say parsers cost "1-5 credits" and name five parsers, including @olostep/google-search and @olostep/amazon-it-product. No table maps parser to cost. A 5x range on the dominant term of a flat-rate model is a large uncertainty, which is why the SERP row in my mix table carries a range rather than a number. Read credits_consumed off one real response and the range collapses.

Olostep's definition of a successful request. ScraperAPI names the status codes it bills (200 and 404). Olostep says only successful requests are billed and does not say which outcomes qualify. Whether a 404, a 403 bot wall, or a 200 with an empty body counts as success is the single most load-bearing unknown in the comparison, because it is the a term.

Olostep Scale concurrency. The Scale plan is listed as "Everything in Standard, Plus" a million requests and browser automations, with no concurrency figure. It presumably inherits at least Standard's 500, and the ceiling is not published.

Olostep trial rate limits. The free tier says "Low rate limits" and gives no number.

Whether Olostep's country parameter carries a surcharge. It appears in the request schema as "Residential country to load the request from" and in no pricing table. Absence from a pricing table is weaker evidence than a stated zero, which is what ScraperAPI gives for country_code.

Which Olostep top-up ladder is authoritative. The pricing page sells packs of 10,000, 250,000 and 2,000,000 credits. The billing API documents supported values of 10,000, 20,000, 80,000 and 100,000. The two lists do not reconcile and neither page explains the discrepancy.

Per-class latency for either vendor. Nobody publishes it, so every throughput figure in this post is a function of a latency you supply.

Success and block rates. Olostep's own claims are 99.5% uptime, "up to 70% cheaper", and "99% reliability, the highest on the market". ScraperAPI's pricing page lists a "99.9% Uptime Guarantee" and "Automatic Retries" among its all-plan features. I measured none of these, and neither should you trust them. They are vendor claims, and uptime is not success rate: an endpoint can answer every request with a 200 that contains a bot wall. Reading the gap between SLA language and observed outcomes is its own skill, covered in how to read a proxy provider SLA, and the detection side in how to detect when your scraper is blocked.

Evaluate the function at five shapes of workload and it stops being close.

Heavy JavaScript rendering on protected targets. Olostep, decisively. Rendering and residential exit are inside the 1-credit base, while ScraperAPI charges 10 for render=true and 10 more for the bypass. This is the 6.3x per-page gap, and no plan discount on the ScraperAPI side closes it.

SERP at volume. Closer than the headline suggests, and it depends on the parser cost Olostep does not publish. Against ScraperAPI's 25 credits, Olostep's 1 to 5 is still cheaper per page, but a $99 plan holding 200,000 credits caps you at 40,000 SERP pages a month in the worst case, while ScraperAPI's Business plan holds 120,000 at 25 credits each for $299. Run the arithmetic at your volume.

High-volume plain fetching. ScraperAPI, on credit price alone. Both charge 1 credit for a flat page, so w_bar is 1.0 for both and the comparison reduces to input 1, where ScraperAPI's Business plan at $0.0997 per 1,000 credits is 5x cheaper than Olostep Standard.

LLM-based extraction. ScraperAPI, by a wide margin. Olostep's LLM extract is 10 credits against a free autoparse=true, which inverts the entire advantage.

Spiky or seasonal volume. Olostep, on structure rather than price. Top-up packs valid for six months beat a monthly block that resets, and ScraperAPI's own FAQ confirms its credits do not roll over. ScraperAPI answers with pay-as-you-go above the plan limit, available on Scaling and above with a settable spending cap, so above roughly $475 a month the structural advantage reverses.

The honest framing is that SparkProxy sits between these two on w_bar and removes the term entirely on the proxy side.

On the Scraping API, the weight table is published, short, and has no domain classes and no anti-bot surcharge. Base URL is https://scrape.sparkproxy.io/api/v1 with an X-API-Key header. render_js defaults to true and costs 5 credits; setting render_js=false makes it a plain fetch at 1 credit. country_code adds 5. js_scenario adds 5 and requires render_js=true, with a 50-step maximum. Batch mode requires render_js=false, and the whole batch costs 1 credit. Signup carries 1,000 free credits.

On the mix in this post, that gives a w_bar of 3.05, between Olostep's 1.00 and ScraperAPI's 9.98, and batching the 55,000 plain pages drops it to about 2.50. The property worth having is not the number: it is that the number is computable from your parameter choices alone, with no domain lookup and no surprise when a target turns on Cloudflare mid-month.

Measuring w_bar for real needs the envelope, and the envelope has one trap. json_response=true is the only thing that returns job_id, status_code, duration_ms and credits_used, and the page body inside it is base64. Matching a marker against the raw envelope string fails on every response and reports a success rate of zero:

import base64, requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = "YOUR_API_KEY"
MARKER = 'itemprop="price"'          # your own proof the page is usable

def measure(urls, render_js=True):
    billed = usable = 0
    for url in urls:
        r = requests.get(API, headers={"X-API-Key": KEY}, timeout=240, params={
            "url": url,
            "render_js": "true" if render_js else "false",
            "proxy_type": "premium",
            "json_response": "true",
        })
        env = r.json()
        billed += env.get("credits_used", 0)
        body = base64.b64decode(env.get("body", "")).decode("utf-8", "replace")
        if env.get("status_code") == 200 and MARKER in body:
            usable += 1
    return billed, usable

billed, usable = measure(["https://example.com/product/8841"])
print(f"w_bar={billed / max(usable, 1):.2f} credits per usable page")

A plain fetch is the same call with render_js=false, which is the 1-credit path:

curl -sS "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: $SPARKPROXY_API_KEY" \
  --get \
  --data-urlencode "url=https://example.com/catalog/page/3" \
  --data-urlencode "render_js=false" \
  --data-urlencode "format=md"

Note that format only converts the content, to html, md, mdx, json, screenshot or pdf. It is not the envelope. If you want structured fields instead, extract_rules replaces the response with an extracted object and must not be stacked with json_response.

The proxy route deletes the weight term outright. SparkProxy's residential plans start from $75 a month with unlimited bandwidth included, across 1M+ premium IPs in 80+ countries, so the billing unit is the plan and its concurrency rather than traffic consumed. There is no per-GB meter and therefore no w_bar to compute: cost per successful page becomes plan price divided by pages your own fetcher completes, and the whole variance moves from the invoice to your code. Whether that trade is worth it is the subject of web scraping API vs self-managed proxies, and the credit mechanics themselves are unpacked in scraping API credit pricing explained. There is a 24-hour free trial with no card if you want to measure before deciding.