SparkProxy vs ZenRows: Who Owns the Unblocking

ZenRows publishes one credit table and applies it identically on every plan. Confirmed on the pricing page, in the docs and on the public pricing calculator, all read 9 October 2026:

The calculator defines the unit in ZenRows' own words: "One credit is a standard successful page; harder work draws more from the same balance."

Put the last two rows of that table next to each other. Residential bandwidth costs 25,000 credits per gigabyte. A fully protected page fetch, browser plus residential exit, costs 25 credits. Divide one by the other and you get an exact equivalence that appears nowhere in ZenRows' marketing: one gigabyte of residential traffic is priced identically to exactly 1,000 protected page fetches, or 25,000 plain ones.

That ratio converts every plan into a per-gigabyte price the pricing page never shows. The arithmetic below is ours, done on ZenRows' published prices and ZenRows' published credit table. It is derived, not quoted, and it is ZenRows' own residential path priced against itself. There is deliberately no SparkProxy column beside it, because SparkProxy doesn't sell residential exits. Each plan name covers several credit rungs on the pricing page, so this takes the entry rung of each plan plus the top Scale rung.

Same byte, 6.3x spread. The only variable that moves the price is how much you commit to up front. That is a perfectly defensible way to run a business, and it's the number to compute before you shortlist anything. Our breakdown of scraping API credit pricing walks the same ladder across several vendors.

Now read the same rungs the other way, because this is the unit the rest of the article needs. A standard request, the plain fetch through ZenRows' default pool with no browser and no premium exit, is 1 credit. So every rung also prices a plain page, and this division is ours as well: $19 for 45,000 credits is roughly $0.00042 a page, $69 for 250,000 is $0.00028, $99 for 500,000 is $0.00020, and $199 for 1,200,000 is $0.00017. That is 25x below the protected path off the same rung, and it's the figure that lines up against a flat datacenter pack.

Two more things from the pricing page worth knowing before you read a rung off it. Annual billing is described verbatim as "Paying yearly gives you two months free (pay for 10, get 12)", roughly 17 percent, and the published annual figures match that formula to within a dollar of rounding at every rung. And the Free plan is 5,000 credits a month, which buys exactly 200 fully protected fetches, with "Monthly refresh, no rollover" and a concurrency limit of 5.

SparkProxy sells the other shape, and it sells a different kind of exit. The product is datacenter: sparkproxy.io's own page is titled "Buy Premium Datacenter Proxies with Unlimited Bandwidth" and describes the pools as "1M+ datacenter IPs across 80+ Countries" and "50,000+ premium US datacenter IPs". There is no residential line on it. The Starter pack is $75 per month at 100 threads, plans are packs rather than meters, and unlimited bandwidth is included. The billing unit is the plan and its concurrency, not the traffic you consume. A page that weighs 4 MB costs the same as one that weighs 40 KB, and a retry costs nothing in traffic terms.

That constrains what an honest comparison can put side by side. A datacenter pack lines up against ZenRows' standard 1-credit request, the plain fetch through its default pool. It does not line up against the 25,000-credits-per-gigabyte residential line, and pricing those two against each other would make whichever vendor you put in the cheap column look about seven times better than it is. Residential and datacenter exits aren't substitutes on a protected target. Treat them as separate purchases.

On plain pages the crossover is a bracket rather than a line, and the published rungs set its edges. The $69 Launch rung covers 250,000 fetches and is still under $75. The $99 Launch rung at 500,000 is the first one over it. So a flat pack starts winning somewhere between 250,000 and 500,000 plain fetches a month, ZenRows is genuinely cheaper everywhere below that, and at 5,000 a month its free tier costs nothing at all.

Protected pages are a much closer race, and the number is the same on both sides. A rendered fetch through a premium pool costs 25 credits on ZenRows (js_render plus premium_proxy) and 25 credits on SparkProxy's Scraping API (render_js=true plus proxy_type=premium, which our docs call the "same tier as premium_proxy=true"). Identical integers, both from the vendors' own documentation. That comparison therefore turns entirely on the price per credit, not on the parameter, and the right SparkProxy comparator for it is the Scraping API's credit plans rather than the $75 pack. If residential exits specifically are the requirement, price ZenRows' premium path against SparkProxy's premium pool and leave the datacenter pack out of the conversation.

