AgentScreenshots API: Does a Public Screenshot API Exist?

AgentScreenshots does not currently offer a public screenshot API.

That is an important boundary. The product has backend endpoints for license validation, usage reporting, Stripe billing, dashboard flows, and feedback, but those are not public screenshot or rendering endpoints. The backend does not accept a URL and return a screenshot.

AgentScreenshots is a local-first CLI workflow. You install the npm package, run agentshot, and the screenshot is written to the output path you choose.

npm install -g agentscreenshots

agentshot "http://localhost:5173" ".agents/screenshots/home.png" 
  --scroll 
  --wait 1000

The result is a PNG or JPEG saved locally at the output path.

What a screenshot API usually means

A screenshot API is normally a hosted rendering service.

You call an HTTP endpoint with a URL and parameters. The provider starts a browser in its infrastructure, loads the page, captures an image, stores or streams the result, and bills by request, image, render time, or bandwidth.

That model is useful. It is also not what AgentScreenshots is today.

Question	Screenshot API	AgentScreenshots
Primary interface	HTTP API	Shell command
Browser runs on	Provider infrastructure	User machine
Best for	Backend jobs, batch renders, external automation	AI coding agents checking rendered UI
Localhost support	Usually needs tunnel or public preview	Works directly in the local command workflow
Output	API response, stored URL, or hosted image	Local PNG/JPEG file
Pricing unit	Usually API request/render	Successful CLI screenshot, called a visual check
Product category	Rendering API or browser cloud	Local-first visual-check CLI

Why AgentScreenshots starts with a CLI instead

The first AgentScreenshots use case is not “my backend needs screenshots.”

It is:

My coding agent changed the frontend. It should visually inspect the result before it says the work is done.

That workflow happens inside a repo, often against a local dev server:

agentshot "http://127.0.0.1:5173/pricing" 
  ".agents/screenshots/pricing-mobile.png" 
  --viewport 390x844 
  --selector "section:has-text('Pricing')" 
  --padding 24

For that job, a shell command is often simpler than an API:

• no tunnel for localhost
• no hosted browser session to configure
• no image upload by default
• no service-side access to private app pages
• no temporary screenshot URL to manage
• no agent-written API client needed for routine checks

The agent can run one command, inspect the saved file, patch the UI, and run the command again.

What the CLI can capture

AgentScreenshots focuses on common frontend review captures:

Need	CLI shape
Full page	--scroll --wait 1000
Specific section	--selector "main" with --padding 24
Vertical slice	--from 1200 --to 2000
Mobile or desktop viewport	--viewport 390x844 or --viewport 1440x1000
Lazy content	--scroll --wait 1000
Wait for app state	--wait-for "[data-ready='true']"
Wait for browser load state	--wait-until load
Dismiss optional UI	--click-if-present "#reject-cookies"
Open required UI	--click "#details-toggle"
Hover state	--hover ".nav-item"
Sharper capture	--device-scale-factor 2

These options are shaped around visual review, not bulk web rendering.

When a screenshot API is better

Use a screenshot API if the screenshot job lives in a backend system.

Good API use cases include:

• generating social preview images at scale
• scheduled screenshots of many public URLs
• rendering images for user-facing reports
• storing screenshots in a hosted archive
• capturing pages from infrastructure where a local CLI workflow is not practical
• building a product feature where screenshots are created server-side
• distributing screenshot jobs across queues, workers, proxies, or regions

Those jobs benefit from hosted infrastructure. They may need predictable uptime, concurrent workers, image storage, public URLs, webhooks, proxies, or browser pools. AgentScreenshots is not trying to be that product in its MVP.

When AgentScreenshots is better

Use AgentScreenshots when the screenshot is part of local development or agent review.

Good CLI use cases include:

• checking a component after changing CSS
• capturing a route running on localhost
• reviewing a staging page reachable only from your local environment or VPN
• showing before/after UI proof inside a repo
• letting an AI coding agent verify mobile layout
• saving artifacts under .agents/screenshots/
• keeping screenshots local by default

The agent does not need a screenshot platform. It needs eyes on the rendered page.

Pricing and metering

AgentScreenshots meters successful CLI captures as visual checks. A visual check is one successful screenshot through the CLI. Failed captures do not count.

Current public plan shape:

Plan	Included visual checks
Anonymous local trial	50 one-time screenshots
Free	100/month
Solo	2,000/month for EUR 5/month or EUR 50/year
Pro	10,000/month for EUR 20/month or EUR 200/year
Studio	100,000/month for EUR 100/month or EUR 1,000/year

This pricing is for a maintained, agent-ready visual-check workflow. It is not priced as hosted browser compute because AgentScreenshots does not currently provide hosted rendering.

The honest boundary

If you need a screenshot API, AgentScreenshots is not that today.

If you need a coding agent to visually check local, preview, staging, or production pages available in its development environment, AgentScreenshots is built for that narrower job.

The distinction matters because it changes the architecture, privacy model, setup, and expected workflow. AgentScreenshots deliberately starts with the local command because the first problem is not remote rendering. It is agents finishing frontend work without seeing it.