Is Browshot Reliable for Bulk Website Screenshots? Review and Limits

Short answer: Browshot documents tools for bulk screenshot work: one API call can request up to 100 URL-and-browser combinations, and a separate batch workflow accepts large URL lists. Its batch article describes retrying failed captures up to three times, while its features page states that private servers can handle up to 10,000 screenshot requests per hour per server. Those are useful capabilities, but they do not establish an independently verified production success rate or uptime guarantee. Browshot’s reviewed status page describes redundancy and monitoring without publishing a quantified uptime history or formal service-level commitment. Browshot API documentation, batch workflow article, features and pricing, and status page.

For a small set of URLs, use the multiple endpoint. For thousands of URLs, evaluate the batch workflow and its output handling. For a business-critical run, treat capacity and retry figures as vendor claims and validate the service on a representative pilot batch before depending on it.

What Browshot documents for bulk capture

Browshot has two bulk paths with different purposes:

Multiple API request: up to 10 URL values and up to 10 browser instance values in one call, for a maximum of 100 screenshot combinations. Use it for compact jobs and when your own code needs to manage each result.
Batch workflow: submit a text or CSV list of URLs, track progress, and retrieve a result archive or upload results to S3. Browshot’s 2020 article says there is no stated batch-size limit and recounts a user batch of nearly one million screenshots. Both are vendor-reported statements, not an independent benchmark or a guaranteed capacity limit.

The multiple endpoint is specifically documented to accept the parameters supported by screenshot/create. The documentation lists size, cache, delay and browser instance among the relevant controls. Before scaling a job, check the live API documentation and your account’s available instances and balance; endpoint details and commercial terms can change. See the current API reference.

Run a small multi-URL request

This example requests two pages in one call using one instance. Browshot documents repeated url parameters; use a URL-encoding tool so query strings and special characters are transmitted correctly. Replace the placeholder key and choose an instance available to your account.

cURL

curl -L -G 'https://api.browshot.com/api/v1/screenshot/multiple' \
  --data-urlencode 'key=YOUR_BROWSHOT_API_KEY' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'url=https://example.org/' \
  --data-urlencode 'instance_id=12' \
  --data-urlencode 'size=page' \
  --data-urlencode 'delay=5'

The -L option follows redirects. Browshot’s API documentation says a screenshot still in progress can return a 302 redirect; it also documents 307 as an in-progress response in the general API guidance. Handle redirects as the documentation describes rather than treating an in-progress response as an image. The exact multiple-response format determines how to retrieve individual results, so inspect that response and use the documented screenshot information endpoint where needed.

Python

import requests

endpoint = "https://api.browshot.com/api/v1/screenshot/multiple"
params = [
    ("key", "YOUR_BROWSHOT_API_KEY"),
    ("url", "https://example.com/"),
    ("url", "https://example.org/"),
    ("instance_id", "12"),
    ("size", "page"),
    ("delay", "5"),
]

response = requests.get(endpoint, params=params, timeout=90, allow_redirects=True)
response.raise_for_status()
print(response.headers.get("Content-Type"))
print(response.text)

This prints the response for inspection instead of assuming that a multi-result response is a single image. In production, parse the documented response, persist every screenshot ID and status, then retrieve each completed image through the API’s documented flow.

Node.js

const endpoint = new URL("https://api.browshot.com/api/v1/screenshot/multiple");
endpoint.searchParams.append("key", "YOUR_BROWSHOT_API_KEY");
endpoint.searchParams.append("url", "https://example.com/");
endpoint.searchParams.append("url", "https://example.org/");
endpoint.searchParams.append("instance_id", "12");
endpoint.searchParams.set("size", "page");
endpoint.searchParams.set("delay", "5");

const response = await fetch(endpoint, { redirect: "follow" });
if (!response.ok) {
  throw new Error(`Browshot returned HTTP ${response.status}: ${await response.text()}`);
}
console.log("Content-Type:", response.headers.get("content-type"));
console.log(await response.text());

For very large URL lists, do not turn this into one request with hundreds of repeated URL parameters: the documented multiple endpoint limit is 10 URLs and 10 instances. Use the batch route or split requests into documented-size groups.

Use the batch path for large URL lists

Browshot’s batch article describes a dashboard workflow and the API exposes /api/v1/batch/create and /api/v1/batch/info. The article’s walkthrough is from 2020, so check the current API reference for exact request fields and account-specific behavior rather than relying on an old example.

