ScreenshotNeo

BlogHow-to

How to Build a Bulk Website Screenshot Workflow with Make

Build a Make scenario that captures a list of website URLs, stores each image, and records failures so you can retry them safely.

By the ScreenshotNeo team4 October 202610 min read

To build a bulk website screenshot workflow with Make, pass one URL at a time from a source module into a screenshot action, then map the returned file or image URL into a storage destination. Add validation before capture and a per-URL result record after it, so blank inputs, failed captures, and reruns are manageable.

The basic pipeline is URL source → validation → screenshot action → file handling → destination → result log. Your URL source can be a spreadsheet, database, webhook, or paginated API. Pick a screenshot provider whose Make module and output shape fit the workflow; verify its current fields, authentication, quotas, and response format before building around them.

1. Choose the source and define each URL record

Start with the app that already contains the sites. Each record should have a URL field that Make can map, plus a stable identifier or other useful metadata. For example, a record might contain a URL, page name, capture date, and destination folder.

  • Spreadsheet or database: Use the relevant Make trigger or search/list module to emit records. Decide whether a run captures every row or only new/changed rows.
  • Webhook: Send an array or one URL per event, then map each incoming URL into the scenario. If an event contains multiple URLs, add an iterator so each URL becomes its own bundle.
  • Paginated API: Use an HTTP module with pagination if the source API exposes pages. Make’s HTTP app supports multiple pagination styles; the source API determines which one to configure. See Make’s HTTP app documentation.

Before scaling, choose rules for blank URLs, duplicates, malformed values, and redirects. A practical default is to skip blanks, normalize or reject malformed URLs, and deduplicate using the canonical URL or a source record ID. The exact validation recipe depends on your source and business rules; there is no universal Make setting that decides these policies for you.

2. Build the scenario one URL at a time

  1. Add a trigger. Choose a source event, scheduled run, or webhook. Make scenarios are workflows made from modules, with output from one module mapped into later modules. Read Make’s scenario overview.
  2. Fetch the URL records. Configure the source module to return the intended rows or records. If it returns pages, configure pagination or use a source module that provides the desired records.
  3. Iterate when needed. If the source returns an array of URLs in one bundle, add an iterator. If it already emits one bundle per URL, an iterator is unnecessary.
  4. Filter invalid records. Add a filter or validation step for blank URLs and any malformed patterns you can reliably identify. Keep the original URL and record ID available for logging.
  5. Add a screenshot action. Select a provider’s Make app and map the current bundle’s URL into its URL field. Make lists URL capture actions for GetScreenshot and HTML to Image API. GetScreenshot is listed as provided by Rasterwise; HTML to Image API is listed under that provider name. Confirm the current app documentation and fields before relying on them.
  6. Inspect one real output. Run the scenario once with a single known URL. Determine whether the action returns binary file data, a downloadable URL, or a job/result identifier. The exact response shape controls the next mapping.
  7. Store or share the output. Add the storage or team destination module you use, then map the capture output and a deterministic filename. If the capture action returns a download URL, use Make HTTP’s download-a-file module first; Make documents that the resulting file data can be mapped into later modules. HTTP app documentation.
  8. Write a result record. Store the source record ID, original URL, capture timestamp, destination path or link, and outcome. This makes failed records identifiable and supports deliberate retries.

3. Select a capture module that fits the output

The Make integration listings establish that capture actions exist, but they do not establish a universal winner for price, fidelity, latency, quota, or batch size. Compare providers by capture mode, output type, returned fields, authentication, current account limit, and destination compatibility.