Two caveats before you read a rung off the table. First, this compares price per unit of work only. The Starter pack ships 100 threads against 50 concurrent requests on ZenRows' Launch rungs, but feature parity is not something we're claiming, so check both vendors' current pages before you buy. Second, ZenRows' Enterprise tier is custom-priced with unlimited volume and 500 to 1,000+ concurrency, and no public number exists for it. At serious scale you'd be comparing against a quote, not against $2,999.

The honest headline is therefore not "cheaper". It's metered versus flat, and two numbers locate you on it: pages per month, and what share of those pages need a browser or a premium exit. If you don't know either, section ten measures both in an afternoon. Our notes on whether unlimited bandwidth is worth it and on residential pricing per GB cover the general case; this is the vendor-specific version of it.

When an API owns the unblocking, it owns the dials that unblocking uses. ZenRows is unusually clear about this in its own docs, which makes the trade easy to audit. Every row below comes from a ZenRows documentation page.

None of that is a flaw. It's the deal. You're paying for someone else to make those calls well, and ZenRows' published operational claims on its homepage, read 9 October 2026, are "100% Fetch uptime, 90 days", "10B+ requests a month" and "Trusted by teams at +10,000 companies". Those are the vendor's claims, not measurements of ours, and no success-rate percentage appears on any ZenRows page we fetched, so treat any such figure you see quoted elsewhere with suspicion.

The reason this table matters is narrow and specific. Nine times out of ten you don't want to touch the User-Agent. The tenth time, a target starts fingerprinting something you can only reach from inside the browser, and the only move the API leaves you is a support ticket.

Here's the scenario that actually decides this purchase. A target ships a new challenge at 2am. Your success rate drops to 40 percent. What can you see, and what can you change?

With ZenRows you get a genuinely good observation surface. json_response=true (which also requires js_render=true) returns html as a JSON-encoded string, plus an xhr array of every captured XHR, fetch and AJAX call with its URL, body, status code, method and both request and response headers, plus an optional js_instructions_report and an optional base64 screenshot. That XHR capture is a real debugging asset, and ZenRows' docs are explicit that the envelope itself adds nothing to the bill: "The json_response parameter doesn't increase the request cost on its own."

# ZenRows Fetch: envelope with captured XHR, per docs.zenrows.com/fetch/features/json-response.md
# Auth is the `apikey` query parameter; js_render is OFF by default and required here.
curl -s "https://api.zenrows.com/v1/" \
  -G \
  --data-urlencode "apikey=$ZENROWS_KEY" \
  --data-urlencode "url=https://example-target.test/product/1" \
  --data-urlencode "js_render=true" \
  --data-urlencode "json_response=true" \
  | python3 -c "import sys,json; e=json.load(sys.stdin); \
print(len(e.get('html','')), len(e.get('xhr',[])))"

What you can't do is change what the browser looked like. The fingerprint, the header order, the TLS stack and the retry policy are all behind the endpoint.

SparkProxy's envelope answers a different set of questions. json_response=true is the only parameter that returns the envelope, and it carries job_id, status_code, duration_ms, credits_used and a base64-encoded body. Decode before you match anything, or every marker check silently fails:

import base64, os, requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = os.environ["SPARKPROXY_API_KEY"]

def fetch(url, render=True, country=None):
    # proxy_type=premium is 10 credits without a browser, 25 with one, so this call
    # as written costs 25, +5 again if country_code is set. Drop proxy_type and you
    # are on the 5-credit rendered path, or the 1-credit path at render_js=false.
    params = {"url": url, "render_js": str(render).lower(),
              "proxy_type": "premium", "json_response": "true"}
    if country:
        params["country_code"] = country          # +5 credits
    env = requests.get(API, headers={"X-API-Key": KEY},
                       params=params, timeout=120).json()
    html = base64.b64decode(env["body"]).decode("utf-8", "replace")
    return env, html

