Send email from Unbounce without a native plugin

To send email from Unbounce with Volanea, connect an Unbounce form submission to a server-side webhook endpoint, then have that endpoint call the Volanea email API. This is an integration pattern rather than a native Unbounce app: Unbounce captures the conversion, your endpoint validates and maps the data, and Volanea delivers the message.

That distinction matters. A landing-page form runs in a visitor’s browser, while an email API key must remain private. The safe architecture puts Volanea behind a server, serverless function, or automation platform—not in Unbounce page JavaScript, custom scripts, hidden form fields, or a thank-you page.

The result can support common post-conversion messages: a confirmation email, a downloadable resource, an event registration receipt, a sales handoff notice, or a double-opt-in prompt. It also gives developers control over validation, consent, idempotency, deliverability, and observability.

The integration architecture

Unbounce supplies outbound webhooks for form submissions. The relevant event is a visitor submitting an Unbounce landing-page form: in Unbounce terms, that submission creates a conversion/lead. Configure the webhook to call an HTTPS endpoint that you control.

The full path looks like this:

A visitor fills in and submits a form on an Unbounce landing page.
Unbounce posts the submission payload to your webhook URL.
Your endpoint checks the request, reads the submitted fields, and decides whether an email should be sent.
Your endpoint sends a REST request to Volanea with the recipient, sender, subject, and content.
Volanea accepts the request and returns a response that your application records alongside the Unbounce lead metadata.

Do not treat this as a browser-to-email-provider connection. The browser’s job ends when it submits the form to Unbounce. The webhook receiver is the trust boundary where you can reject invalid input, avoid unintended recipients, and keep credentials out of public page assets.

Why middleware is worth having

A direct client-side call would expose your Volanea API key to anyone who views the page source, browser network requests, or a bundled script. Once exposed, that key could be used to send mail, potentially creating cost, abuse, and sender-reputation problems.

Middleware also solves practical translation problems. Form labels can change, individual pages can have different fields, and an email template may need data that is not appropriate to collect in the landing-page form. A small endpoint can normalize these differences into one dependable outgoing message shape.

It is usually simplest to use a serverless function—such as a function in the same application that owns the landing page—or a minimal Express/Fastify service. If maintaining code is not appropriate, Zapier or Make can sit between Unbounce and Volanea, but credentials still belong in the automation connection’s protected credential storage, not in front-end code.

What Unbounce sends on a form submission

The Unbounce webhook is driven by the form submission, not by a page view or a visitor merely opening a thank-you page. Test it with a real submission after configuring the webhook, because the exact submitted-field keys reflect the fields on that landing page.

Unbounce separates the lead’s submitted values from page context. A representative form-submission payload has a data object for form values and a meta object for landing-page information:

{
  "data": {
    "first_name": "Avery",
    "email": "avery@example.com",
    "company": "Northstar Labs",
    "marketing_consent": "yes"
  },
  "meta": {
    "page_id": 123456,
    "page_name": "Autumn webinar registration",
    "page_url": "https://example.com/webinar",
    "variant": "a"
  }
}

The important operational point is that data.email is only an example based on a field named email. If the Unbounce form’s field is named work_email, Email Address, or another key, your receiver must use that actual key. Treat field labels and internal keys as a contract: document them, test them, and update the mapping whenever the landing-page form changes.

Build a field inventory before writing the sender

For each page or form variation, write down:

the field that contains the recipient address;
the field that contains a first name, if the message uses one;
the consent field and the values that represent permission;
optional fields used only for internal notifications, such as company or job title;
the page metadata you want to retain for audit and analytics;
the message type that the form is allowed to trigger.

A webinar confirmation and a product-download email may both use email, but they should not necessarily use the same template, consent rule, or reply-to address. Use page ID or a deliberately supplied hidden campaign field to choose the approved message type. Do not accept arbitrary subjects, HTML, or sender addresses from the form payload.

Test the actual request, not a guessed sample

Webhook payloads are configuration-dependent. A field can be omitted because it is not present on a particular landing page, because a visitor did not fill an optional field, or because an integration only exposes the fields supported by that configuration or plan. Capture a sanitized test request in a development environment and compare it to your receiver’s mapping.

Never log raw production payloads indefinitely. They can contain personal data. Log a request ID, page ID, the set of field names received, validation outcomes, and a hashed email address where possible. This is usually enough to troubleshoot without creating an unnecessary second copy of lead data.

Configure the Unbounce webhook safely

Create a public HTTPS endpoint, for example https://hooks.example.com/unbounce/lead. It must accept Unbounce’s POST request and return promptly. Then configure the Unbounce webhook integration for the relevant landing page or form-submission flow and use that endpoint as the destination URL.

