Best Website Screenshot APIs With Webhook Support

A website screenshot API with webhook support lets your application start a render and receive a callback when the result is ready. For the providers covered here, ScreenshotNeo is the first one to consider: it offers async jobs with signed webhooks, clean captures, and bills only clean shots. Its free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000.

Among the other providers in the research, ScreenshotOne documents asynchronous rendering, S3-compatible storage, result delivery, and HMAC-SHA256 webhook verification; Urlbox documents POST callbacks for successful renders and errors; Browshot documents callbacks on finished or error status and up to two delivery retries. These are documented feature differences, not a measured ranking of speed, reliability, image quality, or price.

What to compare before choosing

A webhook is only one part of an integration. Check the callback event types, payload shape, authenticity mechanism, retry behavior, storage path, and the capture options your application needs. Confirm the current API schema and commercial terms in each provider’s documentation before implementation.

Provider	Documented callback behavior	Result handling and safeguards
ScreenshotNeo	Async jobs with signed webhooks.	Website screenshot API and MCP server. Cookie banners, newsletter popups, and chat widgets can be removed before capture; each cleanup step can be turned off. Only clean shots are billed, with response headers indicating page verdict and billing.
ScreenshotOne	Webhook delivers execution results as a POST body; async rendering is supported.	Can upload to S3-compatible storage and return the location when configured. Documents an HMAC-SHA256 signature header. Error notifications are off by default and can be enabled. Official async and webhook guide.
Urlbox	POST callback when a render succeeds or errors.	Its example includes an event name, render ID, and result URL. Supports full-page and element-specific screenshots. Official webhook documentation.
Browshot	POST when a screenshot reaches finished or error status.	Callback body contains the JSON returned by screenshot/info; documentation says delivery may be retried up to two times. Official API documentation.

For Urlbox, the reviewed webhook page does not establish verification or retry behavior. That means those details are unverified here, not necessarily unsupported. The same caution applies to any detail not listed in the table.

How to choose a screenshot API with webhooks

Write down the event contract you need. Decide whether your app must hear about success, failure, or both, and what information it needs to correlate the event to an existing job.
Decide where the image should live. A callback carrying a URL or storage location keeps image bytes out of your webhook handler. If the provider returns binary data synchronously, your application must handle the body and storage itself.
Require a way to authenticate callbacks. Prefer documented signature verification. If a provider documents a shared secret or signature, verify the raw request body before parsing or acting on it.
Design for duplicate and delayed delivery. Make callback processing idempotent using a provider event or render identifier where available. Persist job state, acknowledge quickly, and perform slower work asynchronously.
Check the capture shape. Confirm viewport or device, full-page behavior, element targeting, authentication, output format, and whether lazy-loaded content needs scrolling or an explicit wait.
Compare current plan limits and terms. The research did not establish comparable prices, quotas, service-level commitments, or performance across ScreenshotOne, Urlbox, and Browshot.

A reliable webhook workflow

Your server creates a job record with an internal ID and submits the target URL plus a callback URL.
Store the provider’s job or render ID when the API returns it. Associate it with your internal ID.
When the callback arrives, verify its signature if the provider documents one. Read the raw body for signature verification before JSON parsing.
Validate the event shape and status. A callback can indicate an error as well as a completed render.
Persist the result URL or storage location and transition the job state once. Ignore or safely process duplicate notifications.
Return a successful HTTP response promptly, then enqueue downstream tasks such as image processing, notifications, or database updates.
Record callback timestamps, provider identifiers, and failure reasons without logging secrets or sensitive target data unnecessarily.

Do not assume every provider retries, signs requests, or sends errors unless its current docs say so. Where retry guarantees are unspecified, use your own reconciliation process, such as checking pending jobs against the provider’s status API if one is available.

Provider-specific webhook notes

ScreenshotOne

ScreenshotOne’s documented async flow returns promptly while rendering continues. For an S3-compatible upload with the location in the callback, the guide uses async=true, webhook_url, store=true, response_type=json, and storage_return_location=true. Without storage, a JSON response can include screenshot_url; without JSON response type, the response body is binary. The documentation says webhook error events are off by default and can be enabled with webhook_errors=true.

Verify X-ScreenshotOne-Signature with HMAC SHA-256 using the separate webhook secret, not the API key. Their guide explicitly says the secret differs from the API key. Avoid disabling signing for production unless you have a deliberate alternative authenticity control. See the signature and error details.

Urlbox

Its webhook documentation describes passing a webhook_url and receiving a POST after a render completes or errors. The example includes an event such as render.succeeded, a render ID, and result data. Treat the example as a schema illustration, then validate the current payload and required request parameters against the live docs.

For full-page rendering, Urlbox documents scrolling to load lazy content and determine page height by default; skip_scroll disables that behavior. This can affect what appears in the image, so include it in capture tests for pages with lazy-loaded sections. See webhook docs and the Urlbox documentation.

Browshot

Browshot documents a hook parameter containing your callback URL. It sends a POST when the screenshot status is finished or error; its documentation says the body is the JSON returned by screenshot/info, with up to two retries. Ensure your handler tolerates repeated delivery. The documentation surfaced in the research was older than the other provider pages, so reconfirm behavior and parameters before relying on it. See the Browshot API documentation.

Webhook handler checklist

