How to Send Email From Forminator With Volanea

Send email from Forminator without relying on a native marketplace app: use Forminator’s Webhook integration to post each form submission to a small server-side bridge, then have that bridge call Volanea’s REST API. This keeps the email credential private, gives you full control over field mapping, and makes duplicate-prevention possible.

There is no native Volanea app, listing, or marketplace plugin for Forminator. That is not a limitation you should paper over by putting an email API key into a form field, JavaScript snippet, or public webhook URL. Instead, treat Forminator as the submission trigger and Volanea as the sending provider, with a trusted server endpoint between them.

This guide shows the production-safe path for a common use case: a visitor submits a Forminator contact, request, registration, or lead form; Forminator posts its submitted field values to your endpoint; your endpoint validates and maps those values; Volanea sends an internal notification, a customer confirmation, or both.

What starts the email send in Forminator?

The trigger is a form submission. When a visitor completes and submits a Forminator form successfully, Forminator creates a submission entry and its Webhook integration can send the submitted data to an external URL.

That distinction matters. The trigger is not merely a browser button click, a page view, or a field change. It is the server-side completion of the Forminator form submission flow. Your integration should therefore send an email only after Forminator has accepted the submitted values, not while the visitor is still filling out the form.

For this guide, assume the form has these Forminator field IDs:

• name-1 for the visitor’s full name
• email-1 for the visitor’s email address
• message-1 for the request or message
• service-1 for a selected service or product
• referer_url for the page associated with the submission

Your field IDs may differ. Forminator commonly assigns IDs such as email-1, name-1, and textarea-1, but you should use the exact IDs from your own form rather than copying these names blindly.

Why the integration needs a server-side bridge

Forminator’s Webhook integration is useful because it can send submission data to an endpoint you control. It is not, however, a safe place to configure an email provider’s long-lived secret key.

Volanea’s POST /v1/send endpoint needs a secret API key in the Authorization: Bearer ... request header. A form webhook is designed to deliver form data outward; it is not the right boundary for exposing a credential that can send email from your domain. A URL query parameter such as ?api_key=... is also not an acceptable substitute: URLs are routinely stored in logs, browser history, hosting dashboards, proxy logs, and analytics systems.

The right flow is:

1. A visitor submits the Forminator form.
2. Forminator sends the form fields to a dedicated HTTPS endpoint you control.
3. The endpoint verifies that the request is acceptable.
4. The endpoint turns the submitted fields into a Volanea email payload.
5. The endpoint calls https://api.volanea.com/v1/send with the Volanea secret key stored only on the server.
6. Volanea accepts the message for delivery and records its send outcome.

This architecture also gives you a place to reject malformed data, escape user-provided text before inserting it into HTML, add an idempotency key, record failures, and avoid making a visitor wait for an upstream email API response.

What Forminator actually sends to the webhook

Forminator’s Webhook integration posts a flat collection of submitted form values. The concrete keys reflect the IDs of the fields in the form. A contact-form submission can therefore arrive at your endpoint in a shape like this:

{
  "name-1": "Ada Lovelace",
  "email-1": "ada@example.com",
  "service-1": "Product demo",
  "message-1": "Please contact me about an enterprise account.",
  "referer_url": "https://example.com/request-a-demo/",
  "_wp_http_referer": "/request-a-demo/"
}

Do not treat that example as a universal schema. Forminator sends the fields your form has collected, so checkbox groups, address fields, file uploads, calculated values, hidden fields, and conditionally displayed fields can have different shapes or be absent. The field identifier—not its visual label—is what your bridge should map.

A good first test is to point Forminator at a disposable request inspector or a staging endpoint that logs the raw request body. Submit the real form with representative values, including optional fields, conditional branches, and attachments if you use them. Then freeze the mapping based on the observed payload instead of guessing from the form labels.

Map only the values the email needs

A lead-notification email rarely needs every form field. Passing every value through increases the chance that private data, payment-related information, or an unexpected hidden field appears in an email.

For a request form, a minimal mapping is usually enough:

Do not use a visitor-provided email address as the from value. The sender must be an address at a domain you have verified in Volanea. Set the visitor address as replyTo for an internal notification, or as to when sending a confirmation to the visitor.

