Send email from Pipedream by receiving an event in a Pipedream HTTP / Webhook trigger, mapping its fields in a server-side code step, and calling the Volanea email API. This approach does not require a native Pipedream app or marketplace integration: it uses Pipedream’s workflow trigger and code capabilities directly.

What this Pipedream-to-Volanea workflow does

Pipedream is useful when an email should happen because another system emitted an event: a form was submitted, a CRM record changed, a payment succeeded, or an internal service posted a webhook. Volanea is the delivery layer that accepts the rendered message and sends it as transactional email.

The basic workflow has three hops:

An external system sends an HTTP request to a Pipedream workflow URL.
Pipedream’s HTTP / Webhook trigger starts a workflow run and exposes the incoming event to later steps.
A Pipedream Node.js code step validates and maps the event, then makes a server-to-server POST request to the Volanea REST API.

That separation matters. The originating application does not need the Volanea API key, and it does not need to know how email sending works. It only needs to send a well-defined event to the Pipedream endpoint.

For example, a form backend might post a contact.created event after it stores a new inquiry. Pipedream can turn that event into a confirmation email for the person who submitted the form, a notification to the sales team, or both. The event is the trigger; email delivery is an explicit workflow step, not something embedded in browser code.

Why use an HTTP / Webhook trigger

Pipedream supports HTTP / Webhook triggers for workflows. An HTTP request to the workflow’s unique endpoint starts a run, and the incoming request event is available to the workflow’s downstream steps. This is a practical fit when your source system can make an outbound webhook or HTTP request.

The concrete trigger in this integration is therefore an incoming HTTP request to the Pipedream HTTP / Webhook trigger. In the example below, the request represents a form submission that has already been accepted by your application:

{
  "event": "contact.created",
  "event_id": "evt_01JCONTACT9E5T5G",
  "occurred_at": "2026-09-23T14:42:18.901Z",
  "data": {
    "email": "ada@example.com",
    "first_name": "Ada",
    "company": "Analytical Engines Ltd",
    "message": "Please send me the implementation guide.",
    "consent": true
  }
}

This is the payload your form backend sends to Pipedream, not a format that Volanea creates automatically. You control it, which is an advantage: version it, document it, and avoid coupling your email workflow to a provider-specific event format.

A webhook is also a better trigger than calling Volanea directly from a public form. Public browser JavaScript is visible to the person using the site. Any API key placed there can be copied and abused to send mail, inspect account behavior, or create an unexpected bill. The browser should submit data to your application; your application can then send the event to Pipedream.

Before you build the workflow

Prepare the sending identity and the decisions that should not live in an ad hoc workflow. At a minimum, decide the verified sender address, reply-to destination, event name, message content, and behavior for malformed events.

For a contact-confirmation workflow, the following choices are sensible:

From address: hello@updates.example.com, using a domain you control and have configured for email authentication.
Reply-to address: support@example.com, where a human or support system can receive replies.
Recipient: data.email from the incoming event, but only after validation.
Subject: a fixed, reviewed subject line rather than a value supplied by the form sender.
HTML body: built from trusted template text plus escaped event values.
Text body: included as a readable fallback for recipients whose clients do not render HTML.
Idempotency key: derived from the source event ID, so an event retry does not silently become a second email.

If your application collects addresses from a public form, validation should begin before the workflow fires. Confirm that the field exists, is a string, has a plausible address format, and represents an address that the person is allowed to receive mail at. For higher-risk forms, use confirmation or abuse controls before treating an address as a transactional recipient.

Volanea’s API reference and sender setup guidance are available in the email API documentation. Keep that reference open while implementing the request, especially if your account uses a different API version or supports additional message fields.

Create the Pipedream trigger and send a test event

Create a new Pipedream workflow and choose the HTTP / Webhook trigger. Pipedream provides an endpoint for that trigger. Copy the endpoint into the server-side webhook configuration of your form platform or application.

Do not put the endpoint in frontend code unless it is intentionally a public ingestion endpoint and you have designed for abuse. A public URL can be discovered and posted to. A safer default is for your own backend to receive the browser form submission, apply rate limits and anti-abuse checks, store the submission, and then forward the event to Pipedream.

Here is a minimal server-side example of the request that your application could make to the Pipedream endpoint:

