How to Capture a Website Screenshot from Airtable with Make

Direct answer: Create a Make scenario with an Airtable trigger, send the record’s page URL to a screenshot API through Make’s HTTP module, then save the returned image or image reference and update the Airtable record. The screenshot API does the browser rendering; Make connects the trigger, request, and output steps.

Use Airtable → Watch Records for new or changed records, or Watch Responses when a form submission should start the capture. Add HTTP → Make a request to call the provider’s documented endpoint. The next step depends on whether the provider returns image bytes, a hosted image URL, or a redirect.

What you need

An Airtable base containing the page URL to capture.
A Make connection to Airtable and a scenario with the appropriate trigger.
A screenshot API account and its documented request format, authentication method, and response format.
A destination for the result: an Airtable attachment or text field, or another storage service suited to your retention needs.

Make’s HTTP app can connect to a service when there is no native integration. Its Airtable and HTTP integration documents both request and file-download actions. Make Airtable and HTTP integration

Design the Airtable capture queue

A simple queue makes the automation easier to operate. Create fields such as:

Field	Purpose
Page URL	The public URL the screenshot service should render.
Status	For example, queued, complete, or failed; use values that fit your process.
Screenshot	An attachment or other output reference, depending on the provider response and Airtable module mapping.
Captured at	Optional timestamp for tracking when a successful capture was produced.
Error detail	Optional short diagnostic; avoid storing secrets or sensitive URL query parameters here.

These are workflow design suggestions, not required Airtable fields. For a Watch Records trigger, Make requires a Created Time or Last Modified Time field and watches records in a selected view. Choose the timestamp field that reflects the changes you want to trigger. Make Airtable modules

Build the Make scenario

Choose the trigger. For a table-driven queue, select Airtable → Watch Records and choose the base, table, view, and timestamp field. A view that filters for eligible records can keep unrelated edits from starting captures.
Connect Airtable. Use Make’s current connection flow and grant access appropriate to the base and actions in the scenario. Keep credentials in the connection or secret configuration, not in record fields. Make connection guidance
Add HTTP → Make a request. Set the method, endpoint, authentication, headers, and body to the screenshot provider’s API contract. Map the Airtable Page URL into the provider’s target URL parameter. Do not assume all screenshot APIs use the same method or payload.
Set capture options supported by the provider. Confirm whether it supports output formats, viewport size, full-page capture, waits, or authenticated pages. Only send options documented by that provider.
Inspect and route the response. If the result is a URL, pass that URL to the appropriate download or attachment step. If it is a redirect, follow the provider’s documented redirect behavior. If it returns bytes, configure Make’s response and downstream modules to handle a file. A universal binary-to-Airtable attachment mapping is not established by the general Make documentation; validate the mapping for the selected provider and Airtable module.
Update the Airtable record. Use the record ID from the trigger to write the resulting attachment or reference, status, and optional capture timestamp. Make’s Airtable modules include Update a Record. Airtable module reference
Run one controlled scenario execution. Start with a public page you are allowed to capture. Check the HTTP response and confirm the stored output opens before enabling the scenario for the full queue.

Configure the HTTP request safely

The exact request depends on the screenshot provider. Before mapping fields, check its API documentation for:

HTTP method and endpoint: GET versus POST and the precise route.
Authentication: Header, query parameter, or another supported mechanism. Prefer Make’s secure connection or secret handling where available.
Request shape: Query parameters, JSON body, required target URL field, and optional capture settings.
Response shape: Raw image bytes, JSON containing a URL, or a redirect to an image or PDF.
Timeout and asynchronous behavior: Whether the provider renders within one request or returns a job that must be polled or delivered by webhook.
Page access: Whether the target must be public or can be accessed using provider-supported cookies or headers.

For example, Screenshot API documents a POST request to /api/v1/screenshot with JSON input and an optional redirect to the resulting image or PDF. That is one provider’s contract, not a general standard. Screenshot API REST documentation

Use an Airtable form submission as the trigger

If the screenshot should run when someone submits an Airtable form, use Make’s Airtable Watch Responses flow rather than polling a table. Make’s documented setup is:

Add the Watch Responses trigger in Make and generate its webhook URL.
In the Airtable form settings, set the redirect-to-URL value to that webhook URL and append ?record_id={record_id}.
Use the received record ID to look up the record and map its Page URL into the screenshot request.
Continue with the same response handling and record update steps described above.

In this setup, Make’s Airtable documentation says Airtable supports sending the record_id parameter. Make Airtable modules

Store the result with the right lifetime

Choose storage based on how long the screenshot must remain available. An Airtable attachment may be convenient for a record-centric workflow, but Airtable API attachment download URLs are temporary: Airtable says they remain active for at least two hours and recommends downloading attachments before expiry. Treat those URLs as temporary access links, not permanent public image URLs. Airtable attachment URL behavior