Configure the Forminator webhook

In Forminator, enable the Webhook integration, then add it to the specific form through that form’s Integrations tab. Use the HTTPS address of your bridge endpoint as the webhook URL.

For example, if your application serves the endpoint shown below, the webhook URL might be:

https://forms.example.com/forminator/lead

Keep the endpoint deliberately narrow. It should be dedicated to this form flow rather than being a generic “send any email” endpoint. A narrow endpoint lets you enforce a known form schema, a known sender address, a known recipient list, and a known email purpose.

Before activating the integration, decide which messages should be sent:

• Internal notification only: Send a message to sales or support with the visitor’s email in replyTo.
• Visitor confirmation only: Send a confirmation to the submitted email address after validation.
• Both: Make two separate, purpose-specific sends with separate idempotency keys.

Avoid using an immediate confirmation email as a substitute for marketing consent. A form confirmation is transactional when it acknowledges the visitor’s request. A promotional sequence needs a clear consent model and should be handled separately.

Store the Volanea API key safely

The Volanea API key lives in the server environment used by your bridge—not in Forminator’s public form configuration, not in page source, and not in browser JavaScript.

For a Node-based bridge, define these environment variables in your hosting provider’s secret manager, deployment configuration, or protected .env file outside version control:

VOLANEA_API_KEY=sk_live_replace_with_your_secret
VOLANEA_FROM=Website Team <hello@your-verified-domain.com>
LEAD_NOTIFICATION_TO=sales@yourcompany.com
FORMINATOR_WEBHOOK_SECRET=replace-with-a-long-random-value

VOLANEA_FROM must use a sender address on a domain verified in Volanea. The FORMINATOR_WEBHOOK_SECRET is a separate secret used only to protect your bridge. Since a basic Forminator webhook flow may not give you a suitable custom authorization-header control for this API use case, include this value in the configured webhook URL as a secret query value, such as:

https://forms.example.com/forminator/lead?token=replace-with-a-long-random-value

That token is not a replacement for the Volanea API key. It merely stops casual unsolicited requests from reaching your bridge. It should still be long, random, rotated if exposed, and never committed to source control. The Volanea key remains server-side and is never sent to Forminator or the browser.

For WordPress-only deployments, you can implement the same principle with a small must-use plugin and place the key in wp-config.php or an environment variable consumed by PHP. The security rule stays the same: PHP can read the secret; public pages, form configuration, and JavaScript cannot.

Working webhook bridge: Forminator payload to Volanea email

The following Express handler accepts the flat Forminator payload described earlier, verifies a shared endpoint token, maps the fields, safely escapes user content for HTML, and sends an internal lead notification through Volanea.

It also derives a stable idempotency key from the normalized submission data. In production, a true Forminator submission ID is even better when your flow includes one, because it gives one durable identity to one logical form submission. The key point is that a retry of the same logical event must reuse the same Idempotency-Key.

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

const app = express();

// Forminator webhook deliveries may be parsed as form fields. Accept both
// urlencoded and JSON bodies so the bridge remains explicit about its input.
app.use(express.urlencoded({ extended: false }));
app.use(express.json());

const required = [
  "VOLANEA_API_KEY",
  "VOLANEA_FROM",
  "LEAD_NOTIFICATION_TO",
  "FORMINATOR_WEBHOOK_SECRET"
];

for (const name of required) {
  if (!process.env[name]) throw new Error(`Missing environment variable: ${name}`);
}

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

function oneLine(value = "") {
  return String(value).replace(/[\r\n]+/g, " ").trim();
}

