ScreenshotMachine review: is it reliable for automated website screenshots?

Short answer: ScreenshotMachine publishes an API, practical capture controls, error documentation, and an SLA with a 99.99% availability target. That target is not evidence of achieved uptime. The reviewed sources do not establish recent, independent uptime, capture success rate, or latency measurements, so its real-world reliability remains unproven by the evidence available here.

ScreenshotMachine may fit workloads that need its documented controls and plan structure. For a production-critical decision, ask for recent status history and test representative pages before relying on it. This review separates the vendor’s published commitments from independently established evidence.

What the reliability evidence says

ScreenshotMachine’s SLA states a 99.99% availability target and defines monthly availability as available minutes divided by total calendar-month minutes. The document was last updated July 22, 2020. It describes compensation tiers if availability falls below the target, requires a claim within 30 days, and excludes planned maintenance and events outside the provider’s direct control. It names UptimeRobot as the third-party monitoring service for public uptime information. These are contractual terms and a remedy process, not proof that the target was achieved. Read the ScreenshotMachine SLA for the full scope and exclusions.

The vendor homepage uses the marketing phrase “Fast & Reliable” and says the API is always online. Treat that as a vendor claim, not an independent measurement. The ScreenshotMachine homepage does not establish observed uptime or capture success.

The independent material reviewed also does not establish measured performance. A July 2026 review says it did not run a paid load test, inspect the dashboard, or benchmark render times. A September 2026 tutorial notes that the vendor materials do not provide a named, dated benchmark for latency, success rate, or reliability. No independently published historical uptime figure, capture-success percentage, or latency benchmark was established in this research.

Evidence	What it supports	What it does not support
Vendor SLA: 99.99% target, updated July 22, 2020	A published availability commitment, measurement definition, remedy, and exclusions	That ScreenshotMachine actually achieved 99.99% uptime, or that every API capture succeeds
Vendor API documentation	Documented request controls and error categories	How often errors occur or how quickly a capture completes
Reviewed third-party articles	Context on what public materials do and do not measure	A controlled, independent uptime or performance benchmark

Sources: official SLA, official API documentation, SCRNIFY review, and iTechGuides tutorial.

What the API offers for automated captures

ScreenshotMachine exposes an HTTP GET endpoint at https://api.screenshotmachine.com/. A customer key is required. If a secret phrase is configured, the matching hash is needed; according to the docs, a missing or invalid hash is ignored. The API can return screenshot files and provides an X-Screenshotmachine-Response header for error codes.

Its documented controls include:

• Size and device: width from 100 to 1920 pixels; height from 100 to 9999 pixels, or full for a full-page capture; desktop, phone, and tablet presets.
• Output: JPG, PNG, or GIF.
• Timing and cache: capture delay from immediate to 10,000 ms; cache age from zero to 14 days, with zero requesting a fresh screenshot. The documentation recommends a longer delay for long pages with images or animations.
• Page interaction and selection: zoom, click and hide CSS selectors, cookies, accept-language, user-agent, capture of a single selected element, and pixel cropping.

Consult the API reference for accepted parameter names and constraints. The examples below show a basic capture; adapt query parameters to the documented options and keep credentials out of public client-side code.

Make a capture and check the response

Use an API key from your account. The following examples request a 1280-by-800 PNG capture of https://example.com. They save the response only after checking the HTTP status and the API’s error header. The API documents the error header, but clients should still validate the returned file because a successful HTTP exchange alone is not a sufficient content check.

cURL

curl -sS -G "https://api.screenshotmachine.com/" \
  --data-urlencode "key=YOUR_API_KEY" \
  --data-urlencode "url=https://example.com" \
  --data-urlencode "dimension=1280x800" \
  --data-urlencode "format=png" \
  -D response-headers.txt \
  -o screenshot.png

# Inspect the HTTP status and documented API response header:
curl -sS -I -G "https://api.screenshotmachine.com/" \
  --data-urlencode "key=YOUR_API_KEY" \
  --data-urlencode "url=https://example.com"

For production use, make one request and inspect its saved headers rather than issuing a second capture just to inspect headers. Use curl -w or your HTTP client to record status and timing in the same request; verify the file signature or decode the image before publishing it.

Python

from pathlib import Path
import requests

endpoint = "https://api.screenshotmachine.com/"
params = {
    "key": "YOUR_API_KEY",
    "url": "https://example.com",
    "dimension": "1280x800",
    "format": "png",
}

response = requests.get(endpoint, params=params, timeout=(10, 90))
response.raise_for_status()

api_error = response.headers.get("X-Screenshotmachine-Response")
if api_error:
    raise RuntimeError(f"ScreenshotMachine reported an API error: {api_error}")

content_type = response.headers.get("Content-Type", "")
if not content_type.startswith("image/"):
    raise RuntimeError(f"Expected an image response, got {content_type!r}")

Path("screenshot.png").write_bytes(response.content)
print(f"Saved {len(response.content)} bytes")

Node.js

import { writeFile } from "node:fs/promises";

const endpoint = new URL("https://api.screenshotmachine.com/");
endpoint.search = new URLSearchParams({
  key: "YOUR_API_KEY",
  url: "https://example.com",
  dimension: "1280x800",
  format: "png",
}).toString();

