ScreenshotNeo

BlogHow-to

How to Automate Website Screenshots with Pipedream and a Screenshot API

Build a Pipedream workflow that captures website screenshots with Puppeteer or a screenshot API, then stores or sends the resulting image.

By the ScreenshotNeo team4 October 202610 min read

To automate website screenshots with Pipedream, create a workflow that receives a trigger, captures a URL with either headless Chromium or a screenshot API, and passes the resulting image to storage or another step. Use Puppeteer when you need browser-level control; use an API action when its documented capture options fit your workflow. Close the browser in every Puppeteer path, and treat screenshot bytes as file data when handing them to later steps.

1. Choose the workflow shape

A typical workflow has four parts:

  1. Trigger: a schedule, webhook, or app event provides a URL or tells the workflow which configured URL to capture.
  2. Capture: a Pipedream screenshot action, a hosted API request, or a Node.js step running Puppeteer creates the image.
  3. Persist or hand off: pass the file to a storage or downstream action. A screenshot response is not durable storage by itself.
  4. Optional delivery: notify a channel, send an email, or pass a link or file to another system.

The right capture path depends on the controls you need and the fields available in the action or service you choose. Pipedream documents both a Puppeteer browser package and a GetScreenshot action. The latter includes a URL, PNG/JPEG/PDF format, optional email delivery, optional DOM selector, additional parameters, and API-key authentication configured through the connected account. Pipedream Puppeteer package documentation; Pipedream GetScreenshot integration.

2. Add a trigger and decide where the URL comes from

Create a Pipedream workflow and choose a trigger appropriate to the job: a schedule for recurring captures, a webhook for on-demand captures, or an app event when another service should initiate the capture. The URL can come from trigger data or from a configured value in the workflow. Validate it before making a request: require https:// or http://, reject empty values, and consider an allowlist if the URL comes from an untrusted caller.

The cited Pipedream materials support browser capture and describe the GetScreenshot action; they do not specify every trigger setup or a complete end-to-end workflow. Configure the trigger and downstream storage using the current options shown in your Pipedream workspace.

3. Use Pipedream’s GetScreenshot action

For a managed capture request, add the GetScreenshot action to the workflow and connect its API-key credentials through Pipedream. Set the URL and select an available output format: PNG, JPEG, or PDF. If supported by the workflow you are building, set the optional email destination, DOM element selector, and additional parameters. Use the action output in a later step to store or deliver the result.

  • URL: provide a complete HTTP or HTTPS URL.
  • Format: select PNG, JPEG, or PDF according to the downstream consumer.
  • Selector: use the optional DOM element selector when you need a targeted element instead of the whole page, as supported by the action.
  • Email: use the optional email delivery field if that matches the workflow; otherwise handle the output in subsequent steps.
  • Additional parameters: consult the action’s current configuration for supported values rather than assuming another provider’s parameter names will work.
  • Credentials: connect the API key using Pipedream’s credential flow. Avoid hardcoding secrets in source code or logging them.

Action fields and provider behavior can change. Confirm the live action configuration and the screenshot provider’s current service terms before relying on a particular option.

4. Capture with Puppeteer in a Node.js step

Use browser automation when you need to navigate and capture through a browser in the workflow. Pipedream’s Puppeteer package documentation describes importing the browser module, launching a headless Chromium browser, taking a screenshot, and closing the browser before the step completes. The package page recommends increasing workflow memory to 2 GB for best results with browser automation. This is a package-page recommendation, not a guarantee that every workflow needs or receives the same resources. See Pipedream’s Puppeteer package documentation.

In a Pipedream Node.js code step, use the browser module exposed by the Puppeteer package available in that step. The following is an implementation outline: verify the import syntax and module name against the package page and the step’s current runtime, since package setup can change.

import puppeteer from "puppeteer";

export default defineComponent({
  async run({ steps, $ }) {
    const url = steps.trigger?.event?.url ?? "https://example.com";
    if (!/^https?:\/\//i.test(url)) {
      throw new Error("URL must begin with http:// or https://");
    }

    const browser = await puppeteer.launch({ headless: true });
    try {
      const page = await browser.newPage({
        viewport: { width: 1440, height: 900 },
      });
      await page.goto(url, { waitUntil: "networkidle2", timeout: 60000 });
      const screenshot = await page.screenshot({
        type: "png",
        fullPage: true,
      });

      // Pass screenshot bytes to a downstream action using the format
      // that action accepts. Avoid exporting a large binary as step data.
      return { url, contentType: "image/png", screenshot };
    } finally {
      await browser.close();
    }
  },
});

The example illustrates the browser lifecycle and capture choices; adapt trigger data access and binary handoff to the actual workflow. The package documentation specifically warns that the browser should be closed at the end of the Node.js code step, because leaving it open can keep the step running.

Useful browser choices

  • viewport sets the visible browser dimensions; choose dimensions that match the page view you want.
  • fullPage: true requests the full page rather than only the current viewport. Very long pages can produce large files and take longer.
  • waitUntil controls the navigation readiness condition. Network-idle conditions can be unsuitable for pages that keep requests open; use a different readiness condition and an explicit wait when appropriate.
  • timeout bounds navigation waiting. Choose a limit that fits the workflow’s execution constraints and the sites you capture.
  • Wait for a known selector when page content appears after navigation, if the page exposes a stable selector. Handle the case where it never appears.

5. Handle image output and downstream steps

Keep capture separate from persistence. Decide whether the next step needs raw bytes, a temporary file path, or a durable object in a storage service, and pass the representation that step expects. A Site-Shot vendor tutorial recommends writing API image bytes to /tmp and passing a path downstream rather than returning raw PNG bytes as step output. That is vendor guidance, not a verified statement of Pipedream platform limits; check current first-party Pipedream documentation for file and payload constraints before setting hard limits. Site-Shot’s Pipedream tutorial.