await fetch(process.env.PIPEDREAM_CONTACT_WEBHOOK_URL, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-Webhook-Secret": process.env.PIPEDREAM_WEBHOOK_SECRET
  },
  body: JSON.stringify({
    event: "contact.created",
    event_id: contactEventId,
    occurred_at: new Date().toISOString(),
    data: {
      email: contact.email,
      first_name: contact.firstName,
      company: contact.company,
      message: contact.message,
      consent: contact.emailConsent === true
    }
  })
});

The X-Webhook-Secret is an application-level shared secret for your own endpoint contract. In the Pipedream code step, compare it with a Pipedream environment variable before sending email. This is separate from the Volanea API key. One protects workflow ingestion; the other authorizes email sending.

Send one test request with a non-production inbox. Inspect the event data shown in the Pipedream run. The important point is to inspect the actual received shape rather than assuming your source always sends a JSON object. A form provider may nest fields differently, send empty values as null, omit optional fields, or use a URL-encoded request rather than JSON.

Understand the event data you map

For an HTTP / Webhook trigger, downstream Pipedream steps can access the trigger event through steps.trigger.event. The event includes request-related information and the parsed request body when Pipedream can parse it. The exact properties depend on the request content type and source.

For the JSON example, the application data is expected at:

steps.trigger.event.body.data

That is why the mapping code below starts by reading steps.trigger.event.body. It then checks each field before it creates a Volanea payload. This is safer than doing something like body.data.email.toLowerCase() immediately: one missing data object would turn a routine bad request into an opaque runtime error.

Use a stable event ID from the originating system. Do not create a new random ID inside Pipedream for retry protection, because every retry would generate a different value. An order ID, form submission ID, CRM event ID, or a UUID assigned by your backend is suitable.

The practical field mapping for this workflow is:

Incoming Pipedream event field	Volanea email field	Purpose
`data.email`	`to`	Recipient address
fixed configured sender	`from`	Verified sending identity
fixed configured reply address	`reply_to`	Destination for replies
fixed subject text	`subject`	Confirmation subject
`data.first_name`, `data.company`	`html` and `text`	Personalized but escaped content
`event_id`	`Idempotency-Key` header	Retry-safe source identity

Avoid mapping form input into from, reply_to, arbitrary headers, or a raw HTML field. A person filling in a form should not be able to choose the sending identity or inject markup into a message. If you need to include their message, escape it and present it as text.

Add the Volanea API call in a Node.js code step

Add a Node.js code step after the HTTP / Webhook trigger. Pipedream code steps run on the server side, so they are an appropriate place to read secrets and call a mail API.

The following example validates the incoming webhook, safely maps the form event, and posts the result to Volanea. It uses the standard fetch API and an environment variable named VOLANEA_API_KEY.

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

    // Reject requests not sent by the backend that owns this workflow.
    const suppliedSecret = request.headers?.["x-webhook-secret"];
    if (!suppliedSecret || suppliedSecret !== process.env.PIPEDREAM_WEBHOOK_SECRET) {
      throw new Error("Unauthorized webhook request");
    }

    if (body.event !== "contact.created") {
      throw new Error(`Unexpected event type: ${body.event || "missing"}`);
    }

    if (!body.event_id || typeof body.event_id !== "string") {
      throw new Error("Missing string event_id");
    }

    const recipient = typeof data.email === "string" ? data.email.trim().toLowerCase() : "";
    if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(recipient)) {
      throw new Error("Missing or invalid recipient email");
    }

    if (data.consent !== true) {
      throw new Error("Contact has not provided email consent");
    }

    const escapeHtml = (value = "") => String(value)
      .replace(/&/g, "&amp;")
      .replace(/</g, "&lt;")
      .replace(/>/g, "&gt;")
      .replace(/"/g, "&quot;")
      .replace(/'/g, "&#039;");

    const firstName = typeof data.first_name === "string" && data.first_name.trim()
      ? data.first_name.trim()
      : "there";
    const company = typeof data.company === "string" ? data.company.trim() : "";

    const html = `
      <p>Hi ${escapeHtml(firstName)},</p>
      <p>Thanks for contacting Volanea${company ? ` from ${escapeHtml(company)}` : ""}.</p>
      <p>We received your request and will get back to you shortly.</p>
    `;

    const text = [
      `Hi ${firstName},`,
      "",
      `Thanks for contacting Volanea${company ? ` from ${company}` : ""}.`,
      "We received your request and will get back to you shortly."
    ].join("\n");

    const emailPayload = {
      from: "Volanea <hello@updates.example.com>",
      to: [recipient],
      reply_to: "support@example.com",
      subject: "We received your request",
      html,
      text
    };

    const response = await fetch("https://api.volanea.com/v1/emails", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": body.event_id
      },
      body: JSON.stringify(emailPayload)
    });

    const responseText = await response.text();
    let responseBody;
    try {
      responseBody = JSON.parse(responseText);
    } catch {
      responseBody = responseText;
    }

    if (!response.ok) {
      throw new Error(`Volanea send failed (${response.status}): ${responseText}`);
    }

    return {
      source_event_id: body.event_id,
      recipient,
      volanea_response: responseBody
    };
  }
});

