How to Pass a Webpage URL and Viewport Size to a Screenshot API in n8n

Use n8n’s HTTP Request node to send the page URL and viewport width and height as query parameters, then set the response format to File so the screenshot is available as binary data for later workflow steps. The exact parameter names and authentication depend on the screenshot API. The example below uses ScreenshotOne’s documented /take endpoint; adapt those fields to your provider’s API reference.

1. Prepare the workflow input

Make sure the item entering the HTTP Request node has a URL and dimensions. Add a Set or Edit Fields node before it and create fields such as:

{
  "url": "https://example.com",
  "width": 1440,
  "height": 900
}

These property names are examples. If your incoming fields are named differently, use those names in the expressions below. Keep the URL as a complete address, including https://. Use positive integer dimensions in pixels.

2. Configure the HTTP Request node

Add an HTTP Request node after the input or mapping node.
Set Method to GET.
Set URL to https://api.screenshotone.com/take.
Enable Send Query Parameters and add the parameters below. Use expressions for values coming from the incoming item.
Set the response format to File and choose an output field name such as data.

Parameter	Example value	Purpose
`url`	`{{ $json.url }}`	Page to capture.
`viewport_width`	`{{ $json.width }}`	Browser viewport width in pixels.
`viewport_height`	`{{ $json.height }}`	Browser viewport height in pixels.
`access_key`	Your ScreenshotOne key	Authenticates the request. Store it using your n8n credential or secret-handling method.

In n8n, query parameters can be entered as name/value rows or as JSON. Expressions such as {{ $json.url }} read values from the current item. If you import a cURL command, review the resulting parameter types: imported values may be strings. Use JSON input when preserving numeric or boolean types matters. The HTTP Request node returns the response body by default; File response mode is needed when downstream nodes need the image bytes.

3. Pass viewport values as expressions or fixed values

Use expressions when each item supplies its own dimensions. For a fixed desktop capture, enter literal values such as 1440 and 900 instead. ScreenshotOne documents defaults of 1280 × 1024 pixels when viewport dimensions are omitted. Those names, defaults, and authentication fields are specific to ScreenshotOne; other providers may use different names or send the dimensions in a JSON body.

If a device preset is more appropriate, check the provider’s device emulation options. A device preset can select related viewport properties, and explicit dimensions may override them. Emulation represents a configured device profile rather than a physical phone or tablet.

4. Use the screenshot in later nodes

With the response set to File, the HTTP Request node places the image in the configured binary property, for example data. Connect a downstream node that accepts binary input to save, upload, email, or process the screenshot. Confirm the actual binary property name in the node output before configuring the next step.

If you need to inspect status codes or response headers while handling errors, enable Include Response Headers and Status. By default, the node returns the body, and successful execution generally corresponds to a 2xx response. Configure the node’s error handling deliberately if the workflow should continue after a failed capture.

5. Complete provider-specific example

This example shows the request shape for ScreenshotOne. In the HTTP Request node, map the incoming fields and keep the key in n8n’s secret or credential handling rather than exposing it in a public workflow export.

GET https://api.screenshotone.com/take

Query parameters:
  url             = {{ $json.url }}
  viewport_width  = {{ $json.width }}
  viewport_height = {{ $json.height }}
  access_key      = YOUR_SCREENSHOTONE_ACCESS_KEY

Response format: File
Output field: data

For a different screenshot API, retain the n8n workflow pattern but replace the endpoint, authentication, parameter names, and response settings with that provider’s documented requirements.

6. Choose dimensions for full-page captures

The viewport is the browser’s visible content area. Width affects responsive breakpoints, so changing it can change navigation, column count, and other page layout choices. Height can have different effects depending on the provider’s full-page capture algorithm. ScreenshotOne documents a default algorithm that may stretch the viewport to the page height, while its by_sections algorithm uses the viewport height for each captured section.

