How do I build visual monitoring with a screenshot API?

Capture the page on a schedule with the same request every run — POST { "url": "...", "viewport": {...} } to https://api.apiscreenshot.com/v1/screenshot — store each returned image, and diff it against the previous capture with an image-diff library. apiscreenshot provides the reproducible capture; you run the schedule and the comparison.

How do I make sure a diff reflects a real change?

Send identical options on every capture: the same viewport, the same waitUntil, and the same fullPage or selector. When the only variable is the page itself, any pixel difference is a genuine change rather than a framing or timing artefact.

Can I monitor just one part of a page?

Yes. Pass a selector and the capture is cropped to that element — a price block, a hero, a status banner — so the diff watches only the region you care about and ignores changes elsewhere on the page.

Does APIScreenshot do the image comparison for me?

No — APIScreenshot returns the image bytes; you run the diff. That keeps you in control of the threshold and the alerting. Pair it with an image-diff library like pixelmatch, odiff or Pillow to compare each snapshot against the last.

How do I schedule the captures?

Each capture is a single HTTP call, so trigger it from anything that runs on a timer — cron, a CI pipeline, or a serverless cron. Store each image with a timestamp so you keep a history to diff against.

Are the captured pages stored on your servers?

No. Each page is rendered to produce the image, the bytes are streamed back in the response, and nothing is persisted on our side — you keep the snapshot history wherever you store it.

Catch visual changes before users do

visual monitoring API

Capture the same page with the same request on a schedule, then diff each new image against the previous one to flag layout breaks and regressions. The screenshot API gives you the reproducible capture — identical viewport, timing and scope every run — so a pixel difference is a real change, not a framing artefact. You own the schedule and the comparison.

Start free — no credit card Read the docs

No credit card · 100 free screenshots to start

# Run this from your scheduler (cron, a serverless cron, etc.)
curl https://api.apiscreenshot.com/v1/screenshot \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "fullPage": true,
    "format": "png",
    "viewport": { "width": 1440, "height": 900 },
    "waitUntil": "networkidle2"
  }' \
  -o "snapshots/pricing-$(date +%Y%m%dT%H%M).png"

BUY VS BUILD

Building this yourself means…

Doing it in-house is owning a browser fleet and every edge case around it. Here is the work you skip.

Keeping a browser running on a cron just to take the same screenshot every hour.
Capturing inconsistently, so a viewport or timing difference looks like a real change.
Noticing a visual regression only after a user reports the broken page.
Owning the scrolling, waiting and stitching logic that makes a capture reproducible.

HOW IT WORKS

One request, the asset back

Same shape every time: send the request, it renders on a managed browser engine, you get the image back to store or serve.

01
Send the request
POST your payload to /v1/screenshot with your API key — a URL or your own HTML, plus the options this job needs.
02
It renders
A managed browser engine loads the page, waits for it to settle, and captures it — no headless browser of your own to run or scale.
03
Get the asset
The response body is the image bytes, synchronously — write them to a file, push them to your bucket, or hand them to a diff. No queue to poll.

THE CALL

The exact request for visual monitoring

The parameters this job needs, ready to paste. Full reference in the docs.

Reproducible captures. Send the identical viewport, waitUntil and selector every run and each snapshot is framed the same way, so a diff reflects a real change instead of a capture artefact.
Scope to the part that matters. Use selector to capture just one element — a price block, a hero, a status banner — so the diff watches the region you care about and ignores the rest of the page.
Run it from any scheduler. It is one HTTP call, so trigger it from cron, a CI job or a serverless cron. You store the snapshots and run the diff with whatever image-diff library you prefer.

# Run this from your scheduler (cron, a serverless cron, etc.)
curl https://api.apiscreenshot.com/v1/screenshot \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "fullPage": true,
    "format": "png",
    "viewport": { "width": 1440, "height": 900 },
    "waitUntil": "networkidle2"
  }' \
  -o "snapshots/pricing-$(date +%Y%m%dT%H%M).png"

WHY IT HOLDS UP

What actually makes this work

The concrete parts: the formats, the edge cases it handles, the way it scales. Nothing here is a number we can't show you.

Reproducible captures

Send the identical viewport, waitUntil and selector every run and each snapshot is framed the same way, so a diff reflects a genuine change rather than a capture artefact.

Scope to the region that matters

Pass a selector and the capture is cropped to one element — a price block, a hero, a status banner — so the diff watches what you care about and ignores the rest.

You keep the diff and the threshold

The API returns image bytes; you run the comparison with a library you choose (pixelmatch, odiff, Pillow) and set your own change threshold and alerting.

All features →Documentation →Pricing →

Same API, more jobs

The one call behind visual monitoring powers these too.

Browse all use cases →

FAQ

Visual monitoring — common questions

How do I build visual monitoring with a screenshot API?: Capture the page on a schedule with the same request every run — POST { "url": "...", "viewport": {...} } to https://api.apiscreenshot.com/v1/screenshot — store each returned image, and diff it against the previous capture with an image-diff library. apiscreenshot provides the reproducible capture; you run the schedule and the comparison.
How do I make sure a diff reflects a real change?: Send identical options on every capture: the same viewport, the same waitUntil, and the same fullPage or selector. When the only variable is the page itself, any pixel difference is a genuine change rather than a framing or timing artefact.
Can I monitor just one part of a page?: Yes. Pass a selector and the capture is cropped to that element — a price block, a hero, a status banner — so the diff watches only the region you care about and ignores changes elsewhere on the page.
Does APIScreenshot do the image comparison for me?: No — APIScreenshot returns the image bytes; you run the diff. That keeps you in control of the threshold and the alerting. Pair it with an image-diff library like pixelmatch, odiff or Pillow to compare each snapshot against the last.
How do I schedule the captures?: Each capture is a single HTTP call, so trigger it from anything that runs on a timer — cron, a CI pipeline, or a serverless cron. Store each image with a timestamp so you keep a history to diff against.
Are the captured pages stored on your servers?: No. Each page is rendered to produce the image, the bytes are streamed back in the response, and nothing is persisted on our side — you keep the snapshot history wherever you store it.

Monitor my pages for visual changes

One endpoint, the asset back in one call. 100 free screenshots to start, no credit card to begin.

Start free — no credit card See pricing

Cancel anytime · no long-term contract

Catch visual changes before users do

Building this yourself means…

One request, the asset back

Send the request

It renders

Get the asset