The exact configuration options available can depend on the Unbounce product and account plan, so use the current Unbounce webhook documentation and your account’s integration settings rather than assuming every account exposes identical controls. Before enabling a live campaign, submit the published page yourself and verify that the receiver sees the expected data keys.

Use a receiver URL that contains no API secret

It is tempting to put a secret in a query string, such as https://hooks.example.com/unbounce?token=.... Avoid this unless there is no stronger option. Query strings are commonly retained in proxy, access, and analytics logs.

A better approach is to give the webhook an opaque, high-entropy path segment, such as /unbounce/lead/9e0f..., and validate it server-side. If your Unbounce webhook configuration supports a custom authentication mechanism or secret header, validate that too. Independently of the method, rate-limit the route and reject requests that do not match your expected structure.

If a webhook delivery mechanism does not provide a signed request, an opaque endpoint is not equivalent to cryptographic verification. Design accordingly: keep the endpoint narrow, validate every field, do not let incoming data choose outgoing sender settings, and rotate the endpoint path if it leaks.

Return a fast success response

A webhook sender expects a response within its timeout window. Do not make the endpoint do slow database work, call several APIs sequentially, render expensive content, and then finally send a response. A timeout can cause the sender to retry even when your application eventually processed the request.

For low-volume confirmations, validate, create an idempotency record, send through Volanea, persist the result, and return a 2xx response. For more resilient systems, validate and persist a job first, return success after that durable write, and have a worker send the email. The second approach is safer when the email API has a temporary outage.

Map the Unbounce lead to a Volanea email

The sender should use fixed, server-owned message settings. The submitted email becomes the to value after validation; the approved domain address becomes from; and page metadata is used for controlled template selection or internal tracking.

The example below is a Node.js Express receiver. It expects an Unbounce payload with data and meta, maps data.email and data.first_name, and sends a confirmation through the Volanea REST API. Store the API key in the runtime environment as VOLANEA_API_KEY; do not put it in Unbounce scripts or form fields.

import express from "express";
import crypto from "node:crypto";

const app = express();
app.use(express.json({ limit: "100kb" }));

const allowedPages = new Map([
  [123456, { template: "webinar-confirmation", subject: "You’re registered for the webinar" }]
]);

function escapeHtml(value = "") {
  return String(value)
    .replaceAll("&", "&amp;")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#039;");
}

app.post("/unbounce/lead", async (req, res) => {
  const payload = req.body;
  const fields = payload?.data ?? {};
  const meta = payload?.meta ?? {};

  // Unbounce field mapping: data.email and data.first_name.
  const to = String(fields.email ?? "").trim().toLowerCase();
  const firstName = String(fields.first_name ?? "there").trim();
  const pageId = Number(meta.page_id);
  const campaign = allowedPages.get(pageId);

  if (!campaign) {
    return res.status(202).json({ ignored: "unapproved landing page" });
  }
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(to)) {
    return res.status(400).json({ error: "missing or invalid email field" });
  }

  // Use a durable database/queue in production, not an in-memory Set.
  const idempotencyKey = crypto
    .createHash("sha256")
    .update(`${pageId}:${to}:${campaign.template}`)
    .digest("hex");

  const volaneaResponse = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify({
      from: "Webinar team <events@updates.example.com>",
      to: [to],
      subject: campaign.subject,
      html: `<p>Hi ${escapeHtml(firstName)},</p><p>Thanks for registering. We’ll send your joining details soon.</p>`,
      text: `Hi ${firstName},\n\nThanks for registering. We’ll send your joining details soon.`,
      tags: [
        { name: "source", value: "unbounce" },
        { name: "page_id", value: String(pageId) },
        { name: "template", value: campaign.template }
      ]
    })
  });

  if (!volaneaResponse.ok) {
    const detail = await volaneaResponse.text();
    console.error("Volanea send failed", volaneaResponse.status, detail);
    return res.status(502).json({ error: "email provider rejected the request" });
  }

  const result = await volaneaResponse.json();
  return res.status(200).json({ accepted: true, message: result });
});

app.listen(3000);

The API request uses a bearer token, a JSON body, and an idempotency key. Confirm the current request schema, supported tagging format, and idempotency behavior against the email API reference and setup guides before deploying, especially if you use templates, attachments, reply-to addresses, or provider-specific metadata.

Keep content and routing under application control

The form should not provide the outgoing from, subject, or HTML body. A malicious visitor can modify browser-submitted values, including hidden fields. Use a server-side allowlist keyed by a known page ID, campaign identifier, or endpoint path.

For example, one page ID can map to a webinar registration confirmation while another maps to a gated-report delivery. This prevents a typo in an Unbounce hidden field from turning into an unexpected email type and prevents user-controlled values from becoming message-routing instructions.

Protect the Volanea API key

