How to Send Scheduled Website Screenshots to an Email Digest with n8n

Use an n8n Schedule Trigger → HTTP Request → Gmail workflow: the trigger starts on a schedule, the HTTP Request node asks a screenshot service to capture each URL and returns the image as a file, and Gmail sends the images as attachments in an HTML email. Save and publish the workflow, set its timezone, and confirm the binary field name in execution data before mapping it into Gmail.

This guide uses a hosted screenshot API so n8n does not need to launch and maintain a browser. The renderer is a separate dependency: its endpoint, authentication, output format, and limits depend on the provider. For the n8n node settings below, see the [Schedule Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/), [HTTP Request](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/), and [Gmail](https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.gmail/) documentation.

1. Set the schedule and timezone

Add a Schedule Trigger as the workflow’s starting node.
Choose a built-in interval such as daily or weekly, or choose a custom cron schedule.
Set the workflow timezone if the digest should follow a particular local time. Otherwise, n8n uses the instance timezone.
Save and publish the workflow. The schedule is not active until it is published.

Examples of custom cron schedules from n8n’s documentation:

0 12 * * 1 — noon every Monday.
0 9 * * 1-5 — 9:00 AM on weekdays.

The standard five fields represent minute, hour, day of month, month, and day of week. n8n also permits an optional sixth field for seconds. A monthly trigger set to a date that a month does not contain will not run in that month.

Do not assume that a missed run will always be replayed. The documented missed-execution options apply to Schedule Trigger nodes added from n8n 2.36 onward and require the durable scheduler. The default in-memory scheduler does not run missed executions. Check the scheduler configuration for your n8n deployment if catch-up behavior matters.

2. Choose a screenshot renderer

The HTTP Request node can call a REST API and save a file response. Choose a renderer whose documented output is image bytes that n8n can store, or account for any extra step needed if it returns a URL or JSON instead.

Before building the request, verify these details in the selected provider’s current documentation:

Endpoint and HTTP method.
API key location, such as a header or query parameter.
Whether the API returns image bytes, a downloadable URL, or a JSON job result.
Supported formats, viewport settings, full-page capture, and any limits.
Whether the target page is reachable from the provider’s network.

One vendor-specific example in the research uses a POST request, an x-api-key header, a public site URL, and the HTTP Request node’s File response format. That provider documents PNG or JPEG output and limits captures to public HTTP/HTTPS sites reachable from the internet. These details are specific to that vendor; do not reuse its endpoint or headers with another renderer without checking that provider’s docs.

