ScreenshotAPI Rate Limits for Bulk Screenshot Requests

Direct answer: ScreenshotAPI.com’s pricing FAQ says it does not limit the speed or number of calls a customer can make per day, and says customers can adjust those settings in their account. The FAQ does not publish a numeric requests-per-minute limit, concurrency ceiling, batch-size limit, or retry-header policy. Treat this as the provider’s stated daily-call policy, not a documented guarantee of unlimited simultaneous rendering. ScreenshotAPI.com pricing FAQ

For a bulk job, verify your account settings with ScreenshotAPI.com, begin with modest concurrency, and increase it gradually while observing responses and completion times. That is cautious client-side practice; it is not a vendor-published concurrency limit.

First confirm which ScreenshotAPI you mean

Several services use similar names, and their limits are different. This article’s title refers to ScreenshotAPI.com. Limits published by screenshot-api.org, ScreenshotAPI.net, and ScreenshotAPI.to do not apply to ScreenshotAPI.com.

Provider	Published detail	Do not confuse it with
ScreenshotAPI.com	FAQ says no limit on speed or number of calls per day; settings can be adjusted in the account. No numeric per-minute or concurrency figure is stated on that page.	A stated unlimited simultaneous-rendering guarantee.
screenshot-api.org	Its docs state 60 requests/minute and 500 screenshots/month on the free plan, along with rate-limit headers and 429 responses for rate or quota exhaustion. Provider documentation	ScreenshotAPI.com limits.
ScreenshotAPI.net	Its help page states a plan-dependent 20–80 requests/minute range; its bulk docs state a maximum of 50 URLs per bulk request. Help · Bulk documentation	ScreenshotAPI.com limits.
ScreenshotAPI.to	Its docs say authenticated requests have no enforced rate limit, with work queued sequentially per API key; its keyless endpoint is stated to allow 8 requests/minute. Provider documentation	ScreenshotAPI.com limits.

What “no limit per day” does and does not tell you

The FAQ addresses speed and number of calls per day and points to account settings. It does not state whether a burst of requests is accepted, how many renders can run concurrently, whether requests queue, what batch size is accepted, or whether 429 responses include a retry delay. Do not derive a requests-per-second or concurrency target from a daily-call statement.

Keep these measurements separate when planning a bulk capture:

Daily calls: total requests made during a day.
Request rate: requests within a second or minute.
Concurrency: requests in progress at the same time.
Batch size: URLs accepted in a single API request.
Monthly quota and billing: successful captures or other billable events counted during a billing period.
Queue behavior: whether simultaneous work runs, waits, or is rejected.

A service can allow many calls per day and still have practical throughput constrained by account configuration, page load times, or renderer capacity. The FAQ does not quantify those factors for ScreenshotAPI.com.

Plan a bulk run safely

Verify the hostname and account. Confirm that your key belongs to ScreenshotAPI.com and check its current account settings. If the job depends on a specific throughput target, ask the provider to confirm any account-specific guidance.
Prepare and validate the URL list. Remove malformed URLs, deduplicate entries if duplicate captures are not needed, and record a stable job ID and input index for each URL.
Start with low concurrency. Use a small worker pool for the first run. The worker count is an application setting, not a value published by ScreenshotAPI.com.
Measure outcomes. Record request start and finish times, HTTP status, provider response, and URL. Increase worker count in small steps only when the job remains healthy.
Handle failures individually. Retry transient network errors and explicitly transient server responses with a delay and a bounded attempt count. Do not endlessly retry invalid input or authentication errors.
Make reruns safe. Persist completed URLs and results so a process restart resumes unfinished work instead of recapturing every page. Do not assume a request is idempotent or free to repeat unless the provider documents that behavior.

A conservative worker pattern

The FAQ does not specify a batch endpoint or a retry contract for ScreenshotAPI.com, so the code below deliberately avoids inventing either. It shows a runnable Python worker pool around a capture function. Set CAPTURE_COMMAND to your existing command or client wrapper that captures one URL and exits with status 0 on success. It passes the URL as the final argument, limits concurrent processes, and retries failed commands with exponential backoff. Replace the sample command with the invocation documented for your ScreenshotAPI.com account.

#!/usr/bin/env python3
"""Run one existing screenshot command per URL with bounded concurrency.

Example:
  export CAPTURE_COMMAND='python capture_one.py'
  python bulk_capture.py urls.txt

capture_one.py must accept a URL as its final argument and return 0 on success.
"""
import concurrent.futures
import os
import subprocess
import sys
import time

WORKERS = int(os.environ.get("WORKERS", "2"))
MAX_ATTEMPTS = int(os.environ.get("MAX_ATTEMPTS", "4"))
COMMAND = os.environ.get("CAPTURE_COMMAND", "").split()

if not COMMAND:
    raise SystemExit("Set CAPTURE_COMMAND to your documented single-URL capture command")
if WORKERS < 1 or MAX_ATTEMPTS < 1:
    raise SystemExit("WORKERS and MAX_ATTEMPTS must be positive")


def capture(url):
    for attempt in range(MAX_ATTEMPTS):
        result = subprocess.run(COMMAND + [url], check=False)
        if result.returncode == 0:
            return url, "ok"
        if attempt + 1 < MAX_ATTEMPTS:
            time.sleep(min(2 ** attempt, 30))
    return url, "failed"


