Web Scraping API Credits Explained: Why Your Bill Is Higher

What is a credit in web scraping API pricing?

A credit is an abstraction the vendor invented so it can charge different amounts for different work without publishing a separate price list for every feature. One credit usually maps to one straightforward page fetch. From there it diverges: rendering JavaScript, running an LLM extraction step, routing through a residential proxy or searching rather than fetching can each cost a multiple of the base rate.

This is not dishonest, and every vendor documents it. The problem is that the credit table lives in the docs while the credit count lives on the pricing page, so people compare two plans by credit count and assume the plans are comparable. They frequently are not. A 100,000 credit plan at one vendor and a 100,000 credit plan at another can differ by five times in pages delivered.

Why is my web scraping API bill higher than the plan price?

Because the plan price buys an allowance, and four separate mechanisms spend that allowance faster than a naive page count predicts. Here they are in the order they usually bite.

The first row is the one that surprises people most, because it can fire without you choosing it. Firecrawl, for example, publishes three proxy modes: basic at 1 credit per page, enhanced at 5, and auto, which tries basic and retries on enhanced when a page is blocked. Auto is the default. If you never set the parameter and a tenth of your target list is defended, roughly a tenth of your crawl silently bills five times the rate you budgeted. That is documented behavior rather than a trick, but it is easy to miss when you are estimating from a plan price.

How much does one page actually cost?

Divide the plan price by the pages the plan realistically delivers. Below are published US list prices checked in August 2026 on each vendor's own pricing page, converted to a cost per page at the base rate. We have included ourselves, and the entry tier comparison does not flatter us.

Two honest caveats about that table. Firecrawl publishes its ladder at the annual-billing rate, so paying monthly costs more than the figures shown, and it has a free tier of 1,000 credits where we have no free plan at all. If you are scraping a few thousand pages a month and want to try before paying, Firecrawl is the better starting point and we would rather say so than pretend otherwise. The full ladder for every vendor we track sits in our web scraping API pricing comparison.

What is a compute unit in Apify?

A compute unit is one gigabyte of memory running for one hour. Apify meters Actor runs in those units rather than in pages, at $0.20 per unit on the Free and Starter plans, $0.16 on Scale and $0.13 on Business. Residential proxy bandwidth bills separately at $7 to $8 per gigabyte.

The consequence is that cost per record is a property of the Actor, not of the platform. A lightweight Actor hitting a fast JSON endpoint might return thousands of records per compute unit. A heavy one driving a full browser through a slow, JavaScript-rich site might return a few hundred. Two teams pulling identical monthly volumes can see very different invoices, which is why estimating an Apify bill from a page count does not work and why running a sample is not optional. The trade-off in the other direction is real too: if a maintained Actor already handles a site's pagination and rate limits, you are buying working code as much as compute. We compare that trade in detail in Apify vs Firecrawl.

Do web scraping API credits roll over?

Usually not, and this is worth checking per tier rather than per vendor. Firecrawl expires unused credits monthly on its self-serve plans and offers rollover only on Scale and Enterprise. Apify's included usage allowance expires each month as well. For a steady workload that hardly matters. For a spiky one, where you crawl hard in week one and barely touch the API afterward, it means paying for capacity you structurally cannot use.

If your volume swings a lot, a per-record model that only bills successful deliveries can work out cheaper than a monthly allowance, even at a higher unit rate. That is the genuine argument for the enterprise proxy platforms over a subscription tier, and it applies regardless of which vendor you prefer.

How do I estimate a web scraping bill before I buy?

Five steps, in order. This takes an afternoon and routinely changes which plan people buy.

1. Take a real sample. Pull 200 URLs from the target list you actually intend to crawl, not a tidy subset of easy ones.
2. Measure the block rate. Fetch them with a plain HTTP client, a real user agent and a courteous delay. Count how many return the content you expected. That percentage is your premium-proxy exposure.
3. Count how many need rendering. Search each raw response for a string you can see in the browser. If it is missing, that page needs JavaScript rendering and may cost more.
4. Apply the multipliers. Base rate for the clean pages, the premium rate for the blocked share, and any extraction surcharge on top. Now you have a defensible cost per page.
5. Add the engineering line. If the output is raw HTML or generic JSON, someone writes and maintains a parser per site. That cost never appears on a pricing page and it is often the largest number in the exercise.

Step five is the one teams skip and later regret. An API returning HTML at half the price of one returning typed JSON is not cheaper once a developer spends two days a month keeping selectors alive. It is also worth setting a hard budget threshold on the account so that a runaway crawl tells you the same day rather than at the end of the billing period, because the failure mode with usage-based pricing is a loop that retries forever against a site that is refusing you.

Which billing model should you choose?

Match the model to the shape of your workload rather than looking for the lowest headline number. Flat per-page pricing suits predictable, ongoing crawls of ordinary public pages, because you can forecast it and there is nothing to tune. Usage metering by compute suits occasional, heavy jobs against specific hard targets, where a prebuilt scraper saves you real engineering. Per-successful-record pricing suits volatile workloads with a poor success rate, because failures cost nothing.

What almost never works is buying the cheapest entry tier and hoping the multipliers do not apply to you. They apply to everyone; the only variable is what fraction of your target list triggers them. If most of your sources are documentation, company sites, blogs and public directories, that fraction is small and a flat per-page plan is the simplest correct answer. If your sources are marketplaces and travel sites, budget for the premium path on most of the crawl and pick a vendor built for it. Our guide on whether you need a proxy network at all walks through that measurement, and how much a web scraping API costs covers the wider market.

For the record, ClawEngine bills whole pages with rendering and schema extraction included in the call rather than metered as extras, which is a deliberate choice to make the estimate above unnecessary. That works because we only crawl public, permitted pages and do not try to defeat anti-bot systems. It is a narrower product, and on a defended target list it is the wrong purchase.