How to Check Screenshot API Usage

Direct answer: call your provider’s authenticated account or usage endpoint, then record the plan, billing period, allowed quota, used count, remaining count and reset time. Use the provider dashboard for trends, request logs, status breakdowns and billing context. Track monthly quota separately from requests-per-second or concurrency limits, and alert before either limit is exhausted.

What to check

A useful usage check answers six questions:

Which plan and billing period are active?
How many renders or credits are included?
How many have been used?
How many remain?
When does the allowance reset?
Are requests also constrained by rate, concurrency or another short-window bucket?

Do not treat every failed request as billable usage. Providers differ: some refund failed renders, while others expose separate success and error counts. Read the provider’s current documentation before hard-coding field names.

Step-by-step usage workflow

Authenticate. Sign in to the provider or create an API key with permission to read account usage.
Call the documented endpoint. Save the complete response, including period and reset fields.
Normalize the values. Store plan, allowance, used, remaining, reset timestamp, rate limit and concurrency fields in your metrics system.
Open the dashboard. Review daily and hourly trends, request logs, format breakdowns, errors and billing.
Set alerts. Alert at thresholds such as 70%, 85% and 95% of the monthly allowance, plus alerts for sustained rate-limit responses.
Reconcile. Compare your request logs with the provider’s usage data. Differences can come from cache hits, refunded failures, retries or usage endpoints that are rate-limited but not quota-counted.

Provider usage endpoints

Provider	Endpoint and authentication	Useful fields or dashboard data
Screenshot API	`GET /v1/account`, authenticated as documented	Plan, billing period, used renders and remaining renders. A spent allowance returns `402 quota_reached`. Monthly renders and requests per second are separate controls. Failed 502 and 503 renders are refunded according to its documentation. Source
ScreenshotOne	`GET https://api.screenshotone.com/usage?access_key=<YOUR ACCESS KEY>`	`total`, `available`, `used`, and a `concurrency` object with `limit`, `remaining` and `reset`. Concurrency is distinct from active render counts. Source
ScreenshotAPI.org	`GET https://screenshotapis.org/v1/usage`	Plan, credits remaining, renders today, renders this month and renders total. Its guide also documents insufficient-credit and rate-limit errors. Source
Restpack	`GET https://restpack.io/api/screenshot/usage` with an access token	Date range, plan conversion limit, total conversions and daily counts. Source
ScreenshotMAX	`GET /v1/usage`, authenticated as documented	Quota, used, remaining and concurrency values. Usage requests do not count against quota, but remain rate-limited. Source
RenderScreenshot	Dashboard	Overview, usage charts, request logs, API keys and billing. Usage includes daily and hourly requests, format breakdown and success-versus-error status breakdown. Source

cURL examples

Use the exact authentication and endpoint shown by your provider. These examples illustrate the request shape; inspect the JSON before selecting fields.

# Screenshot API
curl -sS -H "Authorization: Bearer $SCREENSHOT_API_KEY" \
  "https://api.example.invalid/v1/account"

# ScreenshotOne
curl -sS "https://api.screenshotone.com/usage?access_key=$SCREENSHOTONE_ACCESS_KEY"

# ScreenshotAPI.org
curl -sS -H "Authorization: Bearer $SCREENSHOTAPI_ORG_KEY" \
  "https://screenshotapis.org/v1/usage"

# Restpack
curl -sS -H "Authorization: Bearer $RESTPACK_TOKEN" \
  "https://restpack.io/api/screenshot/usage"

# ScreenshotMAX
curl -sS -H "Authorization: Bearer $SCREENSHOTMAX_KEY" \
  "https://api.example.invalid/v1/usage"

Python: fetch and normalize usage

import os
import requests

url = os.environ["USAGE_URL"]
headers = {}
if os.environ.get("USAGE_TOKEN"):
    headers["Authorization"] = f"Bearer {os.environ['USAGE_TOKEN']}"

response = requests.get(url, headers=headers, timeout=30)
response.raise_for_status()
data = response.json()
print(data)

# Map these after checking your provider's documented response.
used = data.get("used") or data.get("used_renders")
remaining = data.get("remaining") or data.get("available")
reset = data.get("reset") or data.get("reset_at")
print({"used": used, "remaining": remaining, "reset": reset})

The fallback keys above are deliberately limited to names documented by the providers in this guide. Keep a provider-specific adapter in production instead of assuming one schema fits every service.

Node.js: fetch usage and alert on thresholds

const usageUrl = process.env.USAGE_URL;
const headers = process.env.USAGE_TOKEN
  ? { Authorization: `Bearer ${process.env.USAGE_TOKEN}` }
  : {};

const response = await fetch(usageUrl, { headers });
if (!response.ok) {
  throw new Error(`Usage request failed: ${response.status}`);
}

const data = await response.json();
const used = data.used ?? data.used_renders;
const remaining = data.remaining ?? data.available;
const quota = data.total ?? data.quota;

console.log({ used, remaining, quota, reset: data.reset ?? data.reset_at });
if (quota && used / quota >= 0.85) {
  console.error("Screenshot usage is at or above 85% of the allowance");
  process.exitCode = 2;
}

ScreenshotNeo usage and capture billing

ScreenshotNeo includes a usage API and exposes billing context on capture responses. Every response identifies the page verdict and whether the request was billed through the X-Page-Verdict and X-Billed headers. Cache hits, bot checks or CAPTCHAs, blank pages, timeouts and failed loads are not billed; only clean shots are billed.

