One Credit Balance, One Rate CardHow Crawlbase Pricing Works Across Every Product

A scraping pipeline rarely uses one product. It fetches pages through an API, renders some of them in a browser, queues large refreshes through a crawler, and keeps results in storage. When every one of those has its own price list and its own balance, working out what a workflow costs means reconciling four bills.

Crawlbase prices all of it on one credit balance and one graduated rate card. The Crawling API, the Enterprise Crawler, Smart AI Proxy, Cloud Storage and the calls made through the Crawlbase Web MCP Server draw from the same pool, and you choose whether to pay as you go or subscribe for a monthly block. This post explains how the rate card works, what one request actually costs, and how to keep spend under control as a workload grows.

How the graduated rate card works

The rate card works like income tax brackets. The first part of your monthly usage is priced at the first rate, the next part at the second, and so on. Crossing a threshold lowers the rate for the usage that follows; it never reprices what you already used. The pay-as-you-go rates for successful standard requests are:

Worked through the brackets, 100,000 successful standard requests cost $76.40, about $0.76 per 1,000. One million cost $527.50, about $0.53 per 1,000, and ten million cost $1,471.90, about $0.15 per 1,000:

100,000 standard requests
  first  1,000  x $3.00 / 1,000  =  $3.00
  next  10,000  x $2.00 / 1,000  = $20.00
  next  89,000  x $0.60 / 1,000  = $53.40
                          total  = $76.40

These figures are for standard requests. Requests to harder sites, or rendered with JavaScript, carry a multiplier, so a request count alone is not enough to forecast a mixed workload. The pricing calculator does the arithmetic for standard, moderate and complex sites, with or without JavaScript.

What one request costs

A successful request to a standard site uses one credit. The price of anything else follows from three rules: the site's difficulty tier, whether the page needs a real browser, and whether you keep the result.

The tier is assigned to the domain automatically; you do not choose it. JavaScript rendering doubles whatever the tier is, so a rendered request to a standard site costs 2 credits and a rendered request to a moderate site costs 3. A screenshot needs a real browser, so it is billed the same way as a rendered request: 2 credits on a standard site and more on harder ones. Storing a page adds half a credit when it is stored, and stored pages are kept for 30 days.

Check a site's tier before you scale

You do not have to guess. Open the Playground in the console, enter a target URL, and it shows the domain, its tier, the multiplier and the credits a successful request will spend. For https://www.amazon.com/dp/1098145356 it shows amazon.com · Moderate · 1.5x.

The estimate updates as you change the options. With Store result switched on, which is the default, the amazon example reads 2 credits: 1.5 for the request plus 0.5 for storing it. Turn storage off and it reads 1.5; turn JavaScript on and the request part doubles to 3. Choosing the Screenshot mode switches JavaScript on, because a screenshot needs a browser. Run request sends a live test, and Copy as cURL gives you the same call to reuse in your own code. When a workload spans several domains, checking each one here is the quickest way to stop treating every site as if it cost the same.

Pay as you go or subscribe

Both options use the same balance and the same products. The difference is how you fund it.

Pay as you go has no monthly fee. You are billed monthly, in arrears, for the successful usage you had, at the graduated rates above. It suits testing, occasional jobs and workloads whose volume is hard to predict.

A subscription buys a monthly allowance of credits at a lower effective rate:

The allowance resets every monthly billing cycle, and annual billing is available at a discount. The pricing page always has the current plans. Subscriptions fit steady workloads such as daily catalogue refreshes or continuous price monitoring. For very large or specialised workloads, enterprise terms cover custom volume, throughput and SLA commitments, and invoicing.

When the allowance runs out

With pay-as-you-go overage enabled, requests keep running after the monthly allowance is used up. The allowance is consumed first, and the usage after it is billed as overage. The ladder does not restart: if your plan's usage has already carried you past the early brackets, overage continues from where it reached, not at $3 per 1,000.