Replace the example sender and reply-to addresses with addresses on your own configured domain. Do not copy updates.example.com literally. A sender identity that has not been configured for your Volanea account will not provide a production-ready result.

The request uses POST https://api.volanea.com/v1/emails, an Authorization: Bearer API key header, and JSON message fields. The Idempotency-Key is deliberately separate from the JSON payload because it identifies the delivery attempt across retries without changing the content of the message.

Store the Volanea key as a Pipedream secret

Create VOLANEA_API_KEY as an environment variable in Pipedream and read it only with process.env.VOLANEA_API_KEY inside the server-side code step. Create PIPEDREAM_WEBHOOK_SECRET the same way. Do not paste either value into the code editor, a workflow name, test data, or a step output.

Environment variables keep configuration out of source code and make key rotation practical. When you replace a key, update the environment variable and redeploy or rerun as appropriate for your workflow configuration. Restrict access to the Pipedream workspace so only people who need to maintain the integration can change its configuration.

The API key must never sit in client-visible configuration for several reasons:

Browser bundles, mobile apps, and publicly readable static configuration can be inspected by users.
A leaked sending key can be used to generate unwanted mail and damage sender reputation.
Revoking a leaked key can interrupt legitimate production sends until all deployed clients are updated.
Server-side storage lets you limit the key to one workflow environment and rotate it without shipping a new frontend release.

Also keep the Pipedream webhook URL and shared webhook secret distinct. Treat the URL as an address and the secret as proof that the request was made by your system. If the source platform supports webhook signatures, verify its native signature instead of inventing a shared-secret scheme.

Test the full delivery path

A green Pipedream workflow run only proves that the code did not throw an error. It does not by itself prove inbox placement, correct authentication, or that the recipient saw the expected content. Test each layer deliberately.

First, submit the test event and confirm that the HTTP / Webhook trigger received the expected body. Next, inspect the code step result and verify that recipient is the intended test inbox and that the response contains the expected Volanea send result. Finally, inspect the delivered email: sender, reply-to address, subject, HTML rendering, text alternative, and links.

Test these cases before enabling the workflow for real traffic:

A normal consented contact with first name and company.
A valid contact with no first name or company.
A request with no data.email field.
A request with consent: false.
A request with an incorrect webhook secret.
The same event_id submitted twice.
A Volanea API failure, using a safe test configuration rather than deliberately harming production delivery.

Testing repeated event IDs is especially important. Event-driven systems are generally at-least-once systems: an upstream service can retry after a network interruption even when the first request was accepted. Your workflow should be designed around that possibility, not around an assumption of exactly-once delivery.

When this breaks: retries, timeouts, and incomplete payloads

This integration has two network boundaries: the source application to Pipedream, and Pipedream to Volanea. A failure at either boundary can leave one system unsure whether the next system received the request.

Pipedream or source retries can create duplicate sends

A timeout does not always mean the remote service did nothing. For example, Pipedream may submit the Volanea request, Volanea may accept it, and the connection may fail before Pipedream receives the response. If the workflow run is retried, it can submit the same email again.

Use the stable source event_id as the Idempotency-Key, as the example does. Do not use the workflow run ID, current time, or a random generated value. Those values change on retries and therefore cannot identify a duplicate operation.

There is a second duplicate risk before Pipedream: your backend may retry a post to the webhook endpoint. Keep event IDs stable there too. If your source system has a delivery ID, persist it with the form submission or database record, rather than generating it at send time.

Webhook timeouts create ambiguity

Your source application should use a bounded timeout when posting to Pipedream and should record the event ID and response status. If it times out, do not assume the event was not received. Retry according to the source platform’s delivery policy, using the exact same event ID.

The Pipedream workflow should respond promptly from the trigger path where possible. Avoid making the inbound request wait on slow, unrelated work such as enrichment, many sequential API calls, or large file downloads. If the event requires substantial processing, make the receipt and the later work separately observable so you can determine whether the email was actually handed to Volanea.

Some source plans omit fields or limit event data