Approach Listed capability Check before implementation
ScreenshotNeo One-call screenshot API and an MCP server for AI clients. Clean shots remove known consent banners, newsletter popups, and chat widgets before capture; only clean shots are billed. Use the API or MCP flow that suits your scenario. Consult the API docs for current request and response details.
GetScreenshot / Rasterwise Make lists Take Screenshot, Take Element Screenshot, Get API Usage, and custom API call actions. Confirm the active account/API key requirement, current fields, output mapping, and account limits. The Make-hosted overview warns that it may be AI-generated, so verify details against vendor documentation.
HTML to Image API Make lists website screenshots, HTML/CSS image generation, PDF generation, and custom API call capabilities. Check the current action fields, output shape, authentication, and account limits.
Make HTTP plus a screenshot API Connects Make to services without a native app; supports requests and file downloads. Follow the API’s authentication and response format, and account for the extra mapping and maintenance.

Do not choose based on an assumed throughput or image-quality comparison. The available integration information does not establish those measurements or a safe batch size.

4. Handle binary files, download URLs, and asynchronous results

Make modules pass data as bundles, but screenshot providers may return different kinds of data. Inspect an actual run before wiring storage:

  • Binary file data: Map the file object or data into the destination’s upload field. Supply a filename if the destination requires one.
  • Download URL: Add HTTP’s Download a file module and map the returned URL. Then map the downloaded file data to storage.
  • Job or task ID: The provider may require a later status/result request. Follow that provider’s documented flow; do not assume the screenshot is ready in the first response.
  • Image URL only: Decide whether a link is enough for your use case. If you need a stored copy, download it before the link expires, if applicable, and upload the file.

Use a predictable filename such as a sanitized source ID plus a date, rather than a raw URL. URLs can contain characters that are awkward in filenames or expose query parameters. Keep the source URL in the result log even if the filename is shortened.

5. Configure authentication and protect credentials

For a native Make app, create its connection using the provider’s documented account or API key setup. For the HTTP app, choose the authentication method the API requires and put credentials in Make’s dedicated Credentials field where supported. Make advises against placing authentication in ordinary request headers or query parameters when a dedicated credential field applies. The HTTP app requires HTTPS endpoints and rejects unverified self-signed certificates. Make HTTP documentation.

Do not put secret keys into spreadsheet cells, webhook payloads, filenames, or logs. If the provider only accepts a key in a query parameter, follow its API documentation and restrict access to the scenario and its run history.

6. Add scheduling, retries, and failure visibility

Make can run scenarios on a schedule, and the GetScreenshot integration page describes recurring daily, weekly, or monthly capture workflows. Set the schedule according to how fresh the screenshots need to be and the provider’s current account limits.

  • Start with a small sample. Test representative URLs, including a long page, a redirect, and a page that may block automated requests.
  • Record outcomes per URL. Store success/failure, source identifier, error detail available from the module, and run timestamp.
  • Route errors deliberately. Use Make error handlers or a separate failure route to log and notify. Avoid retrying every error indefinitely; invalid URLs and authentication failures need correction, while temporary failures may merit a limited retry.
  • Make reruns idempotent. Use a stable record key and decide whether a rerun overwrites the existing image, creates a versioned file, or is skipped after success.
  • Check usage before increasing volume. GetScreenshot lists a Get API Usage action, but the current quota and reset date are account-specific. Check the provider’s current plan and Make’s own operation limits as well.

Neither the reviewed Make listings nor the generic HTTP documentation establish screenshot-provider retry guarantees, throughput, concurrency, quotas, or a universally safe batch size. Increase volume in measured steps and monitor the scenario history and provider usage.

7. Complete example: Make HTTP request to ScreenshotNeo

If you want to use Make’s HTTP app instead of a native screenshot module, create one HTTP request per URL bundle. ScreenshotNeo’s API accepts a GET request with an access key and target URL. Use the provider docs for the current response details and mapping: ScreenshotNeo API documentation.

  1. Add the source trigger and emit one bundle per URL.
  2. Add Make’s HTTP Make a request module. Set method to GET and URL to https://api.screenshotneo.com/v1/shot.
  3. Configure the required credential using Make’s credentials handling where available, following the API docs. If entering query parameters in Make, add access_key and map the current bundle’s url.
  4. Run one sample and inspect the response. Map the returned image data or follow the documented download/result handling into your storage module.
  5. Log the input URL and result for that bundle. Use the response headers and API documentation to understand page verdict and billing where needed.