For the current usage fields, authentication and examples, use the ScreenshotNeo documentation rather than guessing endpoint names. In your collector, persist the response headers together with status code, URL, latency and your own request ID so you can explain every usage difference.

Monitoring in production

Metrics to export

Requests by hour and day
Successful captures, failed captures and refunded failures
HTTP status codes and provider error codes
Latency percentiles, especially median, p95 and p99
Monthly used, remaining and percentage consumed
Rate-limit and concurrency responses
Cache hits and misses when the provider reports them
Format, viewport, device and URL class when these affect cost or latency

Google Cloud’s API monitoring guidance covers traffic, errors, median and percentile latency, response-code breakdowns and method-level metrics in the API Dashboard and Cloud Monitoring. Read the guidance.

AWS CloudWatch Synthetics can run API canaries and store screenshots and HAR files for heartbeat checks. Its canary blueprints describe these patterns, while the BaseScreenshot reference defines the baseline structure used for visual comparisons.

Alert policy

Alert	Suggested condition	Action
Quota warning	70%, 85% and 95% of monthly allowance used	Notify the owner; reduce unnecessary retries or move to a larger plan.
Quota exhausted	Provider returns its documented quota error, such as `402 quota_reached`	Stop retries, queue work for the reset or approve a plan change.
Rate limited	Repeated 429 or provider-specific rate-limit responses	Honor retry-after data, apply exponential backoff and cap concurrency.
Render degradation	Error rate or p95 latency exceeds your normal baseline	Check provider status, target-site changes, DNS and your own worker saturation.

Monthly quota versus rate and concurrency limits

A monthly allowance answers “how many renders can I use during this billing period?” A rate or concurrency limit answers “how quickly may I send requests right now?” You can have thousands of renders remaining and still receive a rate-limit response. Conversely, a request can be accepted while the monthly allowance is nearly exhausted.

Track monthly counters and short-window counters separately.
Use a queue and bounded workers instead of firing unlimited parallel requests.
Retry transient rate limits with exponential backoff and jitter.
Do not retry quota exhaustion as if it were a rendering failure.
Record the provider reset time in UTC and display it in the operator’s local timezone.

Reliability, performance and cost notes

Retries: Retry network failures and documented transient 5xx responses only when the provider’s billing policy makes that safe. Use an idempotency key if the provider supports one.
Timeouts: Set a client timeout longer than the provider’s normal render time, but keep a job-level deadline so a stuck URL cannot consume all workers.
Caching: Cache usage responses briefly to avoid hammering a usage endpoint. Keep the capture billing record from every request.
Pagination: If request logs are paginated, export all pages before calculating totals.
Clock handling: Treat provider reset timestamps as authoritative and store them with timezone information.
Cost control: Alert before exhaustion, deduplicate identical URLs, avoid redundant retries and separate development keys from production keys.
Privacy: Redact access keys and sensitive URLs from logs. Store only the URL metadata needed for reconciliation.

Troubleshooting

Symptom	Likely cause	Fix
401 or 403	Missing, expired or under-scoped key	Check the authentication header or query parameter, rotate the key and verify its usage-read permission.
404	Wrong endpoint version or path	Copy the endpoint from the provider’s current documentation; do not infer it from another provider.
402 quota error	Monthly allowance is exhausted	Stop retries, wait for reset or change plans. Treat it separately from a failed render.
429 or concurrency error	Short-window rate or concurrency bucket is exhausted	Reduce parallelism, honor retry-after and use exponential backoff.
Usage appears higher than captures	Retries, multiple workers, or different billing rules	Join provider usage with your request ID, status, cache and refund records.
Usage appears lower than requests	Cache hits, refunded failures or non-billable verdicts	Inspect provider billing fields and response headers, including ScreenshotNeo’s `X-Billed`.
Reset time is confusing	Local-time conversion or billing-period mismatch	Store UTC, show the provider period and convert only at presentation time.
Dashboard and API disagree	Dashboard aggregation delay or different filters	Compare the same time range, plan and environment; allow for documented processing delay.

Or skip the browser setup

ScreenshotNeo provides a single GET request for a PNG, JPEG, WebP or PDF. The request below is runnable as written after replacing the key; see the ScreenshotNeo API documentation for all options.

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.
Bot checks, blank pages and failed loads are never billed.
The response reports its page verdict and billing result with X-Page-Verdict and X-Billed.
An MCP server lets Claude, Cursor and other MCP clients use take_screenshot, get_page_info and capture_pdf.
Every plan includes the features; 1,000 screenshots a month are free with no card, and paid plans start at $5 for 3,000.

Create a free ScreenshotNeo account and start with the included 1,000 screenshots.

FAQ

Does checking usage consume screenshot credits?

It depends on the provider. ScreenshotMAX states that usage requests do not count against quota, although they are rate-limited. Confirm the policy for your provider.

Should I alert on requests or renders?

Alert on the billable unit the provider documents, usually renders or credits, and separately monitor total requests for traffic and rate-limit risk.

How often should a production service check usage?

Poll often enough to catch a threshold before exhaustion, but cache responses and respect the usage endpoint’s rate limit. A scheduled check plus capture-time header recording is a practical combination.

What should I do when a provider changes its response fields?

Keep a provider-specific adapter, validate the response schema, and review the provider documentation before changing production parsers.