SparkProxy vs ScraperAPI: Failure Accounting, Priced

Start with the two policies in the vendors' own words, because the mechanisms are different even though the headline promise matches.

ScraperAPI's credits documentation: "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)." Its API status-code reference puts it again on the 500 tab: "Request failed. You will not be charged for this request."

SparkProxy's docs: "Credits are deducted before the request runs and automatically refunded on failure."

Same outcome, opposite plumbing. ScraperAPI never debits for a failure, so your balance only ever moves for work that produced something. SparkProxy debits up front and reverses it, so the balance dips by the cost of everything currently in flight and recovers as failures settle. Neither is better in the abstract, but the second has a consequence worth knowing before you launch a big batch near empty: 400 concurrent rendered requests reserve 2,000 credits the instant they go out. If that leaves you short, the 402 body tells you exactly how short, with credits_required and credits_remaining as fields rather than prose.

Reconciliation differs too. On ScraperAPI, billed credits and successful responses are the same population by definition, so there's nothing to reconcile. On SparkProxy every response hands you its own cost: X-Credits-Used as a header on plain HTTP requests, or credits_used inside the JSON body in headless mode. The general mechanics of credit meters are in scraping API credit pricing explained.

Read ScraperAPI's billing sentence again and stop at the second half: "and for requests that have been cancelled from your side before giving us enough time to finish them (70 seconds)."

That clause exists because of how ScraperAPI handles hard targets. Its status-code docs: "ScraperAPI will retry failed requests for up to 70 seconds to try and get a successful response from the target URL before responding with a 500 error indicating a failed request." The docs tell you to set the client timeout to 70 seconds to match.

We've stated that rule before as a row in a billing table, in ScrapingBee vs ScraperAPI. That post tells you the rule exists. The rest of this one prices it, which is the part nobody publishes.

Most scrapers don't. A 30-second timeout is the common choice, and Python's requests has no default at all, so teams add one and pick a number that feels sane for a web page. Pick 30 and you've inverted the billing policy on yourself. Your client hangs up while ScraperAPI is still on attempt three, you're billed for the cancellation, and you never receive the 500 that would have been free. Your logs show a client-side timeout rather than a vendor failure, so nothing in your monitoring suggests you just paid for nothing.

The arithmetic is small enough to carry in your head. Your cost per useful page rises by your abort rate divided by your success rate. Abort 6% of attempts and succeed on 89%, and you pay about 6.7% more per page than the price list says. Abort a quarter of them on a slow target and the uplift is roughly 35%. Nothing on the invoice explains it, because every billed request on it was billed correctly.

One documentation wrinkle before you quote the number to a colleague: the window is 70 seconds on the credits page and the API status-codes page, but the General FAQ says ScraperAPI will "keep retrying the request with different proxies for up to 60 seconds", and the Low Success Rates FAQ says connection_timeout "should be set to at least 60 seconds (70 recommended)". Treat 70 as the documented retry budget and 60 as a figure that also appears in the FAQ.

SparkProxy's budget is longer and the shape is different:

SparkProxy's longer ladder is a cost in latency, not in credits, and it needs a correspondingly patient client. We also don't publish what happens to the pre-debit if you disconnect mid-job, which is a gap in our docs rather than a feature. The safe pattern on either vendor is the same: don't hold a socket open for three minutes. Use the fire-and-forget path, take the 202, let the result arrive at your webhook. If you're tuning timeout and backoff numbers right now, proxy timeouts and retry logic and retry and backoff strategies for web scraping cover the client side.

"Successful" is doing a lot of work in both policies, and it doesn't mean "returned the data you wanted".

A 404 is a paid outcome. ScraperAPI says so explicitly: 200 and 404 are the billable statuses. SparkProxy publishes no per-status billing line, but its documented status model points the same way, because headless mode "always returns 200 on success or 530 on failure", so a 404 page that renders fine is a successful render and therefore a billed one. In plain HTTP mode, transparent_status_code=true mirrors the page's real status onto the API response so your classifier can see it. Either way, verify with credits_used on your trial rather than taking our word for it.

This matters more than it sounds. A sitemap-drift sweep, a stale product-ID list or a quarterly link audit is mostly 404s by design. At 12% dead URLs across 50,000 URLs, that's 6,000 billed requests returning nothing you can store. At 1 credit each it's cheap. Render those same pages and it's 60,000 credits on ScraperAPI against 30,000 on SparkProxy. That's the rendering multiplier the next section prices, landing on a sweep that produced nothing.