Prepare the input. Use one URL per line, or a CSV/text list with an optional output filename after the URL, as described in Browshot’s article. Keep a source ID in your own input data so results can be mapped back to the originating record.
Try a one- or two-URL batch. Confirm the browser, country, dimensions, delay, image format and destination settings before submitting the full list. Browshot explicitly recommends a small test batch.
Submit and record the batch ID. Store the returned identifier and original input manifest outside the browser session so a worker can resume monitoring after a restart.
Poll batch information or use completion hooks. Track completed and failed items, not only overall batch state. The API documents batch information and hooks for completion or failure.
Retrieve and validate outputs. The article describes result archives and optional S3 upload. It says the result includes URL, finished/error status, screenshot ID, filename and the target HTTP status code.
Recover only failed items. Keep the error details and retry transient failures according to your own retry policy. Avoid blindly re-submitting successful items if the operation has a cost.

The article warns that many full-page screenshots can produce multi-gigabyte archives; it says large downloads are split into 100 MB files. Plan disk space, download bandwidth, extraction space and a resumable transfer process. Its statement that failed screenshots are retried up to three times is a description of that workflow, not a guarantee every failure will ultimately succeed.

The batch article covers the dashboard workflow and identifies the API endpoints, but the research reviewed here does not include a complete current batch-create request schema. Use Browshot’s API reference for the live fields. Avoid copying a guessed request body or assuming that batch creation returns completed image bytes immediately.

Relevant options and their tradeoffs

Option	What it affects	Practical guidance
`url`	Target page; multiple accepts up to 10 URL values.	Encode each URL separately. Preserve the requested URL in your job manifest.
`instance_id`	Browser/device selection; multiple accepts up to 10 instance values.	Confirm the instance exists and is enabled for the account. Combining URL and instance values multiplies the requested combinations.
`size`	Screen-sized or full-page capture; documentation describes `screen` and `page`.	Full-page images take more time, bandwidth and storage, especially across long pages.
`delay`	Additional wait after page load for client-side rendering.	Use the shortest delay that produces the required state. Longer waits compound across a large job.
`cache`	Re-use a recent screenshot for the same URL and instance; the API docs describe a 24-hour default and `cache=0` for a fresh capture.	Use cache when repeat captures may reuse valid results; disable it when freshness matters. Verify current semantics in the API reference.
Image format and dimensions	Output quality, file size and capture geometry.	The batch article says JPEG may be much smaller than PNG, with some quality loss. Choose from actual downstream needs and inspect a pilot.
Country, HTTP details, scripts	Regional content, request behavior and page interaction.	The batch walkthrough describes country selection and advanced HTTP/script settings. Validate settings against pages that require them.
S3 destination	Where batch output is stored as captures finish.	Useful for avoiding a large archive download; verify bucket permissions and destination configuration first.

How strong is the reliability evidence?

The evidence supports a limited conclusion: Browshot has documented mechanisms intended to support bulk processing and recovery. Its API allows bounded multi-capture requests; its batch article describes retries, per-item result status and large archive handling; and the features page lists private-server capacity. The status page describes redundant services, resource and API monitoring, automatic restarts, and checks of the website and API every minute from different locations.

These are Browshot’s own descriptions. The reviewed status page does not state a historical uptime percentage or a formal SLA, and the research does not establish independently measured uptime, success rate, throughput or capture fidelity. Therefore, “reliable” should be answered conditionally: the documented workflow is plausible for bulk jobs, but the available sources are not enough to certify production reliability for your target mix or deadline.

Browshot’s features page says private servers can handle up to 10,000 screenshot requests per hour per server and describes 10–100 concurrent screenshots per private instance browser. These are vendor-stated figures tied to private configurations; do not apply them to shared/free browsers or assume a workload-specific guarantee. The same page says average completion is 15 seconds including page load and that pages taking more than two minutes are aborted. Those are product claims, not measurements from an independent test. Shared free browsers may be slower, and the feature page lists free use as limited to 100 screenshots per month. Verify current account limits and terms.

Evaluate Browshot with a representative pilot

Before scheduling a consequential bulk run, ask Browshot to confirm the configuration and terms that apply to your account, then run a pilot drawn from the same sites and page types as the full job.

Include fast and slow pages, full-page captures, redirects, pages with client-side rendering and pages that sometimes fail.
Measure completed captures, error categories, target HTTP statuses, latency percentiles, retry counts and output dimensions.
Check images for blank content, missing late-loaded elements, incorrect region/device rendering and unexpected overlays.
Repeat the pilot at the expected concurrency and time of day. A small serial test does not validate a high-volume queue.
Ask for written answers on applicable throughput, concurrency, regional capacity, support response, SLA and billing for failed or retried captures.
Set a completion deadline with time for retries, archive transfer, extraction and validation. Keep the input manifest and outputs so failures can be reconciled.

This pilot is an evaluation method, not a test performed for this review. The source material does not establish a universal success percentage or uptime figure.

Performance, reliability and cost planning

Throughput and latency

