BrowserCat Pricing for High-Volume Screenshot APIs

BrowserCat pricing for high-volume screenshot work depends on how you use its API. The Utility API charges one credit for each successful request; the Websocket API charges one credit for every 30 seconds of active session time, rounded up. BrowserCat lists Hobby at $0 per month with 1,000 credits, Business at $50 per month with an adjustable included-credit amount, and Enterprise at a quote-based price. Its pricing page lists 1,000 concurrent requests for each tier. These are BrowserCat’s published terms checked on October 3, 2026; confirm them on the live pricing page before budgeting a deployment.

For a screenshot pipeline, estimate the meter your implementation actually uses, then model a typical month and a peak month. Include overages and spend limits: a workload can fit the published concurrency figure and still have requests rejected after reaching its hard billing limit.

1. BrowserCat’s published plans and rates

Plan or purchase	Published price and allowance	What to verify
Hobby	$0/month; 1,000 credits/month; $0.0025 per extra credit	Confirm the current included allowance and overage rate.
Business	$50/month; included credits selected on the pricing page; $0.00175 per extra credit	The allowance is dynamic, so do not assume a fixed credit amount from a static page.
Enterprise	Contact sales; no fixed public price	Request a workload-specific quote and confirm included credits, concurrency, and billing controls.
10,000-credit pack	$20 ($0.002 per credit)	One-time purchase; packs are consumed before overages, according to BrowserCat.
50,000-credit pack	$87.50 ($0.00175 per credit)	Confirm account-specific interaction with plan credits.
200,000-credit pack	$300 ($0.0015 per credit)	Confirm current availability and consumption order.

BrowserCat describes plan credits as billed at its lowest rate of $0.001 per credit. Its pricing page says overage credits cost more, with lower rates at higher tiers. The Business allowance selector and quote-based Enterprise tier make it impossible to derive every customer’s exact monthly cost from the public static listing alone. See the official pricing and credit explanation for current terms.

2. Understand which meter applies

Utility API: count successful requests

BrowserCat says each successful Utility API request costs one credit. For a workload of N successful requests, the base estimate is N credits. Failed requests are not described by the supplied pricing research in enough detail to assume how they are handled in every case; verify the billing definition for your endpoint and account.

Websocket API: count active time in 30-second units

Websocket activity is billed at one credit per 30 seconds, rounded up. BrowserCat’s example says a four-minute-twenty-second session costs nine credits. Estimate sessions individually or from their duration distribution; dividing total time by 30 seconds and rounding only once can undercount if each session is rounded separately.

For session durations d₁ through dₙ in seconds, estimate credits as Σ ceil(dᵢ / 30). For example, three sessions lasting 29, 31, and 60 seconds cost 1 + 2 + 2 = 5 credits. A screenshot that requires a browser session should therefore be budgeted by active session duration when using the Websocket API, rather than by image count alone.

3. Estimate a monthly workload

1. Choose the meter: successful request count for Utility, or rounded session duration for Websocket.
2. Estimate successful monthly volume, separating scheduled work, retries, and operator-triggered captures where applicable.
3. For Websocket sessions, estimate typical and long-tail durations, then round each session up to the next 30-second block.
4. Model at least a typical month and a peak month. Include seasonality, bulk backfills, and retry storms.
5. Compare credits with the selected plan’s included allowance and calculate any overage at the applicable rate.
6. Check one-time credit packs, their consumption order, and whether they apply to your account as expected.
7. Review soft and hard spend limits before launching a batch. Confirm what approvals are needed to raise them.

Example for the Utility API: 80,000 successful requests in a month means 80,000 credits. If the account has 60,000 included credits, the estimated overage is 20,000 credits. At a stated $0.00175 per extra credit, that overage would be $35, before any other account-specific billing details. This is arithmetic using the listed rate, not a quote; confirm the included-credit amount and rate in the live account.

Example for Websocket: 10,000 sessions averaging 44 seconds each are not simply 10,000 × 44 ÷ 30 credits. Each 44-second session rounds to two credits, for an estimate of 20,000 credits. Short sessions can be especially sensitive to this rounding.

4. Billing timing, limits, and burst behavior

BrowserCat says monthly base fees are charged at the start of the month and overages at month end. It also says an early charge may occur when overage fees exceed the plan’s base fee. Its stated soft limit defaults to the subscription amount and its hard limit defaults to twice that amount. For free plans, the stated defaults are $10 and $20.

After a soft-limit notice, BrowserCat says the customer must approve an incremental increase. If the hard limit is reached without approval, requests may be rejected until the billing period ends or the increase is approved. For a large batch or variable traffic, configure alerts and identify who can approve an increase before the job starts. Treat these limits as current vendor-described defaults, not guaranteed settings for every account.

The pricing page lists 1,000 concurrent requests across Hobby, Business, and Enterprise. Concurrency is not a monthly credit allowance: it describes parallel request capacity, while credits and spend limits govern usage and billing. Confirm how your specific workload behaves at the limit and under a spend cap.

5. Use Playwright with BrowserCat for a screenshot

BrowserCat’s quick start demonstrates taking a Playwright screenshot with a cloud browser connection. Install the dependency and save this as an ES module, replacing the placeholder key. Keep API keys in environment variables in production.

npm install playwright