A challenge page is also a paid outcome, on both. This is the leak neither policy addresses, because it isn't a failure at the HTTP layer. A Cloudflare interstitial, a Turnstile widget, a consent wall or a "please enable JavaScript" stub all come back as 200 with real markup. Both vendors bill it, and both are right to by their own stated rules.

They differ in whether they help you notice. SparkProxy classifies CAPTCHA blocks: a 530 body carries reason: "captcha_blocked" and a captcha_type of cloudflare_turnstile, hcaptcha or recaptcha, with null for behavioural blocks such as DataDome, PerimeterX and Akamai. ScraperAPI's answer is to sell you past them instead, with named bypasses at 10 credits each for Cloudflare, Turnstile, Datadome, PerimeterX/Human and Akamai. Different philosophies, and the second one is more useful when the target is actually fighting you.

Here is the whole ledger in one place:

The conclusion is the same whichever vendor you pick: the status code is not a billing control, and your own content assertion is. A 200 that doesn't contain the selector you asked for is the most expensive response either API can return, because you pay full price for a row of nothing. That assertion is work you own either way, which also shapes the build-or-buy question in web scraping API vs self-managed proxies, and how to bypass Cloudflare for web scraping covers what these challenge pages look like from the client side.

One framing to kill before the numbers, because it circulates widely: ScraperAPI is not a per-GB vendor. Its pricing page lists "Unlimited Bandwidth" as a core feature on every plan, and its Plans and Billing FAQ is blunt about it: "Currently, we don't offer bandwidth based pricing. All our plans are based on the number of requests you make to the API each month." Unlimited traffic is table stakes in this matchup, not a differentiator. The vendors where bandwidth billing does decide the purchase are covered in per-IP vs per-GB proxy pricing.

So the comparison has to be fought on credit multipliers and on what a credit costs.

Look at what matches. Premium without rendering is 10 on both. Premium with rendering is 25 on both. Plain fetches are 1 on both. That is what makes the one gap credible instead of cherry-picked: the plain rendered page costs 10 credits on ScraperAPI and 5 on SparkProxy, and almost nothing else diverges. The mirror image is just as real, and it covers two rows rather than one. Geotargeting is free on ScraperAPI and costs 5 credits on SparkProxy. So are browser actions: ScraperAPI's Rendering Instruction Set takes click, input, loop, scroll and wait instructions, sent as an x-sapi-instruction_set header alongside render=true, and its docs publish no credit surcharge for them, where our js_scenario adds 5.

Now the dollar value of a credit, derived from both published plan tables on 9 October 2026 and shown so you can redo it:

The right-hand column is plan price divided by credits, times 10 for ScraperAPI and times 5 for SparkProxy, times 1,000. Arithmetic on published numbers, not a measurement.

Three dated caveats. ScraperAPI's Professional and Advanced credit figures carried a banner-flagged "LIMITED OFFER" bonus on 9 October 2026 (+250K and +500K), so the base allowances are 10,250,000 and 21,000,000 and the bonus can be withdrawn. Its Terms reserve price and credit-cost increases "at least as often as once per calendar year" on 30 days' notice with a matching termination right, and clause 3.15 adds that "for certain protected or high-risk target domains, we may automatically apply credit multipliers". Annual billing takes 10% off, putting Hobby at $44.10/month and Advanced at $1,777.50/month, and the tradeoff in locking that in is the subject of monthly vs annual proxy plans.

Both vendors have a $49 plan. Here is what each one actually delivers once failure accounting is applied. The failure rates below are assumptions, labelled as such, chosen from each vendor's own published statements so you can substitute your own measurements.

Assume you want 10,000 JavaScript-rendered pages on a moderately defended target, with no country code. Assume a 3% hard failure rate, the top of ScraperAPI's own stated range ("You can expect 1-3% of your requests to fail"). Assume 6% of rendered attempts are still running at 30 seconds, consistent with ScraperAPI documenting 4 to 12 second average latency, single requests "sometimes" reaching 60 seconds, and premium=true being offered to "reduce the longtail of some requests taking 20-30 seconds".

