Automating Screenshots with Pipedream: A Developer-Friendly No-Code Recipe

Pipedream sits in a useful middle ground between fully no-code tools like Zapier and writing a standalone service: workflows are built from connected steps like any automation platform, but any step can drop into plain Node.js code when a form field isn't enough. That makes it a good fit for teams that want automation speed without giving up control over the request.

This walks through a workflow that captures a screenshot whenever a webhook fires, with a code step handling the request.

What This Workflow Does

1. Trigger: an HTTP webhook step, giving the workflow its own unique URL to receive events from anywhere (a form submission, another app's webhook, a manual curl).
2. Action: a Node.js code step that calls the Snapshot Site API with the URL from the incoming payload.
3. Action: the resulting screenshot URL gets forwarded wherever the workflow needs it next — Slack, a database, another webhook.

Step 1: Start with an HTTP Trigger

Create a new Pipedream workflow with the HTTP / Webhook trigger. Pipedream generates a unique endpoint URL immediately — any system that can send a webhook, including a form tool, a CMS, or another automation platform, can now kick off this workflow.

Step 2: Add a Node.js Code Step

Pipedream's code steps run plain Node.js with fetch available out of the box:

export default defineComponent({
  async run({ steps, $ }) {
    const url = steps.trigger.event.body.url;

    const response = await fetch("https://api.prod.ss.snapshot-site.com/api/v1/screenshot", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "x-snapshotsiteapi-key": process.env.SNAPSHOT_SITE_API_KEY,
      },
      body: JSON.stringify({
        url,
        format: "png",
        width: 1440,
        fullSize: true,
        hideCookie: true,
      }),
    });

    return await response.json();
  },
});

Storing the API key as a Pipedream environment variable (rather than hardcoding it in the step) keeps it out of the workflow's visible code and reusable across steps.

Step 3: Forward the Result

Add a subsequent step referencing steps.capture_screenshot.$return_value (or whatever the code step is named) to route the screenshot URL into a Slack message, a database write, or a response back to whatever triggered the webhook in the first place.

Why the Code-Step Approach Fits Here

A pure no-code app might expose a fixed set of fields for a screenshot action. A code step exposes every parameter the API supports — delay, hide, format, threshold on compare calls — with the same flexibility as writing a standalone script, just without needing to host or deploy anything. For teams that want automation speed on the trigger/routing side but full control over the actual API request, this is a natural fit.

Extending the Workflow

Once the base workflow works, natural extensions include:

• Swapping the HTTP trigger for a schedule trigger to capture a fixed list of pages on a recurring basis.
• Adding a second code step calling /api/v3/compare to diff the new capture against a stored baseline.
• Branching the workflow based on the response, alerting only when a mismatch or analysis result crosses a threshold.

If you're comparing Pipedream against more form-based automation tools for this kind of workflow, Sending Snapshot Site Screenshots to Slack and Google Sheets with Zapier and Automating Screenshots with Make cover the equivalent setups.

Snapshot Site works the same way regardless of which platform is making the call — a code step, a form field, or a script all send the same request.