How to Schedule Website Screenshots with Make and a Screenshot API

To schedule website screenshots with Make, create a scenario with a schedule and a screenshot API action. Use the API vendor’s native Make app if it fits your workflow; otherwise, call its documented endpoint with Make’s HTTP app. Then route the returned image or download URL to storage, email, or another destination. First confirm how that API returns screenshots: directly as image data, as a job to poll, or as a URL to download.

This guide covers the general setup without assuming a specific vendor’s request fields or response format. Make’s HTTP documentation describes how to connect to APIs; the screenshot provider’s documentation defines its authentication, capture options, and result handling. Make scheduling documentation · Make HTTP app documentation.

1. Choose a schedule and capture workflow

Make supports regular intervals, once, daily, weekdays, weekly, monthly, specified dates, and on-demand schedules. The minimum interval depends on your Make plan. To configure one, open the scenario builder and click the schedule control on the toolbar. You can also set start and end dates in advanced settings. Make’s schedule guide.

Need	Schedule to consider
Track a page throughout the workday	Regular interval or multiple daily run times
Check once per day	Daily
Capture only on business days	Weekdays
Archive a weekly or monthly snapshot	Weekly or monthly
Run only after a manual request or API call	On demand
Run for a fixed campaign or audit window	Use a recurring schedule with start and end dates

Pick the least frequent schedule that satisfies the monitoring need. More frequent schedules create more scenario executions and screenshot requests. The actual minimum interval and any API usage limits depend on your Make plan and screenshot vendor; check both before activating the scenario.

2. Build the Make scenario

Create a scenario. Start a new scenario in Make’s scenario builder.
Add the schedule. Set the interval or calendar schedule, and use advanced settings for optional start and end dates.
Add the screenshot action. Choose a maintained native Make app for your API if available. Otherwise add an HTTP request module and follow the screenshot vendor’s current API documentation for method, URL, authentication, request parameters, and expected response.
Handle the returned result. Map the image data to a file-handling step if the API returns image bytes. If it returns a downloadable URL, use a file-download step. If it returns a job identifier, follow the vendor’s documented polling or callback flow before trying to download the image.
Choose a destination. Add a storage, email, or team-app step. Use a descriptive filename that includes the site and capture date so recurring runs do not become indistinguishable.
Run once and inspect the output. Confirm the image opens, has the intended dimensions, and reaches the destination. Then save and activate the scenario.

Make’s HTTP app includes request and file-download modules for connecting to APIs that do not have a native integration. Make says to select authentication based on the target API and to put authentication details in the dedicated Credentials field rather than adding them to ordinary headers or query parameters. Follow the provider’s own documentation for the exact setup. Make HTTP app documentation.

3. Choose a native app or generic HTTP

A native app can reduce manual setup when it exposes the capture action and settings you need. Make lists a GetScreenshot integration with screenshot, element-screenshot, and usage actions. It also lists an HTML/CSS to Image integration with a URL-screenshot action. These listings establish that the integrations exist; they do not establish that one is better for every use case.

Use generic HTTP when your chosen provider has no suitable native Make app or when its documented API gives you the controls you need. Before committing to a flow, verify the vendor’s supported capture options, authentication, limits, pricing, result format, and retention policy. Those details vary and cannot be inferred from Make’s generic HTTP instructions.

4. Configure image delivery and repeat runs

Direct image response

If the vendor responds with an image, configure the flow to preserve it as a file and pass that file to the next module. Avoid treating binary image data as ordinary text. Confirm the output’s content type and file extension agree.

Download URL response

If the response contains a URL, map that field into Make’s file-download module. Check whether the URL expires and whether it requires authorization; use the vendor’s documented download method and credentials.

Asynchronous job response

If the API returns a job identifier rather than an image, the scenario needs a follow-up step to check job status and retrieve the result. Use the vendor’s specified wait intervals, completion states, and limits. Do not assume every API supports polling or webhooks.

Destination and duplicate handling

Decide whether each scheduled capture should create a new archive item or replace a latest snapshot. For archives, include the date and time in the filename or destination path. For a latest-only view, use a stable destination name if the storage service supports replacement. If a scenario retries after an error, consider whether repeating a save or notification could create duplicates.

5. Example API requests with ScreenshotNeo

For a concrete API example, ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It returns a PNG, JPEG, WebP, or PDF from one GET request. Its parameter names are compatible with those used by other screenshot APIs, which can make switching easier. See the ScreenshotNeo API documentation for the current request details.

