Quick answer: A credit is the billing unit scraping APIs use instead of "per request," because requests have wildly different costs to serve. A basic fetch typically costs 1 credit, while JavaScript rendering, stealth browsers, residential proxies, or screenshots multiply that to 2x, 5x, sometimes 25x. To estimate your monthly need, classify your URL mix by difficulty, apply the provider's multipliers, and add 10-20% for retries.
If you've ever compared scraping API pricing pages and felt like you were comparing airline fares, this post is the decoder ring.
Why credits exist at all
It would be simpler if providers charged per request. Some do. But the cost of serving a request varies by two orders of magnitude:
- A plain HTTP fetch: milliseconds of CPU, a few hundred KB of cheap datacenter bandwidth. Fractions of a cent.
- A stealth browser session through a residential proxy: seconds of a full Chrome instance, megabytes of bandwidth that the provider buys per GB at residential rates, plus the amortized cost of the anti-bot cat-and-mouse team.
If a provider charged one flat price, easy requests would subsidize hard ones, and customers with easy workloads would overpay massively. Credits let the price track the actual cost. That's the charitable read, and it's mostly true.
The less charitable read: multipliers also make headline prices look better ("$49 for 100,000 credits") than effective prices ("which is 4,000 pages if your sites need stealth"). Both things are true at once, which is why you need to do the math on your own mix.
The typical multiplier ladder
Exact numbers vary by provider, so treat these as the industry pattern rather than anyone's rate card:
| Request type | Typical credit cost | Why it costs more |
|---|---|---|
| Basic HTTP fetch | 1 | Cheap compute, datacenter bandwidth |
| JS rendering (headless browser) | ~2-10x | Full browser session, more bandwidth, longer runtime |
| Stealth / premium anti-bot | ~5-25x | Hardened browsers, ongoing evasion R&D |
| Residential or mobile proxy | often stacked on top | Per-GB residential bandwidth is expensive |
| Screenshot / PDF capture | extra multiplier | Rendering plus storage plus transfer |
| Search (with content) | provider-specific | One query fans out into many fetches |
The pattern to internalize: anything that requires a real browser or a residential IP multiplies the price, because it multiplies the provider's cost. This maps directly onto the escalation ladder I described in curl vs headless vs stealth browser.
How to estimate your monthly credit need
Don't guess from the pricing page. Do this instead:
- Sample your real workload. Pull 100-500 URLs you actually intend to fetch, weighted the way production will be.
- Classify by difficulty. What fraction is plain server-rendered HTML? What fraction needs JS rendering? What fraction sits behind Cloudflare or DataDome? (Here's how to tell which method a site needs.)
- Apply the multipliers. For example, with a 70/20/10 easy/rendered/protected split and multipliers of 1/5/10, the blended cost is 0.7 + 1.0 + 1.0 = 2.7 credits per page.
- Add retry overhead. Real pipelines refetch failures and dead pages. 10-20% is a sane buffer.
- Multiply by monthly page count. 50k pages at a blended 2.7 credits plus 15% overhead is roughly 155k credits/mo.
That blended-credits-per-page number is the only figure that lets you compare providers apples to apples.
How link.sc credits work
Since I can speak precisely about my own product: link.sc uses the same credit model, with a design goal that you shouldn't have to pick the tier yourself. The API tries the cheapest method that works for a given domain and escalates automatically, so you're not paying stealth prices for sites that a plain fetch handles.
The plans: free tier with 500 credits/month, $19/mo for 3,000 credits, $99/mo for 100,000, and $399/mo for 500,000. Full details on the pricing page.
A fetch is one call regardless of what happens behind it:
curl "https://link.sc/v1/fetch?url=https://example.com/article" \
-H "Authorization: Bearer lsc_your_key"
You get clean markdown back; the response tells you what the request cost, so your estimates stay calibrated instead of drifting.
The fine print that actually matters
Credit models are fine. The gotchas live in the terms around them. Before committing to any provider (including us, verify everything), check:
Do credits expire? Monthly-reset credits punish spiky workloads. If you scrape heavily one week a quarter, you want rollover or at least an annual pool.
Is there a minimum commitment? Some providers only sell hard tiers on annual contracts or high-minimum plans. The pricing page number and the number you can actually buy at your size may differ.
What happens on overage? Three common behaviors: hard stop (your pipeline dies mid-month), automatic overage billing (fine if the rate is sane, dangerous if it's a multiple of the plan rate), or auto-upgrade to the next tier. Know which one you're signing up for before a busy month finds out for you.
Do you pay for failures? The best answer is that failed requests cost nothing. Some providers charge for attempts. This single policy can change your effective cost by 30%+ on hard sites, because hard sites fail a lot.
Is the multiplier table public and stable? If you can't find the multipliers without talking to sales, budget conservatively.
Credits vs per-GB vs per-success
Two other billing models exist and are worth a sentence each. Per-GB (common for raw proxy products) makes your cost depend on page weight, which you don't control; a bloated site literally costs you more. Per-successful-result is the friendliest framing but usually comes with higher unit prices to cover the failures baked in.
Credits sit in the middle: more predictable than per-GB, more transparent than per-success, and easy to sanity check as long as the multiplier table is public. If you're still deciding whether an API makes sense at all versus rolling your own, the cost math in how much web scraping costs at scale is the companion piece to this one.
The one-line takeaway: never compare providers by credits per dollar. Compare them by your blended pages per dollar, computed from your own URL mix.
Want to see what your URLs actually cost? Sign up free and profile your workload with 500 credits on the house.