Browshot API Rate Limits and Concurrency: What to Expect
Browshot publishes batch and screenshot-capacity figures, but no numeric per-account API rate limit. Here’s how to plan around what the docs actually say.
Browshot’s reviewed public documentation does not specify a numeric per-account API-call rate limit, such as requests per second or minute. It does publish other capacity figures: its multiple endpoint accepts up to 100 screenshot jobs in one API call, premium instances advertise 100+ simultaneous screenshots per user, private instances advertise 10–100 simultaneous screenshots per browser, and a private server is described as handling up to 10,000 screenshot requests per hour. Those are different measures; none establishes a per-account API-call ceiling. Browshot API documentation and its features and pricing page are the primary references for these claims.
1. What Browshot publishes about rate limits
Keep three quantities separate when sizing an integration:
- API calls: HTTP requests your client sends to Browshot.
- Screenshot jobs: individual URLs and browser instances requested, including jobs bundled into a batch.
- Simultaneous screenshots: rendering capacity advertised for an instance or service type.
The reviewed public documentation describes batch size, concurrency, processing load and private-server hourly throughput. It does not give a numeric API-call rate limit per account. Do not convert a batch maximum or screenshot capacity into requests per second. If your production design requires a hard account-wide API rate limit or concurrency guarantee, ask Browshot to confirm the applicable terms for your account and workload.
2. Published figures, and what they mean
| Published item | What Browshot says | What it does not establish |
|---|---|---|
| Multiple endpoint batch size | Up to 10 URLs and 10 instance IDs, for up to 100 screenshots in one API call. | That all 100 jobs run at once, or a request-per-second limit. |
| Premium instances | 100+ simultaneous screenshots per user. | A ceiling for API calls or a workload-specific guarantee. |
| Private instances | 10–100 simultaneous screenshots per browser, described as guaranteed. | An account-wide API request rate. |
| Private server | Up to 10,000 screenshot requests per hour per private server. | 10,000 API calls per hour per account, or the number of servers assigned to an account. |
These are Browshot’s published descriptions. The capacity page does not state a publication year or define a workload benchmark for its hourly figure, so treat the figures as vendor claims and confirm their applicability before relying on them for a production commitment.
3. How batching and asynchronous processing work
Browshot documents /api/v1/screenshot/create for submitting screenshot jobs and /api/v1/screenshot/multiple for grouping jobs. The multiple endpoint’s maximum is 10 URLs multiplied by 10 instance IDs, or 100 requested screenshots per call. A batch is a submission convenience; its maximum size is not evidence that every screenshot renders simultaneously.
The API documents states including in_process, finished and error. A successful submission can therefore precede completion of the render. Use the documented status lookup flow for submitted jobs rather than treating the time to receive the submission response as the time to receive a completed screenshot.
For an integration, a sensible sequence is:
- Choose the instance type appropriate to your workload and confirm the capacity that applies to your account.
- Use batches no larger than the documented 100-screenshot maximum for the multiple endpoint.
- Record submitted job identifiers and check their status using the documented status endpoint.
- Track completion time, errors and queue growth in your own integration. The public material does not specify a universal polling interval or rate-limit retry policy.
- Keep API request rate, jobs submitted, jobs in progress and completed jobs as separate metrics.
4. Load, wait time and the simple API
Browshot’s documentation gives approximate wait expectations based on instance load: below 1 means new screenshots are processed immediately; load from 1 to 2 corresponds to about two minutes; load from 2 to 3 corresponds to about four minutes, with later bands adding about two minutes. These are approximate processing expectations, not API-call rate limits or completion guarantees.
Browshot describes its simple API as slower than the complete API. Its documentation says page rendering can take up to two minutes and instructs clients to follow HTTP 302 and 307 redirects to avoid HTTP timeouts. Make sure your HTTP client follows those redirects and set a timeout appropriate to the render flow. When using the complete API’s job and status flow, account separately for submission and render completion.
5. Free allowance, balance and capacity are separate
The documentation says the default free instance allows 100 free screenshots per month. It also says private and shared screenshot requests require a positive account balance. These are usage and account-balance conditions; they do not describe requests per second. Check the current Browshot account and pricing information when calculating spend, since the figures here answer the capacity question rather than enumerate every billing condition.
6. Planning a production workload
Estimate demand in screenshot jobs, not just HTTP calls. If each call bundles many URLs or instances, the number of jobs can be much larger than the number of requests your client sends. Conversely, a high advertised simultaneous-render figure does not prove that a particular account can submit calls at a matching rate.
- Batch carefully: stay within the documented maximum of 100 jobs per multiple-endpoint call.
- Separate queueing from transport: measure API response time, time waiting for rendering, and final completion independently.
- Use explicit client timeouts: the simple API may involve redirects and pages can take up to two minutes to load.
- Monitor outcomes: capture job states, errors, completion latency and outstanding work so that a growing backlog is visible.
- Ask for workload-specific limits: confirm account-level API rate limits, expected concurrency, applicable private-server allocation and any production commitments directly with Browshot.
The reviewed public documentation does not define a safe universal polling interval, a retry policy for rate-limit responses, or an SLA-backed account-wide concurrency limit. Avoid inventing those values in a client. If Browshot returns a rate-limit or capacity error, preserve the response details, reduce request pressure while investigating, and ask support for the applicable limit and recovery guidance.
7. Runnable request examples
The following examples show a documented single-job submission shape using Browshot’s API key authentication. Consult the current Browshot API documentation for required parameters, response fields, endpoint behavior and status lookup details for your selected instance and output options. The dossier does not provide a complete, verified multiple-endpoint payload schema, so these examples do not invent one.
cURL
curl --get 'https://api.browshot.com/api/v1/screenshot/create' \
--data-urlencode 'key=YOUR_API_KEY' \
--data-urlencode 'url=https://example.com'
Python
import requests
response = requests.get(
"https://api.browshot.com/api/v1/screenshot/create",
params={"key": "YOUR_API_KEY", "url": "https://example.com"},
timeout=150,
)
response.raise_for_status()
print(response.json())
Node.js
const params = new URLSearchParams({
key: 'YOUR_API_KEY',
url: 'https://example.com',
});
const response = await fetch(
`https://api.browshot.com/api/v1/screenshot/create?${params}`,
{ signal: AbortSignal.timeout(150_000) }
);
if (!response.ok) {
throw new Error(`Browshot returned HTTP ${response.status}: ${await response.text()}`);
}
console.log(await response.json());
These snippets submit a job; use Browshot’s documented response and status endpoints to determine when it finishes. Do not assume the create response itself contains the final screenshot in every API flow.
8. Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| Client times out before a screenshot is ready | Page rendering can take up to two minutes, and the simple API is described as slower. | Allow a suitable timeout, follow 302/307 redirects where used, or use the complete job and status flow. |
Jobs remain in_process |
The job was accepted but rendering has not finished; instance load can add wait time. | Poll the documented status endpoint and track queue age. The docs do not prescribe a universal polling interval. |
Job status is error |
The screenshot job failed; this is distinct from an API rate-limit response. | Inspect the returned error details and request parameters, then correct the cause before resubmitting. |
| A batch is rejected or does not match the intended count | The multiple endpoint supports at most 10 URLs and 10 instance IDs per request. | Keep each dimension within 10 and verify the endpoint’s documented parameter format. |
| Requests fail for a shared or private instance | The account may not have the positive balance the documentation requires. | Check account balance and the applicable instance billing requirements. |
| Throughput is lower than expected | Published simultaneous capacity and private-server hourly throughput are different measures; actual applicability depends on service configuration and workload. | Measure job completion and ask Browshot to confirm capacity for your plan. Do not infer an API-call rate from the advertised throughput. |
| A client receives an HTTP error or rate-limit response | The reviewed material does not document a universal rate-limit code or retry policy. | Log status and response body, avoid an aggressive retry loop, and request the account-specific limit and recovery guidance from Browshot. |
9. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP or PDF. Its parameter names also work with those used by other screenshot APIs, which makes switching straightforward. See the ScreenshotNeo API docs.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
ScreenshotNeo accepts cookie and consent banners before capture and removes more than 60 known consent platforms, newsletter popups and chat widgets; each step can be turned off. Bot checks, blank pages and failed loads are never billed, and response headers report the page verdict and billing status. Its MCP server lets AI agents use take_screenshot, get_page_info and capture_pdf. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for ScreenshotNeo free: 1,000 screenshots a month, no card required.
10. FAQ
Does Browshot publish a requests-per-second limit?
Not in the reviewed public documentation. It documents screenshot capacity and batching figures instead.
How many screenshots can I request in one API call?
The multiple endpoint supports up to 10 URLs and 10 instance IDs, for at most 100 screenshots in a call.
Does “100+ simultaneous screenshots per user” mean 100 API calls at once?
No. It is an advertised simultaneous screenshot figure for premium instances, not a numeric API-call rate.
Can I treat 10,000 per hour as my account’s request limit?
No. Browshot describes that figure as screenshot requests per hour per private server. It does not establish account-wide API calls per hour.
What should I confirm before launch?
Ask Browshot to confirm the API-call rate limit, concurrency applicable to your account, private-server allocation if relevant, and workload-specific production commitments.


