Make.com Screenshot API — Automate Captures With Make

The Make.com screenshot API setup is one of those things that sounds harder than it actually is. You open a scenario, drop in an HTTP module, paste the endpoint, and screenshots start flowing into whatever app you've connected downstream. Ten minutes, zero code.

What makes Make interesting for screenshot work isn't just the visual builder. It's the credit-based pricing. A five-module scenario costs five credits per run regardless of complexity. Compare that to platforms where each step counts as a separate billable task, and you start to see why Make pulls ahead for teams running no-code screenshot automation at any real volume.

How the Make.com screenshot API connection works

You won't find a ScreenshotRun listing in Make's app directory, and that's actually a good thing. Make's built-in HTTP module sends a GET request directly to the API endpoint, and you get back screenshot data in whatever format you asked for. PNG, JPEG, WebP, PDF, TIFF, or AVIF.

The request is identical to what you'd run from a terminal:

GET https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&format=png&width=1280&full_page=true

Authorization: Bearer YOUR_API_KEY

Make just wraps this in a visual interface. You fill in the URL, set headers through form fields, and the HTTP module assembles the request. Every Make.com website screenshot flows through the same module, and every parameter the API supports works out of the box — today and whenever new ones ship. No waiting for a third-party app developer to update a community package.

Configure the Make HTTP module for your first screenshot

First, pick up a free API key from your ScreenshotRun dashboard — takes 30 seconds and no payment info.

Step 1. Create a new scenario in Make. Add a trigger. For testing, use the Schedule module set to run once. You can swap it for a webhook, spreadsheet trigger, or anything else later.

Step 2. Click the plus icon after your trigger and search for HTTP. Select "Make a request" from the module list.

Step 3. Fill in the HTTP module:

• URL: https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&format=png&width=1280
• Method: GET
• Headers: add one row with Name Authorization and Value Bearer YOUR_API_KEY

You can either bake parameters into the URL or use the Query String section to add them as key-value pairs. The query string approach is cleaner when you're mapping dynamic values from earlier modules, like {{1.url}} pulling a URL from a previous step's output.

Step 4. Under Advanced settings, set the response type to Binary so Make treats the result as an image file you can pass to Google Drive, Dropbox, email, or any storage module.

Step 5. Click "Run once" to test. You should see binary data in the output panel. A 200 status means it worked. Got a 401? The API key header is missing or wrong. A 400 points to an invalid query parameter — check for typos in the URL string.

That's the base setup.

Five Make scenarios that automate website screenshots

These lean on the parts of Make that actually justify using it over raw code: routers, iterators, and webhooks.

1. Airtable URL list to screenshot attachments

Your team tracks websites in an Airtable base. Maybe it's a prospect list, a portfolio of client sites, or a directory you're building. This scenario reads every row with a URL, captures a full-page screenshot, and uploads it directly to the Airtable attachment field on the same row.

The module chain: Airtable — Search Records (filter for rows missing a screenshot) → Iterator (split the result array into individual bundles) → HTTP — Make a request (call the screenshot API with {{3.fields.URL}}&full_page=true) → Airtable — Update a Record (write the binary response to the attachment field).

We tested this with 40 URLs. The whole run finished in about three minutes, and each row got its screenshot without anyone opening a browser. Four modules per URL means four credits each, so 40 URLs costs 160 credits. Well within the free tier.

2. Router-based desktop and mobile capture in one scenario

This one shows why Make's Router module matters for screenshot work. A single trigger fires once, then the router splits the execution into two parallel paths. One path captures the site at 1440px (desktop). The other captures it at 375px with device=mobile. Both paths save to Google Drive with timestamped filenames.

Routers consume zero credits, so you're only paying for the two HTTP modules and two Drive uploads. Four credits total for both a desktop and mobile screenshot from a single trigger. On platforms with linear-only workflows, you'd need two separate automations for the same result.

This pattern works well for visual regression testing across breakpoints, or when a design team needs both views for review.

3. Webhook-triggered async screenshots (skip the timeout)

Here's the scenario most people don't know about, and it solves Make's biggest frustration: the 60-second HTTP timeout. Heavy pages with lots of client-side rendering can take 15-20 seconds to fully load. Add a full-page capture with lazy-loaded images, and you might push past that 60-second wall. When the HTTP module times out, the whole scenario fails.

The fix: use ScreenshotRun's webhook parameter. Instead of waiting for the screenshot synchronously, you tell the API where to send the result when it's done.