With overage off, requests pause when the allowance is spent and resume when the plan renews. On top of either setting you can set spend caps: one for the account, in dollars, and one per workspace, in credits. Reaching a cap stops new requests.

Which setting is right is a product decision, not a billing one. A live inventory feed may value continuity and allow overage; a research batch with a fixed budget may prefer a hard stop. Choose before the workload reaches its allowance, rather than finding out from a paused pipeline.

One balance across the products

A product-data pipeline might fetch pages through the Crawling API, push nightly refreshes through the Enterprise Crawler and keep selected pages in Cloud Storage. All three spend from the same balance, each by its own rule. The Web MCP Server itself is free; the API requests it makes cost what they would cost if you called the API directly. Accounts that still hold a legacy Smart AI Proxy package keep billing on that package until they move to a plan.

One shared pool does not remove the need to track usage per workload, but it does mean you watch one balance instead of a prepaid budget per integration.

What gets billed

You pay for successful requests. A request is billed when Crawlbase got a usable answer from the site: the page itself, a redirect it followed, or a genuine 404 or 410, because "this page no longer exists" is a real answer. Blocks such as 403 and 429, timeouts and Crawlbase-side failures are not billed.

That makes unreliable targets cheaper to work with, because the attempts that fail do not reach the bill. It does not make failures free in every sense: they still use concurrency and time. Keep sensible timeouts and retry limits, and watch the success rate, because success-based billing reduces wasted spend without replacing good request management.

Estimate a month before you scale

1. Estimate successful volume for each workload, not the number of URLs in the queue.
2. Split it by tier and rendering, using the Playground to find each domain's tier.
3. Add the extras, especially screenshots and pages you keep in Cloud Storage.
4. Compare pay as you go with a subscription, then decide on overage and spend caps.

The calculator handles the ladder and the common multipliers. After the first production runs, compare the estimate with the credits you actually used and adjust. For the background on why Crawlbase bills per successful request, see Crawlbase pricing explained.

Conclusion

The useful property of one balance and one rate card is not that every workload ends up with the same unit cost. It is that cost becomes something you can reason about across a system with several moving parts: check each site's tier, account for rendering and storage, choose how to pay, and decide in advance what happens when the allowance runs out.

Compare the plans and run the numbers on the pricing page, or create a free account and test your own target sites before you commit to anything.

Frequently Asked Questions (FAQs)

Does every request cost the same number of credits?

No. A successful request to a standard site costs one credit. Harder sites carry a multiplier from 1.5 up to 20, JavaScript rendering doubles the site's tier, a screenshot is billed as a rendered request, and storing a page adds half a credit.

Am I charged for failed or blocked requests?

No. Blocks such as 403 and 429, timeouts and Crawlbase-side failures are not billed. A request is billed when it returns a usable answer from the site, which includes a genuine 404 or 410 for a page that no longer exists.

If my subscription runs out and overage is on, does pricing start again at the top bracket?

No. Overage continues from the bracket your usage has already reached instead of restarting at the highest rate. If overage is off, requests pause until the plan renews, and allowances reset every monthly billing cycle.

Can I use the same credits across different products?

Yes. The Crawling API, the Enterprise Crawler, Smart AI Proxy, Cloud Storage and the API calls made through the Crawlbase Web MCP Server all draw from the same balance, each by its own rule. Accounts still on a legacy Smart AI Proxy package bill that traffic on the package.

How long does Cloud Storage keep a page?

Thirty days. Storing a page adds half a credit to the request that fetched it, and reading it back is free.

NZ

Neil Zamora

Senior Architect · Crawlbase

Senior architect at Crawlbase, focused on the systems behind large-scale crawling: proxy rotation, anti-bot resilience, and the APIs that hide that complexity.

IK

Ian Kalvin

Technical Support Engineer · Crawlbase

Technical support engineer at Crawlbase, writing from the front line of what actually breaks in production scraping and proxy setups.