Snapshot Site manages browser rendering for output-oriented jobs. Capture a page, export a PDF, retrieve rendered HTML, compare two states, or request page analysis without exposing a programmable remote browser session.
curl -X POST https://api.prod.ss.snapshot-site.com/api/v1/screenshotSNAPSHOT_SITE_API_KEY
A browser session maximizes control; a task endpoint minimizes infrastructure. The correct boundary depends on whether steps or results are the product requirement.
Use a focused capture request for image, PDF, or HTML output.
Use a dedicated visual diff when the question is what changed.
Use rendered-page summary and quality signals when the consumer needs structured context.
Keep Playwright or Puppeteer when the job requires interactive navigation.
Write down the required final artifact
Select screenshot, compare, or analyze
Set deterministic page-state options
Store result, provenance, and review status
Keep credentials server-side, check the response, and persist the returned asset only after validation.
curl --request POST --url https://api.prod.ss.snapshot-site.com/api/v3/analyze --header 'Content-Type: application/json' --header 'x-snapshotsiteapi-key: YOUR_API_KEY' --data '{
"url": "https://example.com",
"width": 1440,
"fullSize": true,
"waitForDom": true,
"enableSummary": true,
"enableQuality": true
}'
Headless browser API can describe two very different products. One gives developers a remote browser connection and full automation control. The other accepts a task such as capture this URL and returns a defined result.
Snapshot Site follows the second model. That lower control ceiling is useful when the browser is implementation detail. A thumbnail generator, evidence archive, PDF exporter, visual monitor, or page-analysis pipeline usually needs an artifact and provenance, not a page object.
The focused model also makes limitations clearer. Login flows, multi-step interactions, downloads, request interception, and arbitrary browser scripting are not hidden behind a misleading screenshot option.
A browser session maximizes control; a task endpoint minimizes infrastructure. The correct boundary depends on whether steps or results are the product requirement. A useful implementation separates request creation, browser work, result validation, storage, and downstream review. That separation makes failures observable and prevents a rendering option from becoming undocumented business logic.
Headless output becomes useful evidence only when its state is named. Save page identity, responsive dimensions, preparation rule, cleanup selections, format, and capture time alongside the resulting screenshot or document.
Treat width, height, fullSize, delay, DOM waiting, consent cleanup, and hidden selectors as part of the job contract.
Check HTTP behavior and response error fields before consuming links. A technically successful render may still show a CAPTCHA, blank state, or application error.
Record operation, sanitized URL, elapsed time, retry count, capture options, and result storage key.
When a job needs interaction, move it to Playwright, Puppeteer, or a remote browser instead of accumulating brittle preparation scripts.
The API can execute documented preparation controls, including selector cleanup and custom JavaScript on supported endpoints, but that does not turn it into a general session automation product.
A hosted browser can reach destinations on your behalf, so validate targets before dispatch and keep secrets out of payload logs. Apply storage permissions and expiry rules derived from the source, not from the fact that the result is an image.
Read the API documentation for the request contract, the Playwright guide for session-driven work, and pricing when estimating a queue of headless capture operations.
No. It is a task-oriented API for capture, compare, and analyze results. It does not expose a Playwright page or DevTools connection.
Yes, the managed browser renders modern client-side pages. Use measured readiness controls when meaningful content appears after initial load.
Only when the target is reachable through an authorized URL-based preview or access mechanism supported by your architecture. The screenshot endpoint does not document arbitrary cookie or header injection.
Use a remote browser when the workflow must log in interactively, click through steps, intercept requests, reuse a session, or run arbitrary automation code.
Use a managed headless browser API for screenshots, PDFs, rendered HTML, visual comparison, and page analysis without maintaining browser infrastructure.
Use /api/v1/screenshot for basic capture, /api/v2/screenshot for advanced preparation, /api/v3/analyze for rendered-page analysis, or /api/v3/compare for before-and-after visual comparison.
A managed browser renders JavaScript. Use the smallest reliable delay or documented DOM readiness controls when meaningful content appears after initial navigation.
Keep it in server-side environment or secret management and send it only through the x-snapshotsiteapi-key header. Never expose it in public client code.
Start with a representative authorized URL, preserve the request settings, and review the output before expanding volume.