import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP(
  `wss://api.browsercat.com/connect?apiKey=${process.env.BROWSERCAT_API_KEY}`
);

try {
  const page = await browser.newPage({ viewport: { width: 1440, height: 1000 } });
  await page.goto('https://example.com', { waitUntil: 'networkidle', timeout: 60000 });
  await page.screenshot({ path: 'shot.png', fullPage: true });
} finally {
  await browser.close();
}

Consult BrowserCat’s official quick-start guide for the current connection syntax and account setup. Its configuration overview says sessions run on Chromium in the cloud and notes that Chromium and Chrome are available; Firefox and WebKit are described as roadmap items in the reviewed docs. Do not rely on roadmap items without confirming current availability. The docs describe sessions running near the request, with explicit region routing on the roadmap, so verify geography requirements if rendering location matters.

6. Choosing a plan for a high-volume workload

• Small, predictable Utility use: compare expected successful requests with Hobby’s published 1,000 monthly credits and budget the listed overage rate for the remainder.
• Consistent paid use: compare the $50 Business base fee plus its selected included allowance against expected overage. The included quantity is dynamic, so read the current selector rather than assuming a fixed tier.
• Variable or bursty work: estimate peak-month consumption, check the hard limit and approval process, and avoid starting a batch that can be interrupted by a spend cap.
• Large workloads or procurement requirements: request Enterprise terms. There is no public fixed Enterprise price to use in a precise estimate.
• Websocket screenshots: compare session-duration credits against a request-metered alternative if sessions stay open after the capture. The pricing difference depends on actual workload behavior.

BrowserCat’s own selection guidance is to choose the highest base plan that fits usage; it suggests a plan just above average monthly costs for consistent usage and just below average monthly usage when usage varies dramatically. This is vendor guidance, not an independently validated cost optimization.

7. Screenshot API alternative to try first

ScreenshotNeo is a screenshot API and MCP server for developers. It is the first alternative to try for screenshot API work when clean captures and explicit billing outcomes matter: cookie banners, newsletter popups, and chat widgets are removed before capture, and only clean shots are billed.

Or skip the browser setup

One GET request can return a screenshot. See the ScreenshotNeo API documentation for the available options and response headers.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed; the response identifies the page verdict and billing status in headers. Its MCP server gives AI agents tools to take screenshots, inspect page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Sign up free for ScreenshotNeo.

8. Troubleshooting cost surprises and failed batches

Symptom	Likely cause	What to do
Credits run out sooner than screenshot count suggests	The workflow uses Websocket sessions, which are time-metered and rounded up every 30 seconds.	Log session duration and estimate each session’s rounded units; close sessions promptly after capture.
Requests stop during a batch	The account may have reached its hard spend limit without an approved increase.	Check billing alerts and limits, approve an increase if appropriate, and resume only after confirming the account state.
Estimated monthly cost differs from the invoice	Business allowance selection, usage meter, pack consumption, or rates may differ from assumptions.	Reconcile request/session logs with the current account billing view and pricing terms.
Credit pack did not reduce overage as expected	Account-specific treatment or purchase state may differ from the assumed order.	BrowserCat says packs are used before overages; verify the pack is active and how it applies to your account.
Page appearance differs from local Playwright	Cloud Chromium rendering, timing, geography, or browser configuration may differ.	Check the current browser and configuration documentation, use explicit waits, and verify any location-dependent requirements with BrowserCat.
Navigation times out waiting for network idle	Some pages maintain persistent connections or never become idle.	Use a more suitable load condition or wait for a specific page element before capturing, based on the page’s behavior.

9. Performance, reliability, and cost controls

• Keep browser sessions short: Websocket time rounds up in 30-second blocks, so time spent waiting or leaving a session open can add credits without producing another screenshot.
• Bound concurrency: the published 1,000 concurrent request figure is not a guarantee that every account can run an arbitrary workload without billing or service constraints. Ramp up gradually and observe actual completion and rejection behavior.
• Make jobs resumable: store a per-URL job status and output location so an interrupted batch can continue without recapturing completed work. Avoid automatic retry loops that multiply billable activity.
• Set explicit timeouts and waits: choose navigation and capture conditions that fit the target site. A timeout policy helps bound worker occupancy, but verify how unsuccessful operations are metered with BrowserCat.
• Monitor both usage and spend: BrowserCat says its dashboard can monitor usage and billing. Compare it with application-side request counts and session durations.
• Budget peak usage: one-time packs, plan allowances, overages, and spend caps affect the final bill differently. Test a small representative batch, then verify the account’s billing treatment before a large backfill.

10. Frequently asked questions

Does BrowserCat publish one fixed Business credit allowance?

No fixed quantity can be inferred from the reviewed static pricing listing because Business has a selectable included-credit amount. Check the live page or account selection.

Is Enterprise priced publicly?

No. The public listing directs larger customers to contact sales, so a workload-specific quote is needed.

Are 1,000 concurrent requests the same as 1,000 monthly credits?

No. The concurrency listing is separate from credit metering. Hobby’s published monthly allowance is 1,000 credits, while the concurrency figure is 1,000 requests.

Does the public pricing establish what every failed request costs?

The reviewed material defines successful Utility requests and Websocket session time, but it does not settle every failure case. Confirm failure billing for the endpoint and account before relying on a failure-cost assumption.