In Make, you can either use its HTTP request module with the documented GET endpoint and map the response into your file flow, or use the calls below outside Make to confirm the API request shape. Replace the placeholder key and target URL. In Make, store credentials in the HTTP module’s dedicated Credentials field when applicable; follow the API documentation for the exact authentication configuration.

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,
)
r.raise_for_status()
with open("shot.webp", "wb") as f:
    f.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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

6. Or skip the browser setup

ScreenshotNeo can handle the capture while Make handles the schedule and destination. Cookie banners are accepted like a visitor, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. An MCP server lets Claude, Cursor, and other MCP clients take screenshots. Every plan includes every feature; 1,000 screenshots a month are free with no card, and paid plans start at $5 for 3,000.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Read the ScreenshotNeo docs, then sign up free for 1,000 screenshots a month with no card.

7. Reliability, performance, and cost

Keep cadence proportionate. A more frequent schedule means more scenario runs and API calls. Check your Make plan’s minimum interval and the API vendor’s usage limits.
Plan for slow or changing pages. Some pages need more time to render. Use only capture waits or readiness options supported by your provider, and allow sufficient time for the complete scenario.
Handle errors deliberately. Make’s HTTP app can be configured to return an error for 4xx or 5xx responses. Decide how incomplete executions should be monitored and whether a retry is appropriate for each error. Avoid retrying authentication or invalid-parameter errors unchanged.
Respect rate limits. Make documents a default maximum of 100 runs per minute for instant triggers and queueing after a configured maximum. That guidance is specifically for instant triggers; it is not the minimum interval for scheduled scenarios. A webhook caller may receive HTTP 429 if a webhook-response scenario exceeds its rate limit and must wait and retry. Schedule documentation.
Account for result size. Full-page images and PDFs can be larger than viewport screenshots. Confirm the destination accepts the resulting file size and format.
Budget both services. Make executions and screenshot API usage are separate considerations. Estimate recurring captures as scheduled runs multiplied by target pages, then check current plan allowances and pricing with Make and the provider.
Protect credentials and URLs. Use Make’s credential controls and limit access to the scenario. Avoid putting secrets into filenames, public destinations, or logs.

8. Troubleshooting

Symptom	Likely cause	What to check
No scheduled captures occur	Scenario is inactive, schedule is on demand, or schedule dates exclude the current date	Confirm activation, schedule type, timezone, and any start/end dates.
Request is rejected	Wrong authentication method, missing credential, invalid URL, or unsupported parameter	Compare the request with the provider’s current API documentation and inspect the status and response body.
Saved file is not an image	API returned an error payload, JSON job response, or a URL instead of image bytes	Inspect the response content type and body. Add the documented polling or download step if needed.
File is empty or truncated	Binary data was mapped as text, or the flow downloaded the wrong response field	Preserve file data as binary and verify the vendor’s response format.
Screenshot shows a loading state	Page rendering was incomplete when capture occurred	Use a provider-supported wait, selector, or network-idle option if available. Confirm the target page itself loads reliably.
Scenario gets HTTP 429	Rate limit was exceeded	Wait and retry according to the service’s limits. For Make webhook responses, Make specifically says callers should wait and retry after 429.
Storage or email step fails	Destination connection expired, file is too large, or required metadata is missing	Reauthorize the destination, check size and format limits, and inspect required fields.
Repeated files or notifications	A retry repeated a downstream action or the filename is not unique	Choose an archive or replacement strategy and make filenames or destination updates deliberate.

9. Frequently asked questions

Can Make take screenshots on a schedule without a browser running on my computer?

Yes. The scenario calls a screenshot integration or API service, so the capture flow is managed through the connected service rather than a browser session you manually open for each run.

Can I schedule several pages in one scenario?

That depends on how you supply URLs and how the API handles each request. You can design a scenario to process multiple URL records, but check the provider’s batch support and Make’s execution and usage limits.

Can I compare screenshots to detect visual changes?

This workflow captures and routes images. Change detection requires an additional comparison step or service; the cited Make integration descriptions do not establish a universal built-in comparison feature.

Does an instant-trigger rate limit define the scheduled interval?

No. Make describes the instant-trigger run limit separately from the minimum interval for recurring schedules. Check the setting that applies to your trigger type and plan.