env, html = fetch("https://www.sparkproxy.io/", render=True, country="us")
print(env["job_id"], env["status_code"], env["duration_ms"], env["credits_used"], len(html))

Two traps here have each cost somebody a debugging session. format is a content-conversion switch and nothing else, with html, md, mdx, json, screenshot and pdf as its values, so asking for format=json gets you structured page content and not the envelope you wanted. And extract_rules swaps the whole response for an extracted object, which means pairing it with json_response is a contradiction, not a combination.

The difference in a 2am incident is this. Through the API you can see what happened and escalate. Owning the layer, you can see what happened and change the browser, which is slower on the first night and faster on the fifteenth. If your targets are JavaScript-heavy, our guide to scraping dynamic JavaScript sites covers the rendering side in detail.

Both vendors expose a proprietary parameter vocabulary, and the migration cost of either one is not measured in documentation pages. It's measured in call sites. Count the places in your repository that name a vendor parameter: the client wrapper, the retry wrapper, the per-target config that says which targets get a browser, the test fixtures that assert on response shape, the dashboard that charts credits_used. Every one of those is a thing that has to be rewritten and re-tested, and the count is always higher than the team guesses, because a parameter vocabulary leaks into the config layer long before anyone calls it an abstraction. A rename is an afternoon. Thirty call sites and a config schema is a sprint.

Five rows carry the argument. The rest of the dialect maps cleanly enough that a table of it would be a reference, not a decision.

The full dialect mapping, including the four traps that survive a port, is in ZenRows alternatives. The opposite rendering defaults in row three are the first of those traps and the expensive one, so set that flag explicitly on every call in either direction.

The premium row is the one worth sitting with, because the two vendors land on the same two integers from opposite ends. Ten credits for a premium exit without a browser, 25 with one, on both sides. The protected-page meter is therefore identical and the divergence is on the cheap path: ZenRows gives you the 1-credit request by default, SparkProxy gives you the 5-credit rendered one and makes you ask for the 1-credit fetch. What the premium price buys is not the same thing either. ZenRows' premium pool is residential, 55 million addresses by its own published count. SparkProxy's proxy_type=premium selects a file-based premium pool from the server's own proxy configuration, and ad_free selects a cleaner pool for nothing extra, which is what makes the premium line a choice rather than a toll. Pricing the parameter across vendors is fair. Pricing the pools as interchangeable is not.

mode=auto, ZenRows' Adaptive Stealth Mode, is the purest expression of the whole trade, and it has no counterpart on the SparkProxy side of the table. It "analyzes each request and selects the most cost-effective configuration needed for successful data extraction" and you "are billed only once, for the configuration that succeeds". The price is written into the API surface: you may not set js_render or premium_proxy yourself, and doing so returns a 400 saying those parameters "cannot be used with automatic mode". That refusal is the product. The escalation ladder your own code would otherwise own, try cheap, detect the block, retry richer, has been moved inside the endpoint, and the parameters that would let you second-guess it are locked out while it's running.

Which is why the lock-in here is not really about names. A parameter you can rename is a morning's work. A parameter that replaced a decision in your code is a decision you have to write back from scratch, and nobody budgets for that, because the code that used to make it was deleted eighteen months ago.

This is where ZenRows wins outright, and the detail is better than the headline suggests.

The pricing page is unambiguous: "Failed requests are never charged. Not Found (404) and Gone (410) responses count as successful results." The docs phrase it as "You're charged only for successful requests." The error catalogue then refines it per code, and the refinements are the part people miss:

• RESP002 (404 Page Not Found) and RESP007 (Site Not Found): "Note that these requests are billed." 404s are billed by design, consistent with the pricing page calling them successful results.
• CTX0001 (Context Cancelled): "Requests that end with this error aren't charged." REQS002 is also not charged.
• allowed_status_codes flips the policy. The docs carry a verbatim warning: "Requests using the param allowed_status_codes will incur charges!" Switch it on to capture error pages and you've switched on billing for them.