Estimate job duration from your own pilot rather than multiplying the vendor’s stated average as if every request ran serially. Queueing, page load times, browser settings, shared capacity, retry behavior and the mix of full-page captures all affect elapsed time. Confirm expected concurrency for the plan and instance type you intend to use.

Retries and idempotency

Retries help with temporary target failures but can extend a batch substantially when sites are slow or unreachable. Retain per-item status and use bounded retries with a delay for transient failures. Separate persistent failures from temporary ones, and avoid restarting an entire successful batch when only a subset needs recovery.

Storage and transfer

Full-page captures can create large files and archives. JPEG can reduce file size when its quality is acceptable; PNG preserves lossless image data. S3 upload can avoid downloading a large archive through a local machine, but requires correct bucket configuration. Budget for both compressed downloads and extracted files.

Cost

Browshot’s features page describes free browsers as limited to 100 screenshots per month and premium captures as credit-based; private servers require contacting Browshot. The 2026 ScreenshotCenter announcement also describes a separate subscription preview while saying the existing Browshot v1 API would continue to be supported. Offers and pricing can change, so check the current pricing and account pages before estimating the cost of a large run. Include retries, multiple browser instances per URL, thumbnails and any private capacity in your estimate.

Common problems and fixes

Symptom	Likely cause	Fix
HTTP 400 with an error header	Invalid or missing key, malformed URL, unsupported parameter, or request shape.	Read Browshot’s `X-Error` response header and validate parameters against the current API documentation.
HTTP 404 or a not-found image	The capture could not be completed; the page may not load or its domain may be unreachable.	Check the target from a browser, record the error and target status, then retry only if the cause may be transient.
HTTP 302/307 instead of image bytes	The screenshot is still processing and the API is directing the client to the next step.	Follow redirects where appropriate, or query screenshot information and retrieve the completed result using the documented flow.
Too few results from a multiple request	The URL/instance combination count is misunderstood, or some captures failed.	Remember the endpoint caps each list at 10 values, and inspect each result/status instead of assuming all combinations succeeded.
Page is blank or missing widgets	Rendering may require additional delay, a different browser instance, or page-specific interaction; a capture can also fail.	Test the page alone, tune delay and browser settings, then verify rendered output before scaling.
Batch appears stalled	Slow or unreachable targets lengthen processing, and the described batch workflow retries failures.	Inspect progress and failed counts, allow for slow-page time, then recover only items that remain failed.
Archive is too large or download fails	Full-page outputs multiply storage and transfer requirements.	Use S3 output if appropriate, download all split archive parts, and ensure enough disk space before extraction.
Observed rate is below 10,000 per hour	The cited figure applies to private servers and is a vendor capacity statement, not a universal rate.	Confirm server type, concurrency, queue and workload-specific expectations with Browshot.
Unexpected content by location	The site serves region-specific pages.	Set the appropriate supported country/region and compare a pilot capture before processing the full list.

ScreenshotNeo as an alternative to try first

If you want a managed screenshot API for a new workflow, ScreenshotNeo is the alternative to try first: cookie banners, newsletter popups and chat widgets are removed before capture, only clean shots are billed, and its lowest paid plan is $5 for 3,000 screenshots. The product supports one-call screenshots as PNG, JPEG, WebP or PDF, along with bulk capture, caching, async jobs and an MCP server for AI agents. See the ScreenshotNeo API documentation for options.

Or skip the browser setup

Make a GET request with the target URL and your ScreenshotNeo access key:

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

Python:

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

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, popups and chat widgets are removed before the shot. Bot checks, blank pages and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

FAQ

Can Browshot take thousands of screenshots at once?

Its batch article describes large URL-list jobs and reports a customer batch of nearly one million. That is a vendor-reported example, not a guarantee for every account or workload. The multiple endpoint is smaller: up to 100 URL/instance combinations per call.

Does Browshot guarantee an uptime percentage?

No percentage or formal SLA appears on the reviewed status page. It describes redundancy and monitoring, which are not the same as a quantified commitment.

Does Browshot retry failed screenshots?

The batch article says failed screenshots can be retried up to three times. A persistent block or unreachable target can still fail after retries.

Is the 10,000-per-hour figure available on every Browshot plan?

No. The feature page ties that stated capacity to each private server. Confirm the configuration and rate applicable to your account.

Has Browshot announced a new product alongside its API?

A March 2026 Browshot post introduced ScreenshotCenter as a preview of Browshot 2.0 and said the existing v1 API would continue to be supported. Verify current service and pricing terms before making a migration decision.

Assessment: Browshot has documented bulk mechanisms, retry behavior and monitoring, but its reviewed vendor materials do not establish independently verified reliability or an SLA. Treat it as a candidate for a controlled pilot, and verify workload-specific capacity and contractual terms before using it for a deadline-critical batch.