ScraperAPI Hobby, client timeout 70 seconds (as the docs instruct). No aborts. 300 attempts fail and return 500 for free. 9,700 succeed and bill 97,000 credits, which is $47.53 for 9,700 pages, or $4.90 per 1,000 good pages. The headline price is the real price. This is the policy working exactly as advertised.

ScraperAPI Hobby, client timeout 30 seconds (the common default). 600 attempts get cancelled by your client and bill 10 credits each for nothing: 6,000 credits gone. Of the remaining 9,400, 3% fail free and 9,118 succeed, billing 91,180 credits. Total billed: 97,180 credits for 9,118 usable pages, which is 10.66 credits per useful page instead of 10, so $5.22 per 1,000. Same money, and you end the run 582 pages short. That split is generous to ScraperAPI, because it treats the aborts and the hard failures as separate populations. A request that only fails after the full 70 seconds of retrying was still running at 30 seconds, so in practice most of that 3% is also billed as a cancellation rather than returning a free 500. The real figure sits above $5.22, not below it.

SparkProxy Starter. 10,000 rendered attempts debit 50,000 credits up front. 300 fail, return 530 after the full 90/120/180 ladder, and refund 1,500. Net billed: 48,500 credits for 9,700 pages, which is $9.51, or $0.98 per 1,000 good pages. The 250,000-credit plan leaves room for roughly 50,000 rendered pages in the month rather than 10,000.

Two identical sticker prices, and after failures the gap on this workload is $0.98 against $5.22 per thousand useful pages. Most of that is the 2x rendering multiplier and the dollar-per-credit difference, which you could read off the price list. The last 6.5% is a timeout value in a config file.

Flip the workload and the conclusion flips too. Make those 10,000 pages unrendered and geotargeted, and ScraperAPI charges 1 credit where SparkProxy charges 6. At matched 3,000,000-credit tiers that's $0.10 per 1,000 on ScraperAPI Business against $0.50 on SparkProxy Pro. Five times cheaper, on their side. The axis that decides this comparison isn't which vendor is cheaper, it's what fraction of your requests render and what fraction carry a country code.

Neither vendor bills you for hitting the concurrency limit. ScraperAPI returns 429 with "You are sending too many simultaneous requests. Ensure your concurrency rate is according to the limit of your scraping plan and try again." SparkProxy returns 429 with active, limit and retry_after_seconds: 5 as structured fields. Free, both times.

That's exactly why concurrency is the cost nobody prices. It doesn't show up as an error you can count or a line on an invoice. It shows up as a job that finishes at 4am instead of midnight.

Take ScraperAPI's own latency range and use the 8-second midpoint. Ten thousand rendered pages at 20 threads is 4,000 seconds of wall-clock, about 1 hour 7 minutes. The same ten thousand at 50 concurrent is 27 minutes. At the million-credit tier, a hundred thousand rendered pages takes roughly 4 hours 27 minutes at 50 threads and 2 hours 13 minutes at 100. That's derived from ScraperAPI's published average latency and both vendors' published concurrency numbers, and it ignores queueing variance, so treat it as a sizing estimate rather than a forecast.

Two honest notes. ScraperAPI's ceiling is higher than ours, 500 threads on Advanced against our published 400 on Scale, and its General FAQ invites you to ask for more ("If you would like to increase the number of concurrent requests you can make, please contact our customer support team"). If raw parallelism is your binding constraint rather than cost per page, that decides it. The other note is smaller but costs real time: a client that retries a 429 immediately in a tight loop converts a throttle into a spin, and retry_after_seconds tells your code how long to wait instead of leaving your engineer to guess. Sizing a thread count against a target's own tolerance is a separate exercise, covered in understanding concurrent connections in proxies.

This is the failure mode with the largest price tag attached, and it lives in the Terms rather than the docs.

ScraperAPI returns 403 when you're out: "You have exhausted the API Credits available in this monthly cycle. You can upgrade your subscription or enable overages from your dashboard." Whether you can enable overages depends on your tier. Terms 13.5(b): "If you exceed your included credits on a Hobby, Startup or Business plan, you must upgrade to the next available plan to continue using the Services." Pay-as-you-go is available on Scaling, Professional, Advanced and Enterprise only.