Equivalent direct requests are shown below. Replace the target URL with the mapped URL in your own integration. The Python and Node.js examples save the response body as a file; production workflows should also check the HTTP status and response headers before treating the body as an image.

cURL

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

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

8. Troubleshooting

Symptom Likely cause Fix
Screenshot action receives an empty URL The source field was not mapped, the source bundle is blank, or the iterator is missing. Inspect the source module output, map the exact URL field, and add an iterator if the URLs are inside an array.
Invalid URL or unexpected target Whitespace, missing scheme, malformed input, or an incorrectly mapped field. Trim and validate input before capture. Confirm the URL starts with the expected scheme and inspect the mapped value in a single run.
Authentication or permission error Wrong key, wrong auth type, expired connection, or credential placed in the wrong field. Recreate the connection or credential using the provider’s documented method. Keep secrets out of ordinary data fields.
Storage module says file data is missing The capture action returned a URL or job ID rather than a file object. Inspect the module output, download the returned file URL with HTTP if applicable, or complete the provider’s result polling flow.
Stored file is tiny or not an image An error response or status page was saved as if it were image bytes. Check the HTTP status, content type, provider result fields, and page verdict before uploading. Log failures separately.
Only some records run A filter, pagination setup, source limit, or scenario operation limit stopped the flow. Check the scenario execution history and source pagination. Verify current Make and provider limits, then process smaller controlled runs if needed.
Duplicate images appear on rerun The destination filename or idempotency key changes on every run. Build filenames from a stable source ID and choose overwrite, version, or skip behavior explicitly.
HTTP connection rejected The endpoint is not HTTPS or its TLS certificate is unverified. Use the provider’s HTTPS API endpoint with a valid certificate; Make’s HTTP app requires HTTPS and rejects unverified self-signed certificates.

9. Performance, reliability, and cost

Capture one URL per bundle unless the selected provider documents a bulk endpoint and its response handling fits your scenario. A larger run can consume more Make operations and provider requests; the reviewed sources do not establish comparable prices, request quotas, concurrency, or capture speed. Check both services’ current plan details before scheduling a large list.

Reduce avoidable work by filtering blank and duplicate records before the screenshot action, capturing only changed records when the source supports it, and choosing a schedule that matches how often the pages need refreshing. If a provider offers caching or other cost controls, verify its current docs and configure them deliberately.

Reliability comes from observing the flow at record level: preserve the source key, record the result, separate permanent errors from transient ones, and make retries bounded and repeatable. Make scenario history helps diagnose module failures, but a separate result table or sheet is useful when you need a durable inventory of what was captured.

Or skip the browser setup

Use ScreenshotNeo’s one-call API from Make’s HTTP module or another supported client, then map the response into your file destination. The docs are at screenshotneo.com/docs.

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

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed; response headers report the page verdict and billing status. An MCP server lets AI agents such as Claude and Cursor take screenshots. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Learn about ScreenshotNeo, then sign up for the free plan.

FAQ

Can one scenario capture hundreds of URLs?

A scenario can process repeated URL bundles, but the reviewed sources do not set a safe universal batch size. Check Make operation limits and the screenshot provider’s current quota, then scale from a small sample.

Do I need an iterator?

Only when a module emits multiple URLs inside one array bundle. If your source already produces one bundle per URL, map each bundle directly into the screenshot action.

Can I use a webhook instead of a spreadsheet?

Yes. A webhook can start the workflow when a URL arrives. If it includes multiple URLs in one payload, iterate over them before capture.

Can I save PDFs as well as screenshots?

Some Make integrations list PDF generation, including HTML to Image API. Check the provider’s current module fields and output format if PDF is a requirement.

How should I handle pages behind a login?

That depends on the provider’s supported authentication and the website’s access rules. Confirm the provider’s current documentation before sending credentials or relying on access to protected pages.