Automate Screenshots in Zapier and Make with a Screenshot API

If you've ever needed a screenshot of a webpage saved to Google Drive, attached to a Slack message, or dropped into a Notion database — and you didn't want to write a backend service to do it — you've probably landed on the same combination most developers and SaaS builders eventually reach: a screenshot API wired into Zapier or Make.

The tricky part isn't the concept. It's the setup. Most tutorials show you a generic "call this webhook" screenshot without covering the actual configuration details — headers, response types, polling vs. instant responses, and where things silently break. This post covers that.

Why Use Zapier or Make Instead of Writing Custom Code

A screenshot API like PxShot is just an HTTP endpoint — you send a URL and some parameters, and you get back an image or PDF. You could call that from a Node script or a serverless function, but Zapier and Make exist for a reason:

• No hosting required. You don't need a server running 24/7 to listen for triggers.
• Built-in triggers. New row in Airtable, new form submission, new Trello card — all pre-built.
• Faster iteration. Change a workflow in minutes instead of redeploying code.
• Non-developers can maintain it. Once built, a teammate can tweak the workflow without touching code.

The tradeoff is you're constrained by what the automation platform's HTTP modules support. Understanding those constraints up front saves hours of debugging.

Setting Up a Screenshot API Call in Zapier

Step 1: Choose Your Trigger

Common triggers that pair well with screenshot capture:

1. New row added in Google Sheets (e.g., a list of URLs to monitor)
2. New form submission (Typeform, Google Forms) containing a URL field
3. New record created in Airtable
4. Scheduled trigger (Zapier's built-in "Schedule" app) for recurring captures

Step 2: Add a "Webhooks by Zapier" Action

This is where most people get stuck, so here's the exact config:

• Action event: GET (or POST, depending on your API's method)
• URL: your screenshot API endpoint, e.g. https://api.pxshot.dev/v1/screenshot
• Query String Params: map fields like url, format (png, jpeg, webp, pdf), width, height, and full_page
• Headers: include your Authorization: Bearer YOUR_API_KEY header — this is the step people forget, and it results in a silent 401 that Zapier reports as a generic failure

Step 3: Handle the Response

This is the part that trips people up most. Screenshot APIs typically respond in one of two ways:

• Direct binary response — the image bytes come back immediately in the response body. You'll need to pass this into a downstream action that accepts a file (like "Upload File" in Google Drive) rather than a text field.
• JSON response with a hosted URL — the API returns something like {"url": "https://cdn.pxshot.dev/shots/abc123.png"}. This is easier to work with in Zapier because you can pass the URL string into almost any downstream field, including Slack messages, email bodies, or database records.

If your API supports both modes, prefer the JSON-with-hosted-URL approach for Zapier workflows — it avoids binary-handling headaches entirely and works with far more downstream apps.

Step 4: Send It Somewhere

Popular endpoints for the captured screenshot:

1. Google Drive — "Upload File" action, using the file field from your webhook response
2. Slack — post the image URL directly in a message; Slack auto-unfurls it
3. Airtable — update a record's attachment field with the hosted URL
4. Notion — add the URL to a page property or embed block

Setting Up the Same Workflow in Make

Make (formerly Integromat) gives you more granular control over data flow, which makes it slightly better suited for screenshot automation once workflows get complex.

Step 1: Add an HTTP Module

Use "Make a Request" from the HTTP app:

• Method: GET or POST matching your API's spec
• URL: the screenshot API endpoint
• Headers: API key, and Accept: application/json if you want the hosted-URL response mode
• Parse response: toggle this on if you're expecting JSON — Make will automatically let you reference nested fields like data.screenshot_url in later modules

Step 2: Add a Router If You Need Multiple Outputs

A common pattern: one screenshot capture feeds three separate destinations — a database record, a Slack alert, and an email digest. Make's Router module lets you branch after the HTTP call so you only make the API request once, rather than triggering three separate screenshot captures.

Step 3: Handle Binary Data Properly

If your screenshot API returns raw image bytes instead of a hosted URL, Make's HTTP module has a "Show advanced settings" toggle where you can set the response type to binary. This lets you pipe the output directly into Google Drive, Dropbox, or S3 upload modules without needing an intermediate hosted URL.

Real Workflow Examples

1. Automated Visual Monitoring

Trigger: Scheduled every 6 hours. Action: capture a screenshot of a competitor's pricing page via the screenshot API, save to Google Drive with a timestamped filename, and post to a Slack channel for the team to eyeball changes.

2. Auto-Generated OG Images

Trigger: New blog post published (RSS or CMS webhook). Action: call the screenshot API with the post's URL and a specific viewport size (1200x630), save the resulting PNG, and update the CMS's og:image field automatically.

3. PDF Reports from Dashboards

Trigger: New form submission requesting a report. Action: call the screenshot API with format=pdf pointed at an internal dashboard URL, then email the resulting PDF to the requester.

4. Link Preview Cards

Trigger: New URL added to an Airtable base. Action: capture a thumbnail screenshot, attach it to the record, so the team has a visual reference without clicking through every link.

Common Mistakes When Wiring This Up

• Forgetting to URL-encode the target page's URL when it's passed as a query parameter — special characters break the request silently.
• Not setting a timeout buffer. Full-page screenshots of long pages can take a few seconds longer than simple viewport captures; if your automation platform's HTTP timeout is too aggressive, you'll get intermittent failures.
• Ignoring rate limits. If your trigger fires on every row in a 500-row spreadsheet, you'll hit API limits fast — batch or throttle instead.
• Hardcoding image dimensions that don't match the destination (e.g., using a full desktop viewport for a Slack thumbnail that gets squeezed down anyway).

Choosing an API That Plays Well With No-Code Tools

Not every screenshot API is built with automation platforms in mind. When picking one for Zapier or Make workflows, check for:

• A simple GET-request option (some APIs require complex POST bodies that are awkward to build in no-code tools)
• JSON responses with a hosted URL, not just raw binary
• Support for PNG, JPEG, WebP, and PDF output from the same endpoint
• Predictable, documented query parameters for viewport size, full-page capture, and delay before capture

PxShot was built around exactly this kind of simplicity — a single HTTP GET request with query parameters returns either a direct image or a JSON payload with a hosted URL, which makes it drop-in compatible with both Zapier's Webhooks app and Make's HTTP module without any binary-handling gymnastics.

Try wiring it into your next workflow using the free tier at pxshot.dev — it's enough to build and test a full Zapier or Make automation before you need to think about scaling up.