If the screenshot API returns a hosted URL, check that service’s retention and access rules before saving the URL as a durable reference. If the workflow requires long-term or public access, use storage with a lifetime and access model that matches that need, and save its stable reference in Airtable.

Ordering, retries, and sensitive data

Keep captures in arrival order when it matters

Instant webhook-triggered Make scenarios process requests in parallel by default. If later steps depend on captures finishing in submission order, enable Process data in order. Make also documents per-webhook queues and rejection when a queue is full, so account for queue capacity when bursts are possible. Make Webhooks help

Make failures recoverable

Keep a status field so a failed capture can be identified and retried.
Separate the HTTP request failure path from the success path if your scenario design supports it, and record a concise diagnostic.
Avoid retrying permanent failures, such as an invalid URL or rejected credentials, without correcting their cause.
For asynchronous providers, persist the job identifier and follow the provider’s polling or webhook instructions rather than assuming the initial response contains the image.

Protect keys and target URLs

A provider key authorizes requests and may cause billable usage; a target URL may contain private content or tokens. Keep both out of broadly accessible Airtable fields and scenario logs where possible. Use access controls appropriate to the data and avoid capturing pages you are not authorized to access. This is operational guidance based on the credential and URL handling involved in the integration. Screenshot API docs, Make connection guidance

Performance and cost planning

Each eligible record typically causes a screenshot request plus any download and update operations. For large queues, consider how quickly the provider renders pages, Make operation usage, provider quotas or pricing, and the destination’s storage limits. The available sources do not provide a complete cross-provider price comparison, so check current provider terms before estimating per-record cost.

Reduce unnecessary runs: Watch a filtered view or use a status gate so edits unrelated to the URL do not trigger captures.
Control concurrency: Use ordered processing when sequence matters; otherwise account for parallel requests and provider limits.
Handle heavy pages: Page rendering can take longer for slow or resource-heavy targets. Use the provider’s supported wait and timeout controls and configure Make accordingly.
Plan storage: Large image files and repeated captures increase storage use. Keep only the versions the workflow needs.
Measure from your own scenario: Review Make execution history and provider usage information for your actual volume; no generic benchmark applies to every site or provider.

Troubleshooting

Symptom	Likely cause	What to check
No scenario run for a changed record	The trigger is watching a different view or timestamp field, or the required Created Time / Last Modified Time field is missing.	Check the Watch Records configuration, selected view, and timestamp field.
HTTP 400 or validation error	Wrong method, missing target URL, malformed JSON, or unsupported option.	Compare the Make request with the provider’s endpoint and example payload; remove undocumented parameters.
HTTP 401 or 403	Credential is missing, invalid, or lacks access.	Check the provider’s required authentication location and refresh or replace the stored secret.
HTTP 429 or provider rejection	Rate or account limit reached, or too many concurrent requests.	Check provider limits and usage, reduce concurrency or queue work, and retry according to provider guidance.
Request times out	The target is slow, rendering takes longer than the request allowance, or the provider uses an asynchronous job flow.	Check provider timeout and async documentation; use polling or webhook completion if required.
Scenario succeeds but no attachment appears	The response is a URL, redirect, or binary file that the next module is not mapping correctly.	Inspect the actual response type. Add a download step for a URL when appropriate and map the file fields required by Airtable.
Attachment link stops working later	An Airtable API download URL was treated as permanent.	Download or copy the attachment to storage with the needed retention and save a durable reference.
Records finish out of order	Instant webhook scenarios are processing in parallel.	Enable Make’s Process data in order setting if sequence is a requirement.
Some pages are blank or incomplete	The page blocks automated access, needs more render time, or loads content after the initial page response.	Check the provider’s page access, wait, and capture options; inspect the target manually and test its documented settings.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. Make can call its screenshot endpoint with a GET request. The request below saves a WebP response to a file; the API documentation lists the available parameters and behavior: ScreenshotNeo API docs.

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

In Make, use HTTP → Make a request with method GET, URL https://api.screenshotneo.com/v1/shot, and query parameters access_key and url. Map the Airtable Page URL into url, keep the key in protected configuration, and route the returned image according to your storage module. For command-line or application workflows, the same endpoint can be called with cURL, Python, or Node.js:

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)

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

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say which page verdict and billing outcome applied. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Can Make take a website screenshot without a screenshot service?

The workflow described here uses a screenshot API to render the page. Make’s HTTP module sends the request and handles the response; the renderer is provided by the API.

Can I save the screenshot directly into an Airtable attachment field?

That depends on the response shape and the Airtable module’s supported file mapping. A returned URL, redirect, and raw image bytes require different handling; verify the mapping with the selected provider.

Should I use Watch Records or Watch Responses?

Use Watch Records for new or changed table records. Use Watch Responses when the event is an Airtable form submission routed through Make’s webhook setup.

Can the scenario capture private pages?

Only if the selected screenshot provider supports the required authentication and access method. Check its documentation and protect any page credentials and tokenized URLs.