with open(sys.argv[1], encoding="utf-8") as source:
    urls = [line.strip() for line in source if line.strip() and not line.lstrip().startswith("#")]

with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as pool:
    for url, status in pool.map(capture, urls):
        print(f"{status}\t{url}", flush=True)

This wrapper is a scheduling example, not an official ScreenshotAPI.com SDK. Its retries cover command failures generically. For an HTTP client, inspect the provider’s documented error semantics and retry only transient failures; do not blindly retry every non-2xx response.

cURL, Python, and Node.js integration boundaries

Use the request syntax and endpoint documented for your ScreenshotAPI.com account. The retrieved provider FAQ establishes its daily-call policy but does not specify a bulk endpoint, request schema, concurrency value, or rate-limit headers. Therefore, do not copy parameters or endpoint paths from another similarly named provider. If you already have a working single-URL request, call it from a bounded worker queue like the Python example above.

For any language, the rate-control loop should follow the same rules:

Keep an explicit maximum number of in-flight calls.
Apply a per-call timeout so one page cannot stall the entire job.
Record each URL and outcome before advancing the queue.
Retry only failures known to be transient, with capped exponential backoff and jitter.
On authentication or request-validation errors, fix the input or credentials rather than retrying.
Do not rely on Retry-After or rate-limit headers unless ScreenshotAPI.com documents or returns them for your account.

Choosing concurrency and estimating completion

Because ScreenshotAPI.com publishes no numeric concurrency or per-minute ceiling in the cited FAQ, use measured throughput rather than a guessed vendor limit. If a representative low-concurrency run completes N captures in T minutes, its observed throughput is N / T captures per minute for that test workload. This is a measurement from your job, not a provider guarantee. Page complexity, network conditions, and target-site behavior can change later runs.

Increase concurrency gradually and watch for rising latency, timeouts, errors, or incomplete results. If those appear, reduce concurrency and check provider account settings. Long full-page captures and slow sites may keep each worker occupied longer, so a worker count that is fine for simple pages may not suit a different URL set.

Reliability, performance, and cost considerations

Separate quota from throughput. A daily-call policy says nothing by itself about the plan’s financial allowance or how billing treats failed renders. Check the current account and pricing terms before running a large job.
Avoid duplicate work. Deduplication and a durable completion log reduce accidental repeat captures after restarts. Confirm whether cached results or repeated requests affect your account before relying on them.
Bound memory and output handling. Save or stream results as each call completes instead of retaining a large batch of image bytes in memory.
Use realistic timeouts. A screenshot can take longer than a typical JSON API request because page navigation and rendering are involved. Set a deadline suitable for your pages and log timed-out URLs for review.
Respect target sites. Keep the capture rate appropriate for the sites you are accessing and their terms. Provider-side acceptance does not establish permission to automate a target site.
Track the cost unit. Compare the account’s billable successful captures, any monthly allowance, and treatment of failed attempts separately from request rate.

Troubleshooting bulk screenshot jobs

Symptom	Likely cause	What to do
Requests fail immediately with an authentication response	Missing, invalid, or wrong-account API key.	Check the key and account in ScreenshotAPI.com. Do not retry unchanged authentication failures.
Some URLs fail while others succeed	Malformed URL, target-site error, timeout, or page-specific rendering issue.	Log the failing URL and response, validate the URL, and retry only if the failure is transient.
Throughput drops as concurrency rises	Requests may be contending for rendering, target-site access, or network resources.	Reduce worker count, compare a smaller representative sample, then scale up gradually.
A request receives HTTP 429	The service or account is rejecting the current request rate or another policy condition.	Pause and inspect the response and account settings. Follow a documented retry instruction if one is provided. The cited FAQ does not state a retry header or numeric threshold.
The job appears stuck	A request may lack a timeout, or a worker may be waiting on a slow page.	Set per-request deadlines, report progress, and persist completed results so the job can resume.
The run finishes but expected files are missing	Capture command may report success without writing the expected output, or output naming may collide.	Verify each result artifact exists and use unique filenames keyed by job and input index.
A copied rate number does not match your account	It may belong to screenshot-api.org, ScreenshotAPI.net, ScreenshotAPI.to, or another service.	Check the hostname and consult the matching provider’s docs and account settings.

Or skip the browser setup

ScreenshotNeo offers a website screenshot API and MCP server. A single GET request returns a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation for request options and bulk workflows.

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)
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}`);

Cookie banners, newsletter popups, and chat widgets are removed before the shot, and each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; response headers say which outcome occurred.
An MCP server lets AI agents using Claude, Cursor, or another MCP client take screenshots.
1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000. Every feature is on every plan.

FAQ

Does ScreenshotAPI.com have a requests-per-minute limit?

The cited pricing FAQ gives no numeric per-minute limit. It says calls per day and speed are not limited and points users to account settings.

Does “no daily limit” mean I can send unlimited parallel requests?

No such concurrency guarantee is stated in the FAQ. Confirm your account settings and scale gradually.

Can I use another ScreenshotAPI service’s published limits?

No. Similar names belong to separate providers with different rules. Match the hostname before applying a limit.

What should I do if a bulk request is throttled?

Pause, inspect the response, check the relevant account settings, and resume at lower concurrency. Use a retry delay only when the response or provider documentation specifies one.