Keyword: n8n website screenshot automation ยท Updated July 28, 2026

n8n Website Screenshot Automation with an API

A workflow that receives a URL, captures the rendered page, and sends the result to a spreadsheet, database, Slack message, or review queue does not need a custom integration. It needs one well-scoped HTTP request, an API key stored as a credential, and clear handling for failed renders. This guide builds that workflow with SnapshotFlow.

Why use an HTTP workflow for screenshots now?

Workflow tools are increasingly being used to connect agents and production systems. In July 2026, n8n published guidance on governing agents that call internal APIs and execute multi-step workflows; that makes small, least-privilege API steps useful building blocks rather than hidden glue. n8n's guidance specifically emphasizes scoped credentials, runtime controls, and execution records.

There is also a practical content signal: Urlbox published an n8n screenshot workflow in January 2026, while its July CLI article explicitly positions screenshot capture for terminals and agents. That competitor guide is evidence of an active implementation need, not evidence of search volume or a claim that SnapshotFlow has the same native node.

Scope: this article uses n8n's generic HTTP Request node. It does not claim an official SnapshotFlow n8n integration or a prebuilt template.

The workflow: URL in, screenshot URL out

  1. Start with a node that emits a public URL in url: a manual trigger for testing, a webhook, a sheet row, or a CMS event.
  2. Use an HTTP Request node to call GET /screenshot.
  3. Ask for response_type=url so SnapshotFlow returns a text download URL instead of a binary file.
  4. Pass that value to a destination node. The destination might update a record, create a review message, or issue a second request to your own storage.

For a one-off capture or a raw image response, see the Screenshot API quick start. For up to 10 URLs with the same settings, use the separate batch screenshot API guide instead of making an uncontrolled fan-out.

Configure the n8n HTTP Request node

Create an HTTP Request node after the trigger. n8n documents this node as the generic way to call a REST API; consult its HTTP Request node reference for interface details that can change between n8n versions.

Method: GET URL: https://api.snapshotflow.com/screenshot Header X-Api-Key: {{ $credentials.snapshotflowApiKey }} Query parameters url: ={{ $json.url }} format: png width: 1280 height: 800 full_page: true wait_until: networkidle2 response_type: url

In the n8n UI, save the API key in a credential or another protected secret mechanism available in your deployment. Do not place a real key in a Set node, a URL field, or exported workflow JSON. SnapshotFlow accepts the API key in the X-Api-Key header; the repository's API reference lists the capture parameters used above.

Equivalent cURL request for debugging

curl --get "https://api.snapshotflow.com/screenshot" \ -H "X-Api-Key: $SNAPSHOTFLOW_API_KEY" \ --data-urlencode "url=https://example.com" \ --data-urlencode "format=png" \ --data-urlencode "width=1280" \ --data-urlencode "height=800" \ --data-urlencode "full_page=true" \ --data-urlencode "wait_until=networkidle2" \ --data-urlencode "response_type=url"

Expected result and next step

With response_type=url, the API responds with plain text containing a download URL for the rendered image. Configure the HTTP Request node's response format so the next node receives text, then store or forward that value. If the next system expects an image file rather than a URL, either request the default binary image response and configure n8n for a file response, or download the returned URL in a second controlled step.

A URL response is convenient for a review queue, but it is not a substitute for deciding where your organization retains evidence. For durable storage, send the file to the storage system your team controls and record the source URL, capture time, and workflow execution ID together.

Operational advice and edge cases

  • Keep the input boundary narrow. SnapshotFlow only accepts HTTP(S) targets and blocks private or loopback destinations. Validate that upstream URLs are expected public targets before sending them to the API.
  • Make rendering deterministic. Pin width, height, and full_page. Use wait_for_selector when the page has a reliable ready marker; use a bounded delay only when a selector is unavailable.
  • Use cache intentionally. The API caches captures by the complete capture configuration. Set cache=false when the workflow must force a fresh render; otherwise, identical requests can reuse a cached result.
  • Handle errors explicitly. A 400 usually means invalid input, 401 means the API key is missing or invalid, and 403 can mean the target is blocked by SSRF protection. Do not silently treat an error response as a screenshot URL.
  • Respect authorization and platform rules. Cookies and headers can support pages your organization is authorized to access. Keep such secrets out of workflow data, and do not use automation to bypass a site's access controls.

For long-running single captures that should return immediately, SnapshotFlow also supports asynchronous jobs and webhook delivery. That is a different delivery model from the synchronous n8n request shown here; review the async API documentation before using it.

FAQ

Does SnapshotFlow need a native n8n node?

No. The documented HTTP endpoint is enough for the workflow in this guide. A native node would be a separate product integration and is not implied here.

Can I add screenshot automation to an AI agent workflow?

Yes, but use the same controls as any other API call: scoped credentials, constrained URL input, logs, and a clear destination for outputs. For direct tool use by compatible clients, see SnapshotFlow MCP.

Can I capture a logged-in page?

The API supports cookies and headers. Only use them for pages you are authorized to access, and store them in protected credentials rather than in a workflow field.

Sources and further reading

Start with one observable workflow

Test the request with a public URL, inspect the text response, and add storage or notifications only after the capture step is reliable.

Read the API docs