Work that through. You're on Hobby at $49, you run dry on day 20, and you need data for the remaining 10 days. The documented route back is Startup at $149, a $100 step for ten days, and the Hobby credits you already paid for don't come with you. Terms 13.1(a) is explicit: credits "remain usable during that applicable Billing Period only; expire at the end of that Billing Period; are non-refundable and do not roll over." The General FAQ agrees: "we don't have the possibility to roll over unused API Credits."

The overage rate on the higher tiers isn't something we can quote. Terms 13.5(a) says overages bill "at the then-posted in-app rate" and the FAQ calls it "a fixed, predictable rate", but the dollars-per-credit figure is only visible behind login, so don't model it from anything you read in a blog post, this one included.

SparkProxy returns 402 with the numbers attached and the documented remedy is to top up rather than change plan. Our own gap deserves the same plainness: SparkProxy does not publish a credit rollover policy either way. ScraperAPI's non-rollover rule is at least written down. Ours isn't written down at all, so don't assume unused SparkProxy credits carry forward, and ask before you buy a large pack you plan to burn slowly.

One place ScraperAPI is unambiguously better: it publishes a written exit. The docs say "We offer a 7-day no questions asked refund policy." The Terms are narrower, clause 13.8: "You have the right to ask for a refund up to seven (7) days after the first day of purchase (not the same as the day renewal date). After that we shall not refund any Subscription Fees." The window runs from first purchase, not from each renewal. Even so, a buyer who wants to test a paid tier against production targets and walk away has a stated remedy in writing, which is more than most of this market offers.

ScraperAPI's pricing page lists a "99.9% Uptime Guarantee" among the features included with all plans. Its published Terms clause 8.4 reads: "WE MAKE NO REPRESENTATION, WARRANTY, OR GUARANTEE AS TO THE RELIABILITY, TIMELINESS, QUALITY, SUITABILITY, AVAILABILITY, ACCURACY OR COMPLETENESS OF THE PLATFORM... PROVIDED TO YOU STRICTLY ON AN 'AS IS' BASIS." A full-text search of those Terms for "service credit", "service level", "SLA" and "99.9" returns zero matches. So: no service-credit remedy appears in the public Terms. We did not read any separate enterprise agreement, which could contain an SLA for negotiated accounts, so that's the limit of the claim.

On success rate, ScraperAPI publishes observations rather than commitments, and it's careful about the distinction. The General FAQ: "our average success rate is around 98%", "You can expect 1-3% of your requests to fail, but you won't be charged for those", and "If you are experiencing failure rates in excess of 10% then contact our support team." Those are useful planning numbers and they are not contractual.

Now hold the same mirror up to our side, because saying this about one vendor only is how comparison posts lose their credibility. SparkProxy's scraping API page prints "99% Success Rate" and "99.9% Uptime". Those are marketing figures too. They aren't a benchmark, they aren't measured the same way as ScraperAPI's 98%, and they don't belong in a cost model any more than ScraperAPI's do. The only success rate worth planning against is the one you measure on your own targets, which is what the next section is for.

Both vendors let you test without a card. ScraperAPI's free plan is "1,000 free API credits per month (with a maximum of 5 concurrent connections)", plus "5,000 free requests" in the first seven days. SparkProxy gives 1,000 free credits on signup. The structural difference favours them: their grant recurs every month, ours is one-time.

The audit needs three numbers per vendor, and only one comes from the vendor:

1. Billed credits, read per request rather than from the dashboard total.
2. Verified-good responses, meaning your own assertion against the response content, not the status code.
3. Wall-clock for the whole run, which is where throttling hides.

From those, two ratios worth more than any price list. Billed-to-useful ratio is billed credits divided by (unit cost times verified-good responses), and anything above 1.0 is what the price list didn't tell you. Cost per verified record is dollars-per-credit times billed credits, divided by verified-good responses.

On SparkProxy, tag the run so you can group it later, and take the JSON envelope so the cost comes back with the content:

curl -sS "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: $SPARKPROXY_API_KEY" \
  --get \
  --data-urlencode "url=https://example.com/product/8841" \
  --data-urlencode "render_js=true" \
  --data-urlencode "json_response=true" \
  --data-urlencode "tag=audit-2026-10-09/rendered" \
  --max-time 240

The envelope comes back with job_id, status_code, duration_ms, credits_used, tag, and the page in body as base64. That last part trips people up: json_response=true base64-encodes the body, so decode before matching anything against it. A marker check run against the raw envelope string fails on every response and reports your success rate as zero.

