A scraping API sells a document. A managed browser sells time.

Two products get sold under one sentence, "scrape without managing infrastructure", and they are not the same product. A scraping API takes a URL and hands back a document. A managed browser API hands you a browser running somewhere else and lets you operate it. Everything people fight about later, the price, the ban rate, whether JavaScript worked, follows from that first difference, so it is worth deciding on the product before comparing any numbers.

What a request-response API actually sells

You send a URL, options, and a key. You get HTML or JSON back. The vendor owns the proxies, the retries, and the rendering, and you never see any of it.

The bill is shaped by the page's difficulty, and the vendors are explicit about this once you read the credit table. We hold collected rate cards for eight of these services, read off their own documentation pages. On ScraperAPI's published costs, a normal request is 1 credit, Amazon, Walmart and eBay product pages are 5, Google and Bing search results are 25, and LinkedIn pages are 30. ScrapingBee prices the same page three ways depending on the options you switch on: 1 credit for a classic proxy without JavaScript rendering, 10 with premium residential proxies, 25 with premium proxies and rendering. The same URL, a 25x spread, and the variable is what the target site makes the vendor do.

This is the part worth internalizing before any price comparison: on this side of the market, you are renting difficulty, per page, and the credit is the unit of difficulty.

What a managed browser sells

You get a browser session and you operate it, usually with the Playwright or Puppeteer script you already have. Browserless says so in one line: a unit "is a block of browser time of up to 30 seconds per browser connection", and "longer-running automations use an extra Unit for every 30 seconds". The bill is shaped by time and concurrency, not by the target site. Browserbase prices the same shape in different words, browser hours with concurrency tiers: "100 browser hours then $0.12/browser hr", with plans named partly by "25 concurrent browsers".

Two consequences follow from billing by time. First, a fast, clean page is cheap on the browser side and expensive nowhere, while a hard page that takes the browser 40 seconds costs two units regardless of what it is. Second, the failure modes that cost money are different ones: Browserless charges because "session-reconnects count as new browser connections and incur a fresh Unit charge", and a captcha inside your session is billed as work too, at "10 Unitsper successful Captcha solve".

The wire between them

The reason these two products get confused is that the same script can point at either. Playwright's own API describes the connection: a method that "attaches Playwright to an existing browser instance using the Chrome DevTools Protocol", taking a websocket or HTTP endpoint. The difference between your laptop, a container you own, and a managed browser service is, mechanically, one endpoint URL. What changes is who pays for the machine, who owns the IP address it egresses from, and which meter is running while the session is open.

Which jobs fit which bill

An API is the honest bill when the job is many page reads that share nothing: fetch, parse, move on. The retry logic, the proxy pool, and the rendering are the vendor's problem, and the credit ladder prices the difficulty without you writing any of it.

A session is the honest bill when the job is interaction: a login that sets a cookie, a multi-step flow, a page whose content depends on what you clicked, or anything where you need to look at the page and decide. An API cannot sell you that, because the document it returns is the end of its involvement. The session also fits when your target's defenses are behavioral rather than content-based, since the fingerprint and the timing are yours to manage.

The captcha sits on both bills, and it is the clearest illustration of the axis difference. On the API side you can add a solver as a separate, per-solve service, and we hold dated per-1,000 rate cards for ten of them. On the browser side the solve is billed inside the session, as the Browserless unit charge above shows. If your pages are captcha-heavy, that one line item can decide the comparison before anything else is counted. And if you are testing captcha behavior on an app you own rather than fighting it on someone else's, that is a different job with its own tested Playwright fixture.

The third product that is neither

Anti-detect browsers get folded into this comparison and they are a different thing again: they sell identities, not sessions or documents. We track seven of them with dated plan tables, and the unit is the browser profile. AdsPower's Business 200 plan is "$61.0 /mo. billed every 30 days" for 200 persistent profiles with a local GUI to manage them. Nothing about that bill scales with pages or minutes. It is for operating many long-lived identities, which is a job neither of the other two products addresses.

Where the numbers live

For the API side, the comparison is already built: every rate card we collect, the hosted API comparisons, and a workload cost calculator that converts credits into what your pages cost. For the proxy-versus-API cost axis, the break-even math article works it through on one vendor's numbers. We hold no equivalent rate cards for managed browser services yet: the two quotations above came from reading their pricing pages on 16 September 2026, and a page of computed browser-side costs is exactly the kind of number we do not publish until it is collected properly.