Two scenarios work together. Scenario A fires on a schedule (or any trigger), sends the HTTP request with webhook_url=https://hook.make.com/YOUR_WEBHOOK_ID, and finishes immediately. Done. No hanging around. Scenario B starts with a Custom Webhook trigger that receives the finished screenshot from the API and routes it to storage or notifications.

We had this running for a page that consistently took 45 seconds to render. The synchronous approach failed every time. The webhook pattern handled it cleanly on every run.

4. Product page visual QA before launch

If you've ever spent 15 minutes manually screenshotting a product page at three viewport sizes before a launch, this one's for you. The scenario captures desktop, tablet, and mobile views, strips cookie banners and ads, and drops all three into a Slack thread for the team to review.

A Custom Webhook trigger accepts a POST with the page URL from your CI/CD pipeline or a manual cURL call. Then a Router splits into three paths, each hitting the API with different width and device settings. An Array Aggregator collects the three screenshots back into a single bundle, and a Slack module posts them as a thread with the URL and timestamp.

The QA team stopped asking "can someone grab screenshots of the new page?" after we set this up. Push the URL, wait 30 seconds, check Slack.

5. Weekly OG image refresh for your top pages

Social sharing previews go stale. You update a landing page but the old OG image keeps showing up on LinkedIn and Twitter for days. This scenario runs every Sunday at midnight, captures your top 10 pages at 1200×630 (resize_width=1200&resize_height=630), and uploads the fresh images to your CMS or CDN. It's a practical application of the OG image generator pattern, fully automated.

Ten pages through a four-module chain: 40 credits per week, 160 per month. On the free plan, that's 16% of your monthly budget for OG images that always match your current site.

Screenshot API parameters for Make scenarios

All parameters go into the URL query string or Make's Query String Params section. Dynamic values from earlier modules use Make's {{N.field}} syntax, where N is the module number. The full feature set maps directly to these query parameters.

Beyond these basics, the API supports 40+ parameters — check the full docs for geolocation spoofing, custom CSS/JS injection, proxy routing, and fine-grained PDF output settings.

Handle errors, retries, and rate limits in Make

Make's error handling is better than most no-code platforms, and it matters once you're running screenshot scenarios at any real volume.

The HTTP module returns the status code as a mappable field. Add a Filter after it that checks for status code = 200 and only passes successful captures to downstream modules. For failed requests, attach an Error Handler route with a Break directive. Break pauses the scenario, logs the error, and retries automatically based on your settings. If the target site was temporarily down or the API returned a 5xx, the retry usually sorts it out.

Rate limits (429 responses) work the same way. On the free tier, you get 1,000 credits per month — enough for roughly 200 single-module screenshot captures, more if your scenarios are lean. If you need higher volume, the Starter plan at $9/month covers 5,000 captures. That handles most Make automation workflows.

For complex pages that risk exceeding Make's 60-second HTTP timeout, use the webhook_url approach from scenario 3 above. It'll save you the frustration of watching scenarios fail on pages that just take a bit longer to render.

Make vs Zapier vs n8n for screenshot automation

Look, all three platforms send the same HTTP request to the same API endpoint. The screenshots come back identical. What differs is how much the platform charges you and what it lets you build around that request.

Honest assessment: Zapier is faster to set up, but you pay through the nose once you hit any real volume. Make gives you the best cost-to-flexibility ratio for most teams. Self-hosted n8n is cheapest long-term if you don't mind running your own server.

Make sits in a sweet spot for teams that want visual scenario building, conditional logic with routers, and reasonable pricing without managing infrastructure. For comparing the screenshot API providers themselves, our screenshot API comparison covers that side.

Connect screenshots to Make's app ecosystem

Once your HTTP module returns a screenshot, Make can route it to practically anything. Google Drive, Dropbox, S3, Airtable, Notion, Slack, Discord, Microsoft Teams, email, Trello, Monday.com, HubSpot. The list goes on for a while.

A few connections that pair well with the Make.com screenshot API:

• Airtable attachment fields accept binary data directly from the HTTP module — no intermediate storage step needed.
• Google Drive creates timestamped files from the binary response. Combine with a Router to save both PNG and PDF versions simultaneously.
• Slack and Discord handle image uploads natively. Your team sees the screenshot inline, not as a link they have to click.
• Data Store (Make's built-in key-value storage) can hold the previous screenshot's hash for change detection between runs, without needing an external database.

If you're building screenshot scenarios for competitor monitoring, website archiving, or bulk capture jobs, Make's ecosystem handles the routing and storage. ScreenshotRun handles the screenshots. Swap the HTTP caller and everything else stays the same — works just as well with cURL, Node.js, or Python if you ever outgrow the no-code approach.