Here's the ledger as a script. It runs your sample twice, once at a short client timeout and once at a patient one, which is the comparison this whole post is about:

import base64, time, requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = "YOUR_API_KEY"
MARKER = 'itemprop="price"'      # your own proof the page is usable
UNIT_COST = 5                    # render_js=true
DOLLARS_PER_CREDIT = 49 / 250_000  # Starter: $49 / 250,000 credits

def run(urls, client_timeout):
    billed = good = aborted = failed = 0
    t0 = time.time()
    for url in urls:
        try:
            r = requests.get(
                API,
                headers={"X-API-Key": KEY},
                params={
                    "url": url,
                    "render_js": "true",
                    "json_response": "true",
                    "tag": f"audit/t{client_timeout}",
                },
                timeout=client_timeout,
            )
        except requests.exceptions.Timeout:
            aborted += 1          # on ScraperAPI, inside 70s this is a BILLED request
            continue

        env = r.json()
        billed += env.get("credits_used", 0) or 0

        if r.status_code != 200:
            failed += 1           # 530 on SparkProxy: refunded, so credits_used is 0
            continue

        html = base64.b64decode(env["body"]).decode("utf-8", "replace")
        if MARKER in html:
            good += 1
        else:
            failed += 1           # soft success: billed 200, no usable data

    elapsed = time.time() - t0
    ratio = billed / (UNIT_COST * good) if good else float("inf")
    per_1k = DOLLARS_PER_CREDIT * billed / good * 1000 if good else float("inf")
    print(f"timeout={client_timeout}s  billed={billed}  good={good}  "
          f"aborted={aborted}  failed={failed}  "
          f"billed/useful={ratio:.3f}  $/1k_good={per_1k:.2f}  "
          f"wall={elapsed:.0f}s")

urls = [l.strip() for l in open("sample-300.txt") if l.strip()]
run(urls, client_timeout=30)
run(urls, client_timeout=240)

Three hundred URLs is enough to see the shape and costs about 1,500 credits per pass. Run the identical list and the identical marker on the other vendor, reading sa-credit-cost from the response headers in place of credits_used, then compare the two ratios rather than the two price lists.

For the 404 question, drop rendering and turn on transparent statuses so the target's own code reaches your classifier:

r = requests.get(
    API,
    headers={"X-API-Key": KEY},
    params={
        "url": "https://example.com/discontinued/sku-1190",
        "render_js": "false",             # 1 credit, no browser
        "transparent_status_code": "true",  # API status mirrors the target's
    },
    timeout=90,
)
print(r.status_code, r.headers.get("X-Credits-Used"))

Credit where it's due: ScraperAPI's cost-governance tooling is better than anything we publish. It returns a sa-credit-cost header on every response, exposes a pre-flight cost endpoint at api.scraperapi.com/account/urlcost that accepts every parameter so you can price a URL before spending on it, offers a Domain Multiplier lookup in the dashboard, and supports a max_cost parameter that returns 403 with "This request exceeds your max_cost" instead of quietly charging you. If your spend has to be forecast per target and signed off before the job runs, those instruments are a legitimate reason to pick ScraperAPI, and we don't have an equivalent.

No vendor wins every axis, and a comparison that says otherwise is marketing. These are the workloads where we'd tell you to buy theirs.

1. Search engine and marketplace data, today. ScraperAPI publishes working per-domain costs for SERP (Google and Bing, including subdomains, 25 credits), e-commerce (Amazon, Walmart, eBay, 5 credits) and LinkedIn (30 credits), with JSON auto-parsing listed as a core feature on every plan and Structured Data endpoints documented for both its sync and async APIs. Which plan tiers those endpoints are available on isn't something ScraperAPI publishes, so ask before you buy a tier for them. SparkProxy lists its Google Search, YouTube, Amazon, Walmart, Flipkart and Bing APIs as "Coming Soon" on every tier. If the job is a Google SERP feed or an Amazon ASIN pull, they ship it and we don't.

2. Targets that are actively fighting you. Named, priced bypasses at 10 credits each, plus an ultra_premium tier at 30 credits (75 with rendering) documented for "really tough target websites" and cached by default. Two constraints to plan around: premium and ultra_premium "are mutually exclusive", and custom headers "cannot be used together with ultra_premium=true", which discards them even with keep_headers=true. Our +5 stealth add-on and absent per-protection tier make for a thinner escalation path. For the behavioural protections, how to bypass DataDome for web scraping explains what you're up against either way.