app.post("/forminator/lead", async (req, res) => {
  if (req.query.token !== process.env.FORMINATOR_WEBHOOK_SECRET) {
    return res.status(401).json({ error: "Unauthorized" });
  }

  // Exact field mapping: replace these IDs if your Forminator form uses others.
  const name = oneLine(req.body["name-1"]);
  const email = oneLine(req.body["email-1"]).toLowerCase();
  const service = oneLine(req.body["service-1"] || "General inquiry");
  const message = String(req.body["message-1"] || "").trim();
  const refererUrl = oneLine(req.body.referer_url || "");

  if (!name || !email || !message) {
    return res.status(422).json({
      error: "Required Forminator fields are missing"
    });
  }

  // This is a basic format check, not a deliverability check.
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    return res.status(422).json({ error: "Invalid email address" });
  }

  // A deterministic key prevents a duplicate email if this exact form event
  // is replayed. Prefer a true submission ID when your Forminator setup sends one.
  const idempotencyKey = crypto
    .createHash("sha256")
    .update(JSON.stringify({ name, email, service, message, refererUrl }))
    .digest("hex");

  const text = [
    "New Forminator lead",
    `Name: ${name}`,
    `Email: ${email}`,
    `Service: ${service}`,
    `Page: ${refererUrl || "Not provided"}`,
    "",
    "Message:",
    message
  ].join("\n");

  const html = `
    <h1>New Forminator lead</h1>
    <p><strong>Name:</strong> ${escapeHtml(name)}</p>
    <p><strong>Email:</strong> ${escapeHtml(email)}</p>
    <p><strong>Service:</strong> ${escapeHtml(service)}</p>
    <p><strong>Page:</strong> ${escapeHtml(refererUrl || "Not provided")}</p>
    <p><strong>Message:</strong></p>
    <p>${escapeHtml(message).replaceAll("\n", "<br>")}</p>
  `;

  const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": `forminator-lead-${idempotencyKey}`
    },
    body: JSON.stringify({
      from: process.env.VOLANEA_FROM,
      to: process.env.LEAD_NOTIFICATION_TO,
      replyTo: email,
      subject: `New ${service} request from ${name}`,
      text,
      html
    })
  });

  const result = await volaneaResponse.json().catch(() => ({}));

  if (!volaneaResponse.ok) {
    console.error("Volanea send failed", {
      status: volaneaResponse.status,
      result
    });
    return res.status(502).json({ error: "Email provider rejected the send" });
  }

  // Acknowledge only after Volanea accepts the request.
  return res.status(200).json({ accepted: true, result });
});

app.listen(process.env.PORT || 3000, () => {
  console.log("Forminator bridge listening");
});

The Volanea call is the important boundary in that example:

POST https://api.volanea.com/v1/send
Authorization: Bearer sk_live_...
Content-Type: application/json
Idempotency-Key: forminator-lead-...

The JSON body supplies from, to, replyTo, subject, text, and html. Use both text and HTML so the message remains readable in text-only clients and security-conscious mail environments.

For endpoint options, templates, response handling, and delivery events, refer to the email API reference and setup guides.

Send a customer confirmation without turning it into a marketing email

A second Volanea call can confirm that a visitor’s request was received. Keep it separate from the internal notification because the recipient, copy, and failure policy are different.

For example, the customer confirmation can use:

const confirmationPayload = {
  from: process.env.VOLANEA_FROM,
  to: email,
  subject: "We received your request",
  text: `Hi ${name},\n\nThanks for contacting us about ${service}. Our team will reply soon.`,
  html: `<p>Hi ${escapeHtml(name)},</p><p>Thanks for contacting us about ${escapeHtml(service)}. Our team will reply soon.</p>`
};

Use a related but distinct idempotency key, such as forminator-confirmation-<submission-id>. If you use one identical key for two different messages, the API will correctly treat the second request as a retry of the first rather than a new send.

Keep the confirmation focused on the event the visitor just initiated. Do not add a newsletter subscription, product promotion, or unrelated sales copy unless the form separately collected and recorded the appropriate consent.

Use templates when messages become harder to maintain

Inline HTML is convenient for a one-off lead alert, but it becomes cumbersome when you need a brand-consistent layout, localization, several notification types, or non-developer editing. In that case, store the reusable content in a Volanea template and have the bridge send a template ID with variables.

The bridge still owns the trust boundary. Forminator sends raw submission data to your endpoint; your code validates it and maps only approved variables into the template. Do not let the form submit an arbitrary template ID or arbitrary recipient list, because that turns a request form into an email-sending surface.

A practical progression is:

1. Start with one internal notification and explicit inline text and html.
2. Add a visitor confirmation after the first flow is stable.
3. Move repeatable copy into an approved template.
4. Add event logging and delivery-webhook handling for important workflows.

Prevent duplicates with a stable idempotency strategy

Webhook systems are not exactly-once systems. A request can reach Volanea successfully while the bridge loses the response because of a network interruption. A visitor can double-submit a form. An administrator can retest an integration. A hosting retry or a webhook replay can cause the bridge to see the same logical submission again.

Without idempotency, each repeated request can produce another email. This is especially awkward for customer confirmations and can create noisy internal lead alerts.

Prefer a submission-specific identifier

The best idempotency key is based on a durable Forminator submission or entry identifier plus the purpose of the email:

forminator-entry-12345-internal-notification
forminator-entry-12345-customer-confirmation

If your webhook payload does not include a reliable submission ID, add a server-side integration that has access to the saved Forminator entry, or persist a bridge-side event record before sending. Hashing content, as the example does, is a reasonable fallback but is less precise: two legitimate visitors can submit identical words, while a single submission can contain values that are normalized differently.

Keep the logical event and retry key aligned

A retry must use the same key. A genuinely new submission must use a different key. Do not generate a random UUID every time the bridge receives a request if your goal is duplicate prevention; that tells Volanea that every retry is a new send.

If you put the work into a queue, store the key with the job before calling Volanea. If the job runs again, reuse the stored value. This principle is more durable than trying to infer whether an email “probably already went out.”

When this breaks: Forminator webhook failure modes

This integration has two hops: Forminator to your bridge, then your bridge to Volanea. Diagnose the failing hop before changing code or credentials.

Forminator retries or repeated submissions cause duplicate sends

A repeated webhook delivery, a resubmission, or a manual test can reach your bridge more than once. Forminator and network infrastructure should be assumed to provide at-least-once behavior from the perspective of an email workflow; you should not depend on a single delivery attempt as proof that the event is unique.

Fix: use a stable Idempotency-Key tied to the submission ID and message purpose. Record the Forminator entry ID, your idempotency key, Volanea’s result, and the time. When investigating duplicates, compare those records before blaming delivery.

The Forminator webhook times out

A Forminator form submission should not wait on slow database work, a template render, several external APIs, or a long email-provider response. A slow bridge makes the form experience feel broken and increases the chance of a retry or an ambiguous result.

Fix: validate and persist the inbound event quickly, return a successful response once the event is durably accepted, and send asynchronously through a queue when the email is business-critical or traffic is substantial. For a small-volume implementation, keep the bridge focused on one Volanea call and set a clear outbound request timeout. Log the status code and response body, but never log the secret key.

Fields are missing on some submissions

Do not assume every configured Forminator field exists on every request. Optional fields can be blank; conditionally displayed fields may not be submitted; field IDs can change after editing or importing a form; file-upload values can behave differently from plain text; and hidden or calculated values deserve explicit testing.

Fix: make required fields required in Forminator and validate them again in the bridge. Treat optional values as optional. Use a staging checklist that submits every conditional branch. If a field is essential to the email, reject the event with a clear logged reason rather than sending an incomplete message with a misleading subject or recipient.

The Volanea request returns 401 or 403

A 401 usually points to an absent, malformed, revoked, or incorrect API key. A 403 can indicate that the sending identity is not authorized, including an unverified sending domain.

Fix: confirm that the bridge’s environment has the expected secret, restart or redeploy after changing environment variables, and verify that VOLANEA_FROM uses a verified domain. Do not “debug” by pasting the secret into Forminator, a public request inspector, or a frontend script.

The webhook endpoint receives hostile traffic

An internet-accessible endpoint can be probed. A secret query token reduces accidental and opportunistic calls, but it is not the same as cryptographic webhook signing.

Fix: use HTTPS, keep the endpoint purpose-specific, check the token in constant time where practical, rate-limit the endpoint, validate every field, and accept only the minimal message shapes your form expects. If the form handles sensitive or high-value workflows, add a stronger server-side integration that can authenticate the source and look up the saved Forminator entry instead of trusting arbitrary inbound fields.

Test the complete path before publishing the form