Use HTTPS and a route that accepts POST requests.
Read the raw body before JSON parsing when signature verification requires exact bytes.
Verify signatures with a constant-time comparison when the provider specifies a signature format.
Validate the content type, payload size, expected event/status, and required identifiers.
Persist an idempotency key or provider render ID to avoid duplicate side effects.
Respond promptly after durable acceptance; do not hold the callback open while downloading or transforming a screenshot.
Make callback processing observable with structured logs and metrics, while keeping API keys and webhook secrets out of logs.
Provide a way to find jobs that remain pending and reconcile them according to the provider’s documented status or support process.

Capture options that affect webhook jobs

Webhook delivery does not determine screenshot content. Review each provider’s current options for the capture requirements below before committing to an API.

Page extent: viewport-only or full-page. Full-page capture may need scrolling to trigger lazy content.
Target: full page or a specific element selected by CSS.
Rendering context: viewport/device, scale, color scheme, cookies, headers, authentication, timezone, and geolocation where available.
Timing: wait for a selector, a delay, or page/network readiness. A fixed delay can waste time or still be too short.
Output: PNG, JPEG, WebP, or PDF as required by the application.
Storage and access: provider URL, your object storage, signed URL, or an application-managed copy; define retention and access controls.

Urlbox specifically documents full-page and element-specific capture, including the full-page scrolling behavior noted above. ScreenshotOne’s webhook guide documents image result URLs and S3-compatible storage. Do not infer an undocumented option from another vendor’s API.

Performance, reliability, and cost

Performance

Async jobs avoid keeping the initiating request open while a render completes, but the dossier contains no comparable latency measurements. Keep the callback handler fast, move image downloads and post-processing to a queue, and set client-side timeouts based on your application workflow rather than assuming a fixed render duration.

Reliability

A webhook is a notification channel, not by itself a complete job ledger. Persist your own job state before submission, record provider identifiers, make callback processing repeat-safe, and define how to discover a job whose callback never arrives. Retry policy and signature support vary in what the reviewed docs establish: ScreenshotOne documents signatures; Browshot documents up to two retries; equivalent Urlbox details were not established in this research.

Cost

Current comparable provider pricing and quotas were not established in the research, so check each provider’s live pricing and plan terms before selecting one. Include the cost of storage, callback infrastructure, retries, and any options that are billed separately. ScreenshotNeo’s listed plans are Free with 1,000 shots/month and no card, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. A single GET request takes a URL and returns a PNG, JPEG, WebP, or PDF. Its async jobs support signed webhooks. The API also supports full-page capture with lazy images loaded, CSS element capture, dark mode, device presets and custom viewports, retina scale, PDF settings, HTML/CSS input, custom CSS and JavaScript, click-before-capture, hide selectors, wait conditions, request/resource blocking, headers, cookies, user agent and Authorization, timezone and geolocation, transparent backgrounds, resizing, caching with a chosen TTL, signed links for public image tags, bulk capture up to 100 URLs per call, usage API, and OpenAPI spec. Common screenshot API parameter names also work for easier migration.

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. 1,000 screenshots a month are free with no card, and paid plans start at $5 for 3,000.

See the ScreenshotNeo API documentation. For a direct one-call example:

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

Troubleshooting webhook integrations

Symptom	Likely cause	What to do
No callback arrives	Wrong or unreachable callback URL, rejected request, or error callbacks disabled.	Check HTTPS reachability and server logs. For ScreenshotOne, set `webhook_errors=true` if you need error notifications. Confirm provider-specific delivery behavior in its docs.
Signature verification fails	Body was parsed and reserialized, wrong secret used, or signature encoding differs.	Verify against the exact raw bytes; use the webhook secret rather than the API key for ScreenshotOne; confirm the provider’s documented signature format.
Callback repeats	Delivery retry or duplicate event.	Use an idempotency key or render ID and make state transitions safe to repeat. Browshot explicitly documents up to two retries.
Callback says error or has no image URL	The render failed, error events are enabled, or the expected result field differs.	Check the provider status and error fields, and handle failures as a distinct terminal or retryable state. For ScreenshotOne, check error headers/body and whether JSON response type was configured.
Image is missing content below the fold	Lazy-loaded content was not triggered or the page had not settled.	Use the provider’s documented full-page behavior or wait options. Urlbox documents scrolling by default for full-page screenshots and a `skip_scroll` option.
Callback request times out	Handler downloads or processes the image before responding.	Verify and persist the event, enqueue the work, return promptly, then process asynchronously.
Unexpected billing or plan limits	Different providers count options and failures differently; comparable terms were not established here.	Review live pricing, limits, and billing definitions before launch. For ScreenshotNeo, inspect the response’s page-verdict and billed headers.

Frequently asked questions

Which screenshot API documents webhook signature verification?

ScreenshotOne documents an X-ScreenshotOne-Signature header and HMAC-SHA256 verification with a separate secret key. ScreenshotNeo also describes async jobs with signed webhooks; consult its current docs for implementation details.

Which provider documents webhook retries?

Browshot’s API documentation says a callback may be retried up to two times. Do not assume the same retry policy for other providers unless their current documentation specifies it.

Can a webhook send the screenshot file itself?

Payload behavior depends on the provider and configuration. ScreenshotOne documents JSON with a screenshot URL or storage location in its webhook workflow; its synchronous non-JSON response is binary. Design your handler around the provider’s documented payload rather than assuming the callback contains image bytes.

Are these APIs ranked by speed or reliability?

No. The reviewed sources establish documented features, not controlled comparisons of latency, uptime, render fidelity, or price.