Start with small examples for capture, analysis, and comparison. Keep credentials server-side, validate targets, check responses, and preserve every setting that makes the result reproducible.
curl or @snapshot-site/snapshot-siteSNAPSHOT_SITE_API_KEY
A screenshot, a structured analysis, and a visual comparison solve different problems even when they start with a web page URL.
Use screenshot endpoints when the product needs PNG, JPEG, WebP, PDF, or rendered HTML output.
Use rendered-page analysis when summary, topics, metadata, or quality signals are the deliverable.
Use the comparison endpoint for before-and-after visual evidence rather than comparing compressed files byte-for-byte.
Move validated examples into a protected service with destination policy, storage, errors, and observability.
Pick one authorized representative URL
Run the smallest example for the intended result
Add explicit state and inspect the response contract
Move secrets, validation, and storage into your backend
Use explicit dimensions so the requested responsive state is clear.
curl --fail-with-body --request POST \
--url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
--header "x-snapshotsiteapi-key: $SNAPSHOT_SITE_API_KEY" \
--header "Content-Type: application/json" \
--data '{
"url": "https://example.com",
"format": "webp",
"width": 390,
"height": 844,
"fullSize": true,
"hideCookie": true
}'
Use the analysis endpoint when structured page evidence is more useful than pixels alone.
const response = await fetch(
"https://api.prod.ss.snapshot-site.com/api/v3/analyze",
{
method: "POST",
headers: {
"Content-Type": "application/json",
"x-snapshotsiteapi-key": process.env.SNAPSHOT_SITE_API_KEY,
},
body: JSON.stringify({
url: "https://example.com",
waitForDom: true,
}),
},
);
if (!response.ok) throw new Error(`Analyze failed: ${response.status}`);
const analysis = await response.json();
Keep both targets and the comparison context so reviewers understand what changed.
curl --fail-with-body --request POST \
--url https://api.prod.ss.snapshot-site.com/api/v3/compare \
--header "x-snapshotsiteapi-key: $SNAPSHOT_SITE_API_KEY" \
--header "Content-Type: application/json" \
--data '{
"beforeUrl": "https://example.com/release-a",
"afterUrl": "https://example.com/release-b",
"width": 1440,
"height": 900
}'
A short request proves the API contract. Production also needs caller authorization, destination policy, timeout, retry, idempotency, rate control, storage, access, and monitoring. Add these around the working example rather than hiding them inside copied snippets.
Use a fixture you control while evaluating behavior. This keeps consent, availability, and visual state predictable.
Choose capture when the artifact itself is the product. Choose analyze when your application needs structured evidence from the rendered page. Choose compare when the relationship between two known states matters.
Monitoring is a larger workflow. It schedules repeated work, selects a baseline, suppresses expected noise, assigns reviewers, and retains evidence.
Store the source identity, target policy result, viewport, format, readiness and cleanup options, capture time, and code or deployment version. Validate response fields before making an output visible or starting downstream processing.
Never expose the provider key in browser code. The authentication guide shows the trust boundary, and best practices provides a production checklist.
Start with a basic capture against an authorized public fixture. It verifies authentication, reachability, response handling, and storage before advanced analysis.
No example containing the provider key should run in a visitor's browser. Put it in a backend, worker, protected CLI, or secure CI job.
Use a documented screenshot endpoint and request the supported PDF format, then validate and store the returned result according to your application policy.
Advanced screenshot preparation supports documented JavaScript execution. Only run reviewed code against authorized targets and keep it narrowly scoped.
The v3 analyze contract exposes structured fields such as summary, topics, metadata, and quality. Verify current fields in the API documentation.
Comparison creates evidence between two states; monitoring adds schedule, baselines, thresholds, review ownership, alerting, and retention.
Without viewport, format, readiness, cleanup, and capture time, another developer cannot reliably reproduce or interpret an output.
Use the linked rate-limit and error-handling guides before running examples at production volume.
Choose capture, analysis, or comparison, verify one representative URL, and then add the production controls your application owns.