A green test in a webhook configuration screen is not enough. It proves only that a URL responded at that moment. Test the actual visitor submission path.

Use this release checklist:

1. Submit the real public or staging form with a valid address and message.
2. Confirm that the bridge receives the expected field IDs and values.
3. Confirm that the internal recipient gets one email, with a valid Reply-To address.
4. Submit the same logical event again in a controlled test and confirm that the idempotency behavior is correct.
5. Submit a form without each required value and confirm that the bridge rejects it safely.
6. Exercise each conditional form branch and inspect missing or alternate fields.
7. Confirm that the sender domain is verified and the visible from address matches the intended brand.
8. Review logs for secrets, full form bodies, and unnecessary personally identifiable information; remove or redact them.

For high-intent forms, also check the mailbox result, not just the API result. API acceptance means Volanea accepted the message for processing; it is not the same thing as a recipient having read it. Use delivery and bounce events to improve the operational workflow over time.

Alternatives when a webhook bridge is not the right fit

A webhook bridge is the clearest option when you can deploy a small service and want predictable control over security and code. It is not the only route.

A WordPress must-use plugin

If you operate WordPress hosting but do not want a separate Node service, a small must-use plugin can hook into Forminator’s server-side submission lifecycle, retrieve the saved entry with Forminator’s API, map the field data, and call Volanea using WordPress HTTP functions.

This can be operationally simple because the key remains in the WordPress server environment. It also gives you direct access to the Forminator entry ID for idempotency. The trade-off is that you must own, test, and maintain PHP code across WordPress and Forminator updates.

An automation platform as middleware

Forminator webhooks can feed tools that accept webhooks, including automation platforms. That can be useful for prototyping or when a non-developer team needs to inspect and route submissions.

Do not assume that an automation workflow automatically makes the Volanea key safe. Store the key in the automation platform’s credential or connection store, never in a visible step value, and check whether the platform can set the required Authorization and Idempotency-Key headers. Also consider the extra cost, latency, retention of form data, and retry behavior introduced by another service.

WordPress email notifications through wp_mail()

For simple site-owner notifications, Forminator’s own email notification behavior may be enough. If your goal is to route ordinary WordPress-generated mail through Volanea rather than create purpose-built API sends, a WordPress mail-delivery setup may be more appropriate.

That route is different from this guide. It is about replacing or improving WordPress mail transport, while the webhook bridge approach is about transforming a specific form submission into a deliberately designed transactional email event.

Build the Forminator-to-Volanea integration as an event boundary

The value of this setup is not merely that it sends an email. It creates a controlled boundary between untrusted visitor input and a privileged sending API.

Forminator owns form presentation, validation, and submission collection. Your bridge owns authorization, schema validation, HTML escaping, idempotency, and operational logging. Volanea owns the email send pipeline and delivery infrastructure. Keeping those responsibilities separate makes the integration easier to change and safer to operate.

Start with one form, one internal recipient, a verified sender domain, and a stable idempotency key. Once that foundation is working, add customer confirmations, templates, queues, delivery events, and richer routing only where the workflow genuinely needs them.

FAQ

Does Forminator have a native Volanea integration?

No. There is no native Forminator marketplace app or plugin for Volanea. Use Forminator’s Webhook integration with a secure server-side bridge, or write a small WordPress-side integration using Forminator’s developer hooks.

Can I put the Volanea API key in the Forminator webhook URL?

No. Do not put the Volanea secret in a webhook URL, custom form field, hidden input, or browser JavaScript. Store it only in server-side environment variables, a secret manager, or protected WordPress configuration.

What is the correct Forminator trigger for this integration?

Use a successful form submission. The integration should run after Forminator has accepted the form data and created the submission entry, not when a visitor clicks a button or changes a field.

How do I stop duplicate Forminator emails?

Send every logical submission with a stable Volanea Idempotency-Key, ideally derived from the Forminator submission or entry ID plus the email purpose. Reuse that same key for retries.

Can I use the visitor’s email address as the sender?

No. Use a verified address on your own domain as from. Put the visitor’s address in replyTo for internal notifications, or in to when sending the visitor a confirmation.