For an API action, inspect the action output and use its documented binary or file representation. For Puppeteer, page.screenshot() returns image bytes. If a downstream step expects a file, write those bytes to a file using the runtime’s supported file APIs, then hand off the path or upload the file. For a lasting record, upload or otherwise persist the file in a durable destination rather than assuming temporary workflow storage will remain available.

Keep the handoff small and explicit

  • Include useful metadata with the image: source URL, capture time, chosen format, and workflow run identifier where available.
  • Prefer a stored file reference or path for downstream processing when the platform and action support it.
  • Do not log API keys, authorization headers, cookies, or sensitive page content.
  • For multiple captures, process results in a way that respects the capture provider’s limits and the workflow’s execution and storage constraints.

6. Decide between browser automation and an API action

Need Starting point What to check
Managed request with simple documented fields Pipedream GetScreenshot action Current formats, selector behavior, optional delivery, additional parameters, credentials, and provider terms.
Browser navigation or custom code orchestration Puppeteer Node.js step Package setup, memory guidance, navigation waits, browser cleanup, and binary handoff.
Capture controls or output behavior beyond the action’s fields Evaluate a screenshot API directly Required options, authentication, output format, failure behavior, billing terms, and downstream integration.

The cited sources do not establish a detailed feature-by-feature comparison or pricing comparison between these paths. Choose based on the controls and operational requirements you can verify. Browser automation runs Chromium inside the workflow, so account for its memory and execution needs. An API avoids managing the browser in your code step, but its capture controls and service terms depend on the selected provider.

7. Troubleshoot common failures

Symptom Likely cause Fix
The workflow step stays open The Puppeteer browser was not closed. Put await browser.close() in a finally block so it runs on success and error paths.
Navigation times out The site is slow, blocks automation, or keeps network requests open while waiting for network idle. Set a deliberate navigation timeout, use a readiness condition suited to the page, and wait for a stable selector when available. Handle timeout errors explicitly.
The image is blank or incomplete The capture happened before client-rendered content or images appeared, or the chosen viewport does not show the intended content. Wait for a meaningful selector or page state; verify the target URL and viewport; test full-page capture for content below the fold.
Browser launch or capture fails under load Browser automation resource needs exceed the workflow configuration. Review Pipedream’s current package guidance, including its recommendation of 2 GB memory for best results with browser automation. Reduce concurrency or capture scope if needed.
Downstream step cannot consume the image Raw binary was returned where the next action expects a file, path, or another encoding. Check the downstream action’s input contract and pass bytes or a file reference in that required form. Consider a temporary file handoff and verify current platform constraints.
GetScreenshot rejects the request Invalid URL, missing or invalid connected credentials, or an unsupported action option. Check that the URL starts with HTTP or HTTPS, reconnect the API-key account, and confirm the live action fields and provider requirements.
Secrets appear in logs or code Credentials were embedded or printed as ordinary data. Use the connected credential mechanism and remove secret values from logs and returned step data.
Workflow succeeds but no one can retrieve the image later The file was only handed off temporarily and never persisted. Add an explicit durable storage or delivery step and retain its resulting reference.

8. Performance, reliability, and cost

Performance

Full-page captures, large pages, and slow network or script execution increase capture work and image size. Use the smallest viewport and capture area that satisfy the use case. Avoid waiting indefinitely for network idle on pages with continuous requests; wait for the content that matters. Reuse a managed API when its controls fit and running a browser in the workflow is unnecessary, but check its own response time and limits rather than assuming a particular speed.

Reliability

Validate input URLs, set timeouts, close browser resources in a finally block, and make downstream persistence explicit. Decide how the workflow should handle a failed capture: fail the run, route the error to a notification, or retry only when the failure is plausibly transient. Avoid blind retries for invalid URLs or persistent access restrictions. Store enough metadata to identify what was captured and when.

Cost and operating load

No usage price, quota, or comparative cost is established by the cited research for Pipedream, GetScreenshot, or Site-Shot. Check current Pipedream workflow pricing and the selected screenshot provider’s plan before scheduling frequent or high-volume captures. Browser automation also uses workflow resources; Pipedream’s Puppeteer page recommends 2 GB memory for best results. Include downstream storage and delivery costs in your estimate.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Make one GET request to capture a URL; its API documentation describes the available parameters.

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', new Uint8Array(await res.arrayBuffer()));

In Pipedream, put the API key in a connected secret or credential and construct the same GET request in a Node.js step; pass the response bytes or saved file to your persistence step. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents use screenshot tools. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000, and every feature is available on every plan. Sign up free for 1,000 screenshots a month, with no card required.

9. FAQ

Can a Pipedream workflow capture a screenshot on a schedule?

Yes. Use a schedule trigger, provide the URL from workflow configuration or trigger data, capture it, and add a step that stores or delivers the result.

Should I use PNG, JPEG, or PDF?

Choose the format accepted by the next step and suited to the output: the documented GetScreenshot action offers PNG, JPEG, and PDF. Confirm any format-specific behavior with the current provider documentation.

Does the screenshot action automatically save files permanently?

The documented action provides a capture workflow, but durable storage is a separate workflow decision. Add a storage or delivery step and retain its file reference.

Do I need to run Puppeteer if I use a screenshot API?

No. Use the API action or request when its supported fields meet the capture needs. Use Puppeteer when the workflow needs browser automation and control available in the browser step.

Is a temporary file path a guaranteed Pipedream requirement?

No such platform requirement is established by the cited material. A vendor tutorial recommends a temporary file path for image bytes; verify current Pipedream file and payload guidance for the workflow you build.