Against a target whose defences you can't predict, that policy plus mode=auto is worth real money, because you stop paying for your own retry loop and for guessing which vendor runs on a given site.

Three cost-control mechanics round it out. Concurrency is capped per plan at 5 (Free), 20 (Build), 50 (Launch), 100 (Growth), 200 to 400 (Scale) and a custom 500 to 1,000+ on Enterprise; exceed it and you get "a 429 Too Many Requests error" until slots free up. The detail to notice is that the cap travels with the plan name, not with the credit rung: the $69 and the $129 Launch rungs both stop at 50 slots, so a team that is short of throughput rather than short of credits has only one lever, which is to buy a plan it doesn't need the allowance for. Our piece on concurrent connections covers how to size that number before you pick a rung. An account can also hold "up to 10 API keys, for example one per project, environment, or customer", each with "its own credit caps", settable per billing period, daily, weekly or monthly, returning HTTP 402 AUTH014 when hit. For an agency, that's a genuinely hard-to-replicate control.

Two things to check with ZenRows rather than trust either page on. Credit carry-over is described two ways: the docs FAQ says paid-plan credits "roll over for 1 additional billing period before they expire", while the terms say the available Usage "cannot be accumulated and cannot be consumed by the Client once the duration period has elapsed". Ask before you buy. And on feature gating, the pricing page states that "Every plan includes every primitive (Fetch, Extract, Batch, Browser Sessions) and every interface (REST API, CLI, MCP server, SDKs)", while the error catalogue defines AUTH010 "Feature Is Not Included In Plan" and AUTH012 "Subscription Does Not Allow Use Of The Product" under HTTP 402. Both statements are published, and we're not going to guess which one describes your account.

One more operational note. ZenRows publishes an acceptable-use list in its docs that blocks banks, card processors and payment gateways ("VISA, MasterCard, PayPal, Stripe, and similar payment platforms"), visa and eVisa sites, and government sites, "primarily .gov", adding "We may also block other sites based on legal or ethical concerns". Only fully qualified domain names may be scraped, not raw IP addresses. Read that list against your target list before you sign anything.

Plenty of real workloads should buy the API, and a comparison that pretended otherwise would be useless. ZenRows is the better purchase in all of these cases:

• Small volume. Anything under a couple of hundred thousand plain pages a month, or a few thousand protected ones. The $19 Build rung buys 45,000 standard fetches or 1,800 fully protected ones; the $69 Launch rung buys 250,000 standard or 10,000 protected. For a side project, a weekly price check or a single-client scraper, ZenRows undercuts a $75 pack outright.
• Evaluation, and permanently free hobby use. 5,000 credits a month, no card, and the terms call it "a permanent, recurring free plan" that is "not a time-limited trial". That beats any fixed-length trial for someone who wants to test over several weeks, and a job needing under 200 protected pages a month runs free forever.
• Spiky or unpredictable anti-bot work. Failures aren't billed, and mode=auto escalates from 1 credit upward and charges once for the configuration that worked. You're buying out of the business of guessing.
• Teams who don't want to write or maintain parsers. Extract, css_extractor, autoparse and the 12 outputs filters (emails, phone numbers, headings, images, audios, videos, links, menus, hashtags, metadata, tables, favicon) cost no extra credits, and Markdown, plaintext and PDF output are free too. Structured JSON straight out of the endpoint is less work than building extraction on top of a pool.
• Multi-step authenticated flows. Browser Sessions give you a real remote browser over Puppeteer or Playwright with a persistent session, billed at 25,000 credits per GB plus 5 credits per minute. Log in, click through three screens, read a value: that's the right tool for it, and a rotating pool plus your own browser fleet doesn't hand it to you out of the box.
• Agency and multi-tenant budgets. Ten API keys with independent credit caps so one client's runaway job can't eat another's allowance.
• JavaScript-heavy bulk sweeps. 100,000 URLs per Batch job with rendering supported.
• Long sticky sessions. The legacy residential product offers sticky TTLs up to ttl-1d, a full day, against SparkProxy's 5-minute auto-rotation. If a workflow must hold one IP for hours, that's the longer option.
• Enterprise procurement. The Enterprise tier is where ZenRows puts the SLA, SOC 2 and ISO 27001 compliance, a dedicated account manager and quarterly business reviews. Free through Scale carry no SLA, and the percentages aren't published. If a security questionnaire gates your purchase, this decides it.
• Agent and tooling ergonomics. A first-party CLI, an MCP server, SDKs for Python, Node and Go, and documented integrations across LangChain, LlamaIndex, CrewAI, n8n, Zapier, Make, Scrapy, Playwright and Selenium. If an LLM agent is driving the scraper, the MCP server matters.
• Long-tail country coverage. "190+ countries" per the proxy_country docs, with a code list in the docs FAQ spanning 195+ entries from af to zw, against SparkProxy's 80+. For a long tail of small markets, ZenRows covers more of them. (Note that the pool figure, "55 million residential IP addresses", appears on the premium-proxy page and on the legacy residential page, while the same premium-proxy page also says ZenRows maintains "thousands of residential IPs". Quote it as their published figure, not as an audited count.)