Put VOLANEA_API_KEY in your deployment platform’s encrypted environment-variable or secret manager facility. The process running the receiver reads it at runtime; Unbounce never needs to know it.

This is a non-negotiable separation of responsibilities. Unbounce needs only the webhook destination. Your server needs the Volanea credential. The page visitor should receive neither.

Places the key must not live

Do not store the key in:

Unbounce custom JavaScript or page HTML;
a hidden input, URL parameter, or thank-you-page redirect;
a public Git repository or a front-end .env file bundled into JavaScript;
a browser-accessible local-storage value;
a Zapier or Make field mapping that is visible in a message body or task history.

If a key is exposed, rotate it immediately, review API activity, and inspect the page or repository history that caused the exposure. Removing a key from current code does not undo a leaked deployment artifact, cached JavaScript bundle, or screenshot.

Sender identity is separate from API authentication

A valid API key authorizes your application; it does not automatically establish that every sender address is suitable for production mail. Use a sender domain you control and complete the domain-authentication steps required by your email provider. Keep the from domain consistent with the landing-page brand when possible.

This reduces user confusion and supports healthier deliverability. A visitor who signs up on example.com should not receive a confirmation from an unrelated-looking address. Include a usable reply-to route when replies are expected, and ensure any unsubscribe or consent obligations are handled according to the message type and applicable rules.

Validation, consent, and deliverability

A form submission proves that the form was submitted; it does not prove that an address is deliverable, owned by the visitor, or authorized for recurring marketing. Decide what kind of message you are sending before you automate it.

A requested download or webinar registration confirmation is usually an operational response to the visitor’s action. A promotional nurture series is a separate marketing decision and should depend on explicit, recorded consent where required. Do not silently interpret a generic contact form as blanket permission for ongoing campaigns.

Validate addresses before sending

Basic syntax validation protects your API from obviously malformed values, but it cannot establish mailbox existence. For higher-value flows, add layered checks:

Require the email form field in Unbounce.
Normalize whitespace and casing for comparison and deduplication.
Apply basic syntax validation in the receiver.
Optionally check the address with an email address verification tool before adding it to a marketing workflow.
Use confirmation links or double opt-in where your policy requires stronger proof of ownership and consent.

Avoid rejecting valid addresses merely because they use a plus alias, an internationalized domain, or an uncommon top-level domain. Email validation is a risk-management process, not a reason to build an overly restrictive regex.

Separate transactional and campaign logic

A landing-page conversion can legitimately initiate both a direct confirmation and a later campaign workflow, but they should have different controls. The immediate confirmation should be deterministic: one approved event, one expected message, clear copy, and a traceable send record.

A campaign enrollment needs audience rules, consent state, suppression handling, frequency decisions, and a way to stop messages. Keeping these paths separate makes it easier to audit why a recipient received a particular email and to prevent a retrying webhook from accidentally enrolling someone repeatedly.

When this breaks: failures in the Unbounce-to-email hop

Most problems are not failures of the email API alone. They happen at the boundary between Unbounce’s webhook delivery, your endpoint, your data store, and Volanea’s send request. Design for each failure mode deliberately.

Retries can create duplicate sends

A webhook system may retry after a network error, timeout, or non-2xx response. From Unbounce’s perspective, a retry is reasonable. From the recipient’s perspective, two identical registration emails are confusing.

Use idempotency at your receiver, not just wishful thinking. Build a stable key from a true submission identifier if the payload provides one. If it does not, use a carefully chosen composite—such as page ID, normalized email, message type, and a submission timestamp or short time bucket—and store it in a durable database with a uniqueness constraint.

The sample uses a hash to illustrate the mechanism, but production systems must persist the key before or alongside sending. An in-memory set disappears on a server restart and does not coordinate across multiple serverless instances. If Volanea supports idempotency keys, pass the same stored key in the API request as an additional layer of protection.

Webhook timeouts create ambiguous outcomes

Suppose your receiver calls Volanea, Volanea accepts the message, but the connection drops before your receiver returns a 200 response to Unbounce. Unbounce may retry. If you did not store the idempotency record before the send, the retry can send a duplicate.

A robust workflow is: validate the payload, create a durable pending job keyed by the submission, return a success response once the job is stored, and let a worker send the message. Update the job to sent with the Volanea response identifier. If the worker crashes after the provider call, reconcile pending jobs using the idempotency key and provider response where possible rather than blindly resending.

Fields may be missing or renamed

Some submissions will lack optional fields. Different landing pages may use different names for the same concept. Account configuration, product availability, or the selected integration path can also affect which metadata is available.

Make required fields explicit. If email is required for a confirmation, return a clear validation result and alert the site owner to inspect that page’s form configuration. For optional personalisation, use a safe fallback such as “there” rather than failing the entire transactional flow because first_name is absent.

