Scrapingbypass API uses a credit-based billing model. According to the current official documentation, V1 and V2 consume 1 credit after each successful request. When V2 encounters and successfully completes a verification challenge, it consumes an additional 2 credits. V2s uses the same V2-style parameters but adds stream response support, so its credit behavior should be understood in the same V2 scenario while checking your actual console usage records.

Overview

The safest way to understand credit usage is to separate two parts: the base successful request credit and the extra verification challenge credit. A request that fails before a successful response does not consume the base request credit, but a successful challenge can be deducted immediately even if a later response error occurs.

Consumption by API Version

Example: if a V2 or V2s request can reuse an already validated session and returns successfully, you mainly consider the successful request credit. If the same request triggers a JS Challenge, Turnstile, or Incapsula validation and the challenge succeeds, include the extra challenge credits as well. Always use the console credit log as the final source of truth.

Which challenges add extra credits?

The official documentation lists the following challenge types:

• Cloudflare JS challenge
• Cloudflare Turnstile
• Incapsula

When a verification challenge succeeds, the extra credits are deducted immediately. If a response error happens after the challenge, the challenge credits are not returned, while the base request credit is not deducted when the request itself is not successful.

How V2s affects credit usage

V2s is not a separate challenge type. It is the stream-response version of V2. To use it, set x-cb-version: 2s; all other V2 parameters, such as x-cb-proxy, x-cb-part, and x-cb-sitekey, remain the same.

This means V2s should be evaluated by the same logic as V2: if it only streams a large response after a session is already valid, the stream behavior itself is not the same as a new challenge. If the V2s request triggers and solves a JS Challenge, Turnstile, or Incapsula verification, the extra challenge credits should be expected.

curl --request GET   --url "https://api.scrapingbypass.com/files/report.zip"   --header "x-cb-apikey: YOUR_APIKEY"   --header "x-cb-host: target.com"   --header "x-cb-version: 2s"   --header "x-cb-proxy: http://user:pass@proxy-host:port"   --header "x-cb-timeout: 600"   --output report.zip

Session persistence and credit-saving tips

V2 and V2s support session partitioning through x-cb-part. After a challenge succeeds, the validated Cloudflare cookies can be kept in the server-side session partition for a limited period. Reusing the same target host, proxy, and part can reduce repeated challenges and therefore reduce the chance of extra challenge credit consumption.

• Use a stable or sticky proxy IP for the same workflow.
• Use different x-cb-part values for concurrent workers to avoid challenge lock conflicts.
• For Turnstile flows, verify x-cb-sitekey, [cf_token], x-cb-action, and x-cb-cdata before retrying repeatedly.
• Use V2s for large files or long responses, and set a reasonable x-cb-timeout to avoid restarting downloads and repeating challenges.

Expiration and Balance Management

• Credit Expiration: unused credits are cleared automatically after the validity period ends.
• Top-up Logic: each purchase is calculated independently. New credit packages do not extend the validity of previous ones.
• Consumption Order: credits are deducted in expiration order, so the earliest-expiring credits are consumed first.
• Billing Check: to verify V2 or V2s usage, compare request logs, x-cb-status, and the credit records in your console.

Note on V2/V2s Optimization

To maximize cost efficiency, reuse validated sessions within their valid window, keep proxy and part values stable for the same workflow, and switch to V2s only when stream response is actually needed.