For more on the general shape of this decision, independent of either vendor, see web scraping API vs self-managed proxies. If you're cross-shopping managed APIs against each other rather than against proxies, ZenRows alternatives and ZenRows vs ScraperAPI are the pages for that.

The case flips on three conditions, and you usually need only one of them.

Volume past the crossover. Somewhere between 250,000 and 500,000 plain fetches a month the meter overtakes a $75 datacenter pack, and past that bracket it keeps compounding, because the only lever a credit plan hands you is a bigger commitment. A flat pack has no such lever, since there's nothing to meter: at 1,200,000 plain pages the published comparison is $199 against $75, and at 5,000,000 it's $549 against the same $75. Page weight never enters into it on our side, because bandwidth is unlimited.

Many targets, each slightly different. A credit-metered API prices every target the same way, by defence level. Your own layer lets you spend engineering once and run cheap forever on the 80 percent of targets that need nothing more than a plain HTTP fetch with a believable header set and a clean IP. On SparkProxy that's render_js=false at 1 credit and roughly 3x faster, or straight proxy traffic at no per-request cost at all on a pack.

A target you have to debug deeply. If a single site is 60 percent of your revenue and it ships challenges every few weeks, you need the browser in your own hands: header order, TLS fingerprint, canvas noise, timing. Those are all inside the vendor's box in a managed API, and the only escalation path is a ticket.

Two smaller things that decide specific cases. SparkProxy's proxies speak HTTP, HTTPS and SOCKS5 with IP whitelisting or user:pass auth, on 1 Gbps ports, which matters when the client isn't an HTTP library you control. And the pool is 1M+ premium datacenter IPs across 80+ countries, rotating either per request at random or on a 5-minute timer, which is the right shape for a target that rate-limits each address. Pool character matters more than pool size at every tier, and our breakdown of premium versus standard residential pools makes that argument in the general case.

The cost that never shows up on either pricing page is engineering time. Owning the layer means you maintain it, including on the night a target changes. That's the real price of the flat plan, and it's why the crossover is a range rather than a line.

SparkProxy sells both halves of this argument, so the useful question isn't "which vendor" but "which product". Proxies always winning would be a sales pitch, not a comparison.