const response = await fetch(endpoint, { signal: AbortSignal.timeout(90000) });
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: ${await response.text()}`);
}

const apiError = response.headers.get("X-Screenshotmachine-Response");
if (apiError) {
  throw new Error(`ScreenshotMachine API error: ${apiError}`);
}

const contentType = response.headers.get("content-type") ?? "";
if (!contentType.startsWith("image/")) {
  throw new Error(`Expected an image response, got ${contentType}`);
}

await writeFile("screenshot.png", Buffer.from(await response.arrayBuffer()));

These examples demonstrate defensive client handling; they are not a claim that the service has a particular failure rate. For signed requests, selectors, cookies, and other options, follow the parameter and signing rules in the official documentation.

How to evaluate it for production

1. Ask for dated operational evidence. Request a recent status history and clarify whether the SLA monitors the website, the capture API, or both. Confirm the measurement window, exclusions, notification process, and remedy.
2. Build a representative test set. Capture pages from the sites you actually need, including long pages, images, animations, consent flows, and the device profiles and output formats your workflow uses. This is an evaluation method, not a test result from this review.
3. Record each outcome. Track HTTP status, X-Screenshotmachine-Response, response content type, whether the image decodes, elapsed time, and error category. Keep the target URL and options so failures can be reproduced.
4. Exercise timing and cache behavior. Compare immediate captures with a documented delay for slow or animated pages. Test cache age zero when freshness matters and a nonzero cache age where reuse is acceptable.
5. Set an operational fallback. Decide how your job queue handles timeouts, invalid captures, and service errors. Retry only transient failures, cap attempts, and avoid an unbounded retry loop that can consume quota or delay downstream work.

These checks follow from the documented controls and error model. They do not imply that the API has been independently load-tested or that it meets a particular success-rate threshold.

Errors and troubleshooting

Observed issue or error	Likely cause	What to check
Invalid or missing key	The key was omitted, mistyped, or is not valid for the account	Confirm the key parameter and account credentials; do not expose the key in browser code or logs.
Invalid hash	A configured secret phrase is paired with an incorrect hash	Recompute the hash according to the vendor’s signing instructions and make sure the exact request parameters are used.
Invalid or missing URL	The URL is absent, malformed, or incorrectly encoded	Provide a complete URL including scheme and URL-encode it through the HTTP library rather than concatenating query strings by hand.
No credits	The account has exhausted its available screenshot credits	Check current account usage and plan limits before retrying; repeated requests will not resolve exhausted quota.
Invalid selector	A selector for element capture, click, or hide does not match the page as expected or is malformed	Test the selector against the target page and confirm the relevant element exists when the capture runs.
Invalid crop	Crop coordinates or dimensions are invalid	Check pixel values and ensure the crop fits within the requested screenshot dimensions.
Generic system error	The API reports a general system failure	Record response headers, status, request options, and time. Retry with a limit if appropriate and contact vendor support with a reproducible request.
Saved file is not a usable image	The client accepted an error body or unexpected response as image content	Inspect HTTP status, X-Screenshotmachine-Response, content type, and decode the image before handing it to downstream code.
Screenshot misses content or animation state	The page may need more time to render images or animation frames	Use the documented delay option within its supported range, then compare outputs on representative pages.

The API documentation lists invalid hash, invalid key, invalid URL, missing key or URL, no credits, invalid selector, invalid crop, and generic system error, and says the response header carries an error code. It does not state how frequently any of these occur.

Pricing, caching, and workload cost

The pricing page reviewed on October 3, 2026 lists a free Starter plan for 100 fresh screenshots per month, Basic at €9/month for 2,500, Pro at €59/month for 20,000, and Enterprise at €99/month for 50,000. It lists overage rates of €0.004, €0.003, and €0.002 per additional screenshot for the paid tiers, respectively. The page says additional use is counted and billed in groups of 1,000 rounded down. It also says captures are cached for 14 days and that loading a cached screenshot is not billed as a new fresh screenshot.

These are vendor-published plan terms and can change. Verify current prices, taxes, limits, cache behavior, and billing rules on the ScreenshotMachine pricing page before budgeting. For cost estimates, distinguish fresh captures from cache hits and account for how often each target URL changes.

Alternative to try first: ScreenshotNeo

ScreenshotNeo is a website screenshot API and MCP server for developers, made by Yorker Media. It is the alternative to try first if clean captures and billing transparency matter: it removes cookie and consent banners, newsletter popups, and chat widgets before capture, and only clean shots are billed. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers report the page verdict and billing status.

It offers full-page and selected-element capture, dark mode, device presets and custom viewports, image formats, PDF, HTML/CSS capture, custom CSS and JavaScript, clicks and hidden selectors, waits, request blocking, headers, cookies, user agent, authorization, timezone, geolocation, transparent backgrounds, resizing, configurable caching, signed image links, asynchronous jobs with signed webhooks, bulk capture, a usage API, and an OpenAPI specification. Parameter names used by other screenshot APIs also work, which makes migration easier. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

One GET request returns a screenshot or PDF. See the ScreenshotNeo API documentation for parameters and response behavior.

cURL

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

The free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 screenshots; all features are on every plan. Yearly billing gives two months free. Sign up for ScreenshotNeo’s free plan to get 1,000 screenshots a month with no card.

FAQ

Does the 99.99% SLA mean ScreenshotMachine has achieved that uptime?

No. It is a vendor-published target in an SLA last updated July 22, 2020, with defined exclusions and remedies. It is not an observed uptime result.

Is there a verified screenshot success rate?

None was established in the sources reviewed. Ask for dated service metrics or collect your own results against representative pages.

Can I use ScreenshotMachine for production?

That depends on your tolerance for capture failures, the API’s fit for your pages, and the operational evidence you can obtain. Validate behavior with monitoring and a fallback plan before making it a critical dependency.

Are cached captures billed as fresh requests?

The reviewed pricing page says cached screenshots are stored for 14 days and loading one is not billed as a new fresh screenshot. Confirm current terms before relying on that billing behavior.