Do not rely on a page URL string as the only routing key; URLs can change. Prefer stable IDs when they are included, and maintain an allowlist that is reviewed whenever a new Unbounce page goes live.

Provider failures need a retry policy too

A 4xx response from Volanea often indicates a request that should be fixed rather than retried: an invalid recipient, unverified sender, malformed body, or missing authorization. A 5xx response or network failure may be temporary.

Use bounded exponential backoff for transient failures, retain the failed job and response detail, and alert when error rates rise. Never retry indefinitely. Repeated sends to invalid or suppressed recipients can harm deliverability and obscure the underlying integration problem.

Using Zapier or Make instead of custom code

If you do not have a safe place to deploy a webhook receiver, an automation platform can provide the middleware layer. Both Zapier and Make offer Unbounce integrations/workflows for form submissions, though the exact triggers, actions, and field lists available to an account should be verified in the platform’s current UI.

The conceptual configuration remains the same: select the Unbounce form-submission trigger, map the email field into an authenticated Volanea HTTP request or supported connector action, and restrict the workflow to approved pages. Use the automation platform’s secret/connection management for the Volanea credential, not a value copied into a public field.

Trade-offs of no-code middleware

Automation tools are quick to configure and useful for lower-volume flows, but they are not a replacement for careful integration design. Confirm whether the platform retries failed steps, how long it retains task data, whether it can generate or forward idempotency keys, and how it reports a partial failure after the email provider accepts a send.

Custom middleware is usually better when you need strict deduplication, complex consent rules, custom templates, regional data controls, or a large number of landing pages. An automation platform may be sufficient for a single webinar page if you add filters, error alerts, and a tested duplicate strategy.

Monitor the flow after launch

A successful test is only the first signal. Monitor the complete funnel: Unbounce form submissions, webhook arrivals, validations rejected, jobs created, Volanea acceptance responses, and subsequent delivery or bounce events where available.

Use correlated identifiers. Store the landing-page ID, a non-sensitive submission correlation value, your idempotency key, the message type, and Volanea’s returned message identifier. This lets support answer practical questions such as “Did Maya receive the confirmation?” without rummaging through raw webhook payloads.

Metrics that reveal trouble early

Watch these ratios over time:

received webhooks versus Unbounce form submissions;
accepted jobs versus validation failures;
accepted email sends versus provider rejections;
duplicate suppressions versus total submissions;
delivery, bounce, complaint, and unsubscribe signals for the appropriate message category.

A sudden rise in missing-email validation failures often indicates a landing-page field rename. A rise in duplicate suppressions can indicate webhook retries or a flawed idempotency key. A provider rejection spike may point to a rotated credential or sender-domain issue. These are different incidents and should not be diagnosed as a generic “Unbounce email problem.”

A practical launch checklist

Before enabling the integration for real traffic, complete this checklist:

Publish and submit the exact Unbounce landing page, then capture a sanitized webhook payload.
Confirm the required field keys and page metadata used in routing.
Put the Volanea API key in server-side secret storage and verify it is absent from page source and repository history.
Configure a verified sender identity and use a fixed, approved from address.
Add input validation, an allowlist of permitted page IDs, and safe HTML escaping for any submitted values used in content.
Implement durable idempotency before enabling retries or high-volume traffic.
Test normal submission, missing email, malformed email, provider error, slow response, and repeated webhook delivery.
Add logs, alerts, and a documented owner for failed jobs.

With those controls in place, sending mail from an Unbounce conversion becomes a maintainable system rather than a fragile point-to-point automation. The landing page remains focused on conversion, while your integration service owns the security and delivery decisions that belong on the server.

FAQ

Can I send email directly from Unbounce custom JavaScript?

No. Do not call Volanea from Unbounce page JavaScript because the browser would expose the API key. Use an Unbounce form-submission webhook to a server-side endpoint, or use a credential-managed automation platform as middleware.

What triggers the Volanea email?

The trigger is an Unbounce landing-page form submission—the conversion/lead created when a visitor submits the form. Your webhook receiver decides whether that specific submission is eligible to generate an email.

How do I stop duplicate confirmation emails?

Assume Unbounce webhook deliveries can be retried after errors or timeouts. Store a durable idempotency key per eligible submission before sending, enforce uniqueness in your database, and forward the same key to the email API when supported.

What if my form uses `work_email` instead of `email`?

Change the field mapping in the receiver from data.email to data.work_email, then submit a live test form. Do not assume form-field names are consistent across Unbounce pages; validate each page’s actual payload.

Can the same form start a campaign and send a confirmation?

Yes, but keep the immediate confirmation and campaign enrollment as separate workflows. Apply explicit consent, suppression, frequency, and unsubscribe controls to campaign enrollment rather than treating every form submission as permission for ongoing promotional mail.

How to Send Email From Unbounce With Volanea