Pick the Scraping API (base https://scrape.sparkproxy.io/api/v1, X-API-Key header, 1,000 free credits on signup) when your targets need a browser, when you want the render step, the exit selection and the challenge handling to sit behind a single call, and when you'd rather read credits_used off an envelope than run a browser fleet. You're buying the same shape of thing ZenRows sells, and the published credit weights are the ones to budget against: render_js defaults to on at 5 credits, render_js=false is 1, country_code adds 5, js_scenario adds 5 for browser actions up to 50 instructions, format=screenshot and format=pdf add 5 and need rendering on, and proxy_type=premium is 10 credits without a browser or 25 with one. proxy_type=ad_free is the pool value that costs nothing extra.

Pick the datacenter proxy packs (Starter from $75 a month, 100 threads, unlimited bandwidth, 1M+ IPs, 80+ countries, HTTP/HTTPS/SOCKS5) when the unblocking logic already lives in your code or you want it to, when your pages-per-month is past the crossover bracket, or when per-request pricing of any kind is the thing you're trying to escape. If what you actually need is a residential exit, neither the pack nor this section is the answer, and you should be comparing premium pools on both vendors instead.

Most teams end up running both: proxies underneath the 80 percent of targets that need nothing clever, and a managed API on the handful that do. That split is cheaper than either pure strategy, and it's the arrangement this comparison tends to point at once you've measured your own traffic.

A note on what we're not quoting. The $75 figure is the published entry price for the Starter datacenter pack. We're not putting a Scraping API plan price in this article, because a price comparison is only honest when both numbers come from a current page, so check the SparkProxy pricing page for the credit plans before you budget. The per-request credit costs above are from the Scraping API docs and are accurate as of 9 October 2026.

You need two numbers, and neither vendor can give them to you. Both take an afternoon to measure.

Number one: pages per month, and the bytes behind them. Run your real URL list and count both. The page count is what locates you on the metered-versus-flat bracket. The byte count only matters if a per-gigabyte residential meter is on your shortlist, in which case multiply it by 25,000 to get the ZenRows credit figure. Almost nobody knows either number before they look.

import base64, os, requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = os.environ["SPARKPROXY_API_KEY"]

def measure(url, render):
    env = requests.get(API, headers={"X-API-Key": KEY},
                       params={"url": url, "render_js": str(render).lower(),
                               "json_response": "true"}, timeout=120).json()
    raw = base64.b64decode(env.get("body") or b"")
    return {"status": env.get("status_code"), "ms": env.get("duration_ms"),
            "credits": env.get("credits_used"), "bytes": len(raw),
            "words": len(raw.split())}

urls = open("targets.txt").read().split()
rows = [measure(u, render=False) for u in urls]      # second pass: render=True

ok    = [r for r in rows if r["status"] == 200 and r["words"] > 120]
bytes_per_page = sum(r["bytes"] for r in ok) / max(len(ok), 1)
PAGES = 1_000_000                                    # your real monthly page count
print(f"sample {len(rows)}  clean {len(ok)}  avg {bytes_per_page/1024:.1f} KB")
print(f"projected {PAGES:,} pages/month: {bytes_per_page * PAGES / 1e9:.1f} GB of traffic")
print(f"ZenRows plain path at 1 credit/page:      {PAGES:,} credits")
print(f"ZenRows protected path at 25 credits/page: {PAGES * 25:,} credits")
print(f"ZenRows residential meter at 25,000/GB:   "
      f"{bytes_per_page * PAGES / 1e9 * 25_000:,.0f} credits")

The words > 120 filter earns its place. Most block pages come back 200, carrying a few hundred bytes of challenge markup instead of your content, so a tally built on status codes alone will tell you everything worked and hand you a byte average computed from pages you never received. Count words, then count bytes.

Number two: how many of your targets genuinely need the browser. This is the number that decides whether you're paying 1 credit or 25 for the median page, and it's the single biggest lever on either vendor's bill.

# Same sample, two passes. If the cheap pass gets the content, never pay for the expensive one.
cheap = [measure(u, render=False) for u in urls]
rich  = [measure(u, render=True)  for u in urls]

need_browser = [u for u, c, r in zip(urls, cheap, rich)
                if c["words"] < 120 <= r["words"]]
print(f"{len(need_browser)} of {len(urls)} targets need rendering")
print("ZenRows median credits:",
      25 if len(need_browser) > len(urls) / 2 else 1)

Then price it both ways. Multiply your rendering ratio by ZenRows' credit table to get a monthly credit figure, pick the rung that covers it off the pricing page, and compare that to a flat pack. If the answer lands within 20 percent either way, buy the API, because at that margin the engineering time dominates the price difference and you should let someone else carry the 2am page.

Run the same sample through ZenRows' free tier while you're at it. 200 fully protected fetches is a small sample but it's free, it's permanent, and it tells you whether their escalation logic clears your specific targets. That's a better signal than any article, including this one.