A form, CRM, or billing plan may not include every field you tested with. For example, an entry-level form plan may provide an email field but not a hidden submission ID; a CRM webhook may send a record ID but not the full record; a source may omit custom fields until they are explicitly selected in its webhook configuration.

That is why the code treats first_name and company as optional but requires event_id, email, and consent. If your source cannot provide a stable ID, have your backend generate and persist one before it posts to Pipedream. If it only sends a record ID, a Pipedream step can fetch the canonical record from your backend before sending—but that adds another failure boundary and should be justified.

Invalid recipients and sender configuration fail differently

A missing recipient field is a payload validation problem and should fail before the Volanea request. A sender domain that is not configured is a delivery configuration problem. Keep those categories separate in logs and alerts. The first is usually fixed by a source payload change; the second is fixed in sender-domain configuration, not by retrying the workflow.

Make the workflow safe for production volume

Once the basic flow works, treat it as production infrastructure rather than a one-off automation. Define which events are transactional and which are marketing. A contact confirmation requested by a person can be transactional; a later promotional sequence needs an appropriate consent basis and unsubscribe handling.

Keep templates under change control. A code step is convenient for a small confirmation message, but large templates with complex localization, conditional content, or legal copy become difficult to review when embedded in workflow code. In those cases, render a tested template in your application or use the message construction approach supported by your sending architecture.

Monitor outcomes at three levels:

Source health: webhook attempts, non-2xx responses, and retries from the originating application.
Workflow health: Pipedream runs, validation failures, execution duration, and exceptions.
Email health: Volanea API responses, delivery events where available, bounces, complaints, and recipient engagement appropriate to the message type.

Use an alert that identifies the event ID, not only an error string. An event ID lets an operator find the originating form submission, the corresponding Pipedream run, and the email API request without exposing the recipient address in every alert channel.

Alternatives when an HTTP webhook is not your source

The direct Pipedream route is appropriate when your source can post an HTTP request or when a Pipedream trigger for that source already produces event data. You do not need a native Volanea marketplace app to make the final outbound API call; the Node.js code step is the integration point.

If a source has no webhook capability, several patterns remain viable. A scheduled Pipedream workflow can poll a database or SaaS API for new records, then use the same mapping and Volanea request. A source that can call Zapier or Make can send its event there first, but adding middleware is only useful if it solves a real source-connectivity problem. It adds latency, credentials, monitoring, and another retry policy.

For application-owned events, sending from your own backend may be simpler than introducing a workflow platform. Pipedream is most valuable when non-application systems need to initiate automation or when you want to compose several APIs without deploying a separate integration service.

A practical deployment checklist

Before switching from a test inbox to production recipients, review this list:

The sender domain and from address are configured for your Volanea account.
VOLANEA_API_KEY exists only in Pipedream server-side environment configuration.
The public client never receives the Volanea key or a privileged backend webhook secret.
The inbound webhook request is authenticated or signature-verified.
The source sends a stable, persisted event_id.
The Volanea request uses that ID as its idempotency key.
Required fields are validated before the API call.
Optional fields have safe fallbacks.
Dynamic text is escaped before inclusion in HTML.
A failure alert includes an event ID and avoids leaking full contact data.
The same event was tested twice to confirm duplicate handling.
The workflow’s consent rules match the purpose of the message.

The result is a small but robust integration: Pipedream coordinates the event, Volanea sends the email, and your backend remains the authority on customer data and authorization.

FAQ

Does Volanea have a native Pipedream app?

No native Pipedream app or marketplace installation is required for this approach. Use Pipedream’s HTTP / Webhook trigger and a Node.js code step to call the Volanea REST API directly.

Can I send email from Pipedream after a form submission?

Yes. Have your form backend post a JSON event to a Pipedream HTTP / Webhook trigger, then map the event body to a Volanea email request in the next workflow step. Keep the Volanea key on the server side.

Where should I store the Volanea API key in Pipedream?

Store it as a Pipedream environment variable and access it in a server-side code step through process.env.VOLANEA_API_KEY. Never include it in frontend JavaScript, a public form, or checked-in workflow code.

How do I prevent duplicate emails after a retry?

Assign every source event a stable ID and send that value as the Idempotency-Key on the Volanea API request. Reuse the same event ID whenever the source or workflow retries.

What happens if the webhook payload has no email address?

Validate the payload before calling Volanea and fail the workflow with a clear error. Do not send to a fallback address in production unless that behavior is intentional and appropriately secured.

How to Send Email from Pipedream with Volanea