Beating bot detection without overpaying for it

When a site fights back, the instinct is to reach for a bigger hammer: a real browser with full stealth. It usually works. It's also usually overkill, and at any kind of volume, the overkill is the part that costs you.

There are two ways to get this wrong. One is loud: fire plain HTTP at a site that fingerprints TLS handshakes, and you get back a wall of 403s. The other is quiet. You send a stealthed browser to fetch a static blog post, it works perfectly, and you've just spent a full browser's worth of time and money on content that was sitting in the response body the whole time. The first mistake shows up immediately. The second one only shows up on the bill.

So we built the stack around a single rule: use the lightest fetch that actually works, and reach for the stealth browser only when a target needs it.

The fetch tiers

There are two. Every request runs on the cheap tier by default, and you step up to the stealth browser only for the targets that need it.

1. Fast HTTP. A fast request that carries a real browser's TLS and header fingerprint, so it isn't flagged the moment it connects. No browser, no JavaScript — just a clean fetch of what the server returns. This clears most of the open web: static pages, APIs, server-rendered content, most articles.
2. Stealth browser. For the hard targets — JavaScript-heavy pages, aggressive anti-bot, or content that only appears once you interact with the page — we load the page in our own hardened, anti-detection Chromium build. It runs the scripts, handles the interaction, and returns the fully rendered result. It's the expensive tier, and the only one that adds a credit surcharge, because a full browser costs the most to run.

Fast HTTP is the default, and it clears most of the open web on its own. Stealth is opt-in: the stealth browser runs only when you ask for it, because it's the most expensive tier — so the decision to pay for it stays with you.

Why the cheap default matters

Cost and latency both climb with how much machinery a fetch needs:

Send everything through the stealth browser and you overpay on every easy page. The default keeps the easy majority — which is most of the web — at the base rate, and you spend on a browser only for the targets that actually need one.

This is also where JavaScript comes in. A client-rendered page can answer fast HTTP with a 200 and an almost-empty shell, because the real content only appears once its scripts run. That's exactly the case stealth mode is for: it loads the page in a real browser, runs the scripts, and hands back the fully rendered result.

Stealth is a last resort

# No stealth flag: the request runs on fast HTTP, the cheap default.
curl https://api.webscrape.ai/v1/scrape \
  -H "X-API-Key: wsg_live_your_key_here" \
  -d '{ "website_url": "https://tough-target.example" }'

You turn on stealth mode when you already know a target needs a real browser — JavaScript rendering, interaction, or aggressive anti-bot — and want to go straight to it. But that's the exception. Most pages never need anything past fast HTTP.

Two notes on billing, since they follow from the same idea. Credits are charged on success only, so a fetch that fails costs nothing. And the stealth surcharge applies only when the stealth tier actually runs, which means only on requests you send with stealth turned on. On /v1/scrape that surcharge is two credits on top of the one-credit base, so a default request that clears on fast HTTP is billed at the base rate.

The part that matters

Most of the win here is in the default, not the stealth browser itself. A fetch that already carries a real browser's fingerprint brings back most of the web without a browser at all. Reserve stealth for the pages that truly need it, and proxy pools and browser fleets stop being something you have to think about.