When comparing captures, record the viewport width and height, whether full-page capture is enabled, and the capture algorithm. Do not confuse viewport dimensions with output image resizing: ScreenshotOne documents image resizing separately from viewport settings.

7. Troubleshooting

Symptom	Likely cause	Fix
The API reports a missing URL.	The expression points to a field that does not exist, or the URL field is empty.	Inspect the incoming item and map the expression to its actual property name. Confirm the URL includes a scheme such as `https://`.
The API reports invalid dimensions.	Width or height is absent, zero, negative, non-numeric, or outside the provider’s limits.	Check the incoming values and the selected provider’s documented dimension constraints. Use positive integer pixel values.
The key is rejected or the request is unauthorized.	The key is missing, incorrect, expired, or sent under a parameter/header name the provider does not accept.	Verify the provider’s authentication instructions and credential value. Avoid sharing execution data that exposes the key.
The node succeeds but a later node cannot find an image.	The response is being treated as JSON/text, or the downstream node expects a different binary property.	Set response format to File, note the configured output field, then select that same binary property downstream.
The screenshot has the wrong responsive layout.	The width selected a different CSS breakpoint than expected.	Set the intended viewport width and rerun. Compare captures at the same width when checking visual changes.
The full-page image height differs from expectations.	The provider’s full-page algorithm uses viewport height differently, or output resizing was mistaken for viewport control.	Check the provider’s full-page capture options and distinguish capture dimensions from post-capture image resizing.
The workflow stops on an HTTP error.	The API returned a non-2xx response and the node’s error behavior stopped execution.	Inspect status and response headers/body. Enable response status and headers if useful, then configure error handling and retries according to the provider’s error semantics.
A public page works, but a private page does not.	The target requires authentication, cookies, or headers that were not included in the capture request.	Check whether the chosen screenshot API supports the required credentials and how it expects them. Do not assume one provider’s authentication fields apply to another.

8. Performance, reliability, and cost

Keep image data binary: pass the File response through binary-capable nodes. Avoid converting large images to text unless a downstream API explicitly requires base64.
Expect variable capture time: page load, scripts, and network resources affect completion time. Set timeouts based on the provider’s documented behavior and the workflow’s execution limits.
Handle transient failures intentionally: use retries only where appropriate, and consider the possibility that a repeated request could create another billable capture with providers that charge per request. Check the selected service’s billing and retry semantics.
Control concurrency and volume: large batches can multiply API calls and workflow runtime. Use batching or rate controls that match both n8n capacity and the provider’s limits.
Track usage: record the input URL, requested dimensions, response status, and execution time where appropriate. Keep API keys and private page data out of logs that are broadly accessible.
Understand the cost model: pricing, free quotas, failed-request charges, and cache behavior differ by provider. Confirm current terms in the chosen API’s documentation before running high-volume workflows.

Or skip the browser setup

ScreenshotNeo accepts one GET request with a URL and returns a PNG, JPEG, WebP, or PDF. Its API uses width and height parameters for viewport dimensions; see the ScreenshotNeo API documentation for request options and authentication. The sample below saves the returned image bytes to a file:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -d width=1440 \
  -d height=900 \
  -o shot.webp

In n8n, use the same URL, method, query parameter mapping, and File response configuration described above, with ScreenshotNeo’s endpoint and parameter names. Cookie banners are accepted like a visitor and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say which result occurred. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000, and every feature is on every plan. Learn more at ScreenshotNeo.

FAQ

Can I send a different URL for every item?

Yes. Map the URL field with an expression such as {{ $json.url }}, and ensure every incoming item contains a valid URL.

Do viewport dimensions determine the final full-page image dimensions?

Not always. Viewport width affects page layout, while full-page algorithms can use viewport height differently. The final image can also be resized separately.

Can I use another screenshot provider?

Yes. Keep the HTTP Request and binary-response pattern, then follow that provider’s current documentation for endpoint, authentication, parameter names, limits, and error handling.