ScreenshotNeo is the first option to try when you want a hosted renderer: it removes known cookie and consent banners, newsletter popups, and chat widgets before capture, and only clean shots are billed. Its [website](https://screenshotneo.com) describes a website screenshot API and MCP server; the API supports a single GET request for PNG, JPEG, WebP, or PDF output.

3. Configure the HTTP Request node

Connect an HTTP Request node after the Schedule Trigger.
Set the method and URL to match the screenshot provider’s API documentation.
Configure authentication using the provider’s documented method. n8n supports predefined and generic authentication, along with query parameters, headers, and request bodies.
Pass the website URL and any required capture settings.
Set the response format to File and choose an output field name, for example screenshot.
Run a manual execution once and inspect the node output. Confirm that the response is binary data in the field you selected.

For one fixed URL, the workflow is simply Schedule Trigger → HTTP Request → Gmail. To capture several pages in the same digest, provide the URLs as separate input items and capture each item before composing the message. The exact looping and binary-data mapping depends on your item structure and the provider’s response. Inspect execution data instead of assuming a field name.

If the provider returns a URL or JSON job result rather than image bytes, add the documented follow-up step to retrieve the image before Gmail. A hosted screenshot link alone is not equivalent to an attachment, and email clients may not display a remote image consistently.

4. Send the digest with Gmail

Add the Gmail node after capture. Connect and authorize the Gmail account used to send the digest.
Choose the Send Message operation and enter recipients, subject, and message body.
Set the email type to HTML if you want headings, links, or a list of captured sites.
In the attachment setting, enter the name of the incoming binary field that contains the screenshot, such as screenshot. Use the field name shown in the execution data.
For multiple URLs, make sure your workflow produces the intended digest structure and attaches or otherwise accounts for every screenshot before the Gmail node sends the message.

The Gmail node documentation supports mapping an attachment from an incoming binary field. This guide uses attached images because the cited documentation establishes that path. It does not establish that simply putting a remote screenshot URL in the message will display inline in every email client. Inline images require suitable MIME and content-ID handling, and client behavior should be verified for your recipients.

5. Example workflow shape

Schedule Trigger
  └── HTTP Request (renderer returns image bytes as a file)
        └── Gmail (HTML message + binary attachment)

A practical execution checklist:

The trigger’s timezone matches the intended delivery time.
The workflow is saved and published.
The provider can reach the target URL.
The HTTP Request output is a file, not an error response or JSON payload.
The Gmail attachment field matches the actual binary property name.
A manual run sends the expected recipients one message with the expected attachment or attachments.

6. Add multiple URLs and useful email context

For a small digest, represent each website as an item and let the capture step process each one. Include the page URL or a short label in the item so the email can identify which screenshot belongs to which site. If your workflow aggregates items into one message, verify that the aggregation preserves the binary fields; some workflow shapes require an explicit merge or aggregation step.

Useful digest content can include the capture date, page name, source URL, and a short status for each item. Keep the screenshot itself as an attachment when you need a reliable record available with the email. If your renderer returns a URL instead of binary data, check its retention and access rules before relying on that URL in a recurring digest.

n8n’s HTTP Request node supports GET and POST, headers, query parameters, request bodies, and authentication options. Which of these to use is determined by the renderer’s API; the node’s flexibility does not make one provider’s request format universal.

7. Troubleshooting

Symptom	Likely cause	What to check or change
The scheduled workflow never runs	The workflow is not published, or the configured time zone is not the one you expected.	Save and publish it. Set the workflow timezone explicitly and confirm the schedule expression.
A monthly run is missing	The selected day does not occur in that month.	Choose a day that exists in every month or use a schedule design that handles month-end explicitly.
A missed run did not catch up	The scheduler configuration does not support replay, or the documented feature requirements are not met.	Check whether the node was added in n8n 2.36 or later and whether the durable scheduler is enabled. The default in-memory scheduler does not run missed executions.
The HTTP Request node returns an error	Wrong endpoint, method, credentials, request shape, or an inaccessible target URL.	Compare the request with the selected provider’s current API docs. Confirm the target is reachable from the renderer and that authentication is in the documented location.
The output is not an image attachment	The request is returning JSON, a URL, or an error body, or the response format is not set to File.	Inspect the HTTP Request output. Set File response format when the API returns bytes, or add a follow-up retrieval step for a URL or asynchronous result.
Gmail sends without an attachment	The attachment property name does not match the incoming binary field.	Inspect the capture node’s binary output and map that exact field name in Gmail.
Only one of several screenshots arrives	The workflow’s item or aggregation structure drops binary data or sends one message per item.	Inspect data after each node. Adjust the aggregation and Gmail placement to match whether you want one email per page or one combined digest.
A remote image does not appear in the email	The email references a hosted URL, and the recipient’s client may not load it automatically.	Attach the image through Gmail’s binary attachment mapping. For inline images, implement and verify MIME/content-ID behavior for the email clients you support.

8. Performance, reliability, and cost

Every URL adds a separate rendering operation. For a digest with many pages, account for the provider’s concurrency and request limits and the time needed for pages to load. The research sources do not establish comparative speed, quotas, pricing, retention, or reliability for screenshot services, so check those directly with the provider before scheduling a large recurring workload.

Keep the workflow’s failure behavior visible: inspect execution history, and decide how to handle a failed capture so one unavailable page does not silently produce a misleadingly complete digest. A scheduled trigger and an HTTP request do not guarantee that a page will be available or that its rendering will succeed.

For a hosted provider, the cost model may depend on successful captures, plan quotas, or other terms. Confirm the current pricing and what counts as a billable capture with the provider. The source material does not support a general cost comparison or any performance benchmark.

Or skip the browser setup

Use ScreenshotNeo’s GET endpoint from n8n’s HTTP Request node. Store your API key in n8n credentials or another secret store, then pass it as a query parameter along with the URL. Set the response format to File so the returned image can flow into Gmail as an attachment. See the [ScreenshotNeo API documentation](https://screenshotneo.com/docs/) for request options.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

In n8n, use the same API base and parameters in the HTTP Request node rather than running these snippets: method GET, URL https://api.screenshotneo.com/v1/shot, query parameters access_key and url, response format File. ScreenshotNeo also accepts the parameter names used by other screenshot APIs, which can make switching easier.

Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing status. An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. [Create a free ScreenshotNeo account](https://screenshotneo.com/account/sign-up/).

FAQ

Can I schedule a digest for a specific local time?

Yes. Set the workflow timezone to the intended local timezone. Without it, n8n uses the instance timezone.

Can n8n take the screenshot itself?

This workflow uses an external renderer through HTTP Request. The cited n8n documentation establishes how to call an API and store a file response; it does not prescribe a browser-rendering service.

Can the email show screenshots inline instead of attaching them?

Possibly, but the cited Gmail node documentation supports attachments and does not establish universal inline-image behavior. Inline embedding needs correct MIME and content-ID handling, then testing in the email clients your recipients use.

What if a page is private?

Check whether the renderer supports the authentication and network access the page requires. The cited vendor example only accepts public, internet-reachable HTTP/HTTPS sites; other providers may differ.