3. Overnight batches where reliability beats latency. The Async API runs jobs "until the requested pages are successfully scraped or for up to 24 hours", accepts "up to 50 000 URLs per batch job", delivers by webhook, and stores results "for up to 72 hours (24 hours guaranteed)". Its own FAQ recommends it when "success rate matters more than response time". Our batch mode works only with render_js=false. For 50,000 rendered pages collected by morning, their architecture is the right one, not just the cheaper one.

4. Plain geotargeted fetching at scale. country_code costs zero extra credits there and 5 here, so an unrendered geotargeted request is 1 credit against our 6, roughly five times cheaper per thousand pages at matched tiers. The catch is the plan gate: individual country codes need Business at $299/month, because "Hobby and Startup plans support only US and EU regional-based geotargeting (individual country codes are not supported)."

5. Small and intermittent work. 1,000 free credits per month, recurring, at 5 concurrent connections, plus 5,000 in the first 7 days. A side project pulling a few hundred plain pages a month runs there permanently at $0, where our 1,000 credits are a one-time grant. Structural win, not a rounding error.

6. Spend that has to be forecast before it's committed. The cost-control instruments from the previous section.

7. Maximum parallelism. 500 threads on Advanced and 500+ on Enterprise against our published 400 on Scale, with support willing to raise limits on request.

8. Buyers without an engineer. ScraperAPI's pricing page sells DataPipeline as a way to "automate data collection without writing a single line of code", and its own DataPipeline docs call it a "low-code solution" that runs "up to 100 000 URLs, keywords, ASINs or Walmart IDs at once" on a schedule, delivered to a webhook as HTML, JSON or CSV. Those docs don't say which plan tiers include it, so confirm that with their support before you buy a tier on that basis. The AI Parser alongside it does publish its entitlements, in a per-plan table: every plan including the free one gets a parser and "the first parser you create is always free", paid tiers hold up to five, each parser after the first costs 30,000 credits, and the free plan can create a parser but can't update it. For a market-research team with nobody to maintain a scraper, that beats any per-request economics.

9. Anyone who wants a written way out. The 7-day refund policy quoted above.

One more note in their favour: ScraperAPI publishes a floor for negotiated deals, stating that discounted accounts "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." Publishing the limit of your own discount is unusual, and it saves a buyer a wasted negotiation.

If two or more of those nine describe your project, buy theirs. The broader landscape is in ScraperAPI alternatives, and if ScrapingBee is the other name on your shortlist, ScrapingBee vs ScraperAPI prices that pair directly.

The mirror image, stated as narrowly as it deserves.

Rendered pages without a country code. 5 credits against 10, on top of a lower dollar-per-credit at every comparable tier. $49 buys roughly 50,000 rendered pages on Starter and 10,000 on Hobby. If most of your crawl needs a browser, this is the whole argument and the rest is detail.

Concurrency per dollar below the top tier. 50 against 20 at $49, 100 against 50 at a million credits, 200 against 100 at three million. Above that their ladder goes higher than ours.

Failure telemetry you can branch on. A 530 body carrying attempts, reason, captcha_type and job_id; a 429 carrying active, limit and retry_after_seconds; a 402 carrying credits_required and credits_remaining. Machine-readable failure classification is cheaper to operate than a sentence of English, because your retry logic can act on it without parsing prose.

A longer server-side retry ladder, and a way not to wait for it. 90 seconds then 120 then 180, with callback_url returning 202 immediately so you aren't holding a socket open while it works.

Dead-link sweeps. Batch mode takes comma-separated URLs and the whole batch costs 1 credit, with per-URL success, httpStatus and error in the results array. It only works with render_js=false, which is exactly the right mode for a 404 audit, and nothing on either vendor's price list competes with 1 credit for a batch.

Content conversion with no second meter. format=md, mdx or json converts server-side at no charge beyond the render cost, so Markdown extraction costs the same 5 credits as the HTML.

And the caveats, so this section stays honest: no rollover policy published, no named per-protection bypass tier, no shipped SERP or marketplace endpoints, no published overage mechanics, and a smaller advertised pool. Those are real, and four of them are documentation problems we should fix rather than product problems.