Everest Forms can collect contact requests, registrations, quote requests, and other submissions—but sending the right follow-up reliably needs more than a standard WordPress notification. This guide shows how to send email from Everest Forms through a secure webhook relay and Volanea’s REST API, without pretending there is a native Everest Forms app or marketplace plugin.

The integration is deliberately split into two hops:

An Everest Forms submission triggers its Webhook feature.
Your server-side relay validates and maps that submission, then calls Volanea’s POST /v1/send endpoint.

That design keeps the Volanea secret key out of browser-visible code, gives you a place to validate untrusted form input, and lets you protect against duplicate emails when a webhook delivery is retried.

What Everest Forms actually provides

Everest Forms does not provide a native Volanea integration, installable Volanea app, or marketplace connector. The correct integration point is its Webhook feature, which is available on Everest Forms’ Premium plan.

The webhook is configured per form. Everest Forms describes the event in practical terms: every time a visitor submits a form, the form’s information can be sent to an external URL. In other words, the trigger for this integration is a form submission—not a CRM record, lifecycle stage, or campaign event.

In the form settings, Everest Forms lets you configure:

A Request URL for the external endpoint.
A request method, including POST.
A request format of JSON or FORM.
Optional request headers.

For this integration, use POST and JSON. JSON is easier to validate, less ambiguous than URL-encoded form data, and a natural fit for a server-side relay.

Why not point Everest Forms directly at Volanea?

There are two reasons not to call the email API directly from the Everest Forms webhook configuration.

First, an Everest Forms submission is form data, while an email API request needs a deliberate email object: a verified sender, recipient, subject, HTML or text content, and often a reply-to address. A relay converts one into the other safely.

Second, the Volanea API key is a secret credential. Even though Everest Forms sends webhooks from WordPress server-side, putting the Volanea key directly into a general-purpose webhook header makes it harder to rotate, scope, audit, and protect. A relay lets Everest Forms authenticate using a separate, limited shared secret while the Volanea key remains only in the relay’s environment configuration.

That boundary also prevents a compromised WordPress administrator account, a configuration export, or verbose request logging from automatically becoming unrestricted access to your transactional email account.

The architecture: Everest Forms → relay → Volanea

A dependable implementation has three responsibilities split across the right systems.

Component	Responsibility
Everest Forms	Collects and validates the visitor’s form submission, then sends JSON to your webhook URL.
Your webhook relay	Verifies the request, validates required fields, maps values into an email, and creates a stable idempotency key.
Volanea	Accepts the email through `POST /v1/send`, checks suppression status, processes the message, and dispatches it.

The relay can be a small Node.js endpoint, a serverless function, a WordPress must-use plugin endpoint, a Laravel controller, or another service your team already operates. The important requirement is that it runs server-side and can read secrets from environment variables.

A practical contact-form example

Assume you have an Everest Forms contact form with these fields:

Name, stored with the meta key full_name
Email, stored with the meta key email
Company, stored with the meta key company
Message, stored with the meta key message
A hidden field named submission_token

Using stable, readable meta keys makes integration mapping much easier. Everest Forms supports editable field meta keys in Pro, but changing an existing meta key can disconnect historical entry data and break existing integrations. Set your keys before the form goes live, then treat them as part of the form’s API contract.

When a visitor submits that form, the webhook payload is the submitted field data. Everest Forms does not document a universal, fixed event envelope with a guaranteed event, data, and id structure. Its webhook sends the form’s data in the selected request format, so your payload keys follow the fields configured in your form.

For the example fields above, a JSON submission payload is shaped like this:

{
  "full_name": "Jordan Lee",
  "email": "jordan@example.com",
  "company": "Northstar Labs",
  "message": "Could you send pricing and implementation details?",
  "submission_token": "ef-9bb22b91-4aae-442b-95e7-8aaf6fd9fe70"
}

Your exact keys and nested values depend on the fields you create. Test the real form against a request inspector or your relay’s structured logs before relying on a production mapping—especially if the form contains address fields, checkboxes, repeaters, file uploads, or conditional fields.

Set up the Everest Forms webhook

Before creating the webhook, make sure you have:

An active Everest Forms plan that includes Webhook.
A published form with the required fields.
A publicly reachable HTTPS endpoint for your relay.
A verified Volanea sending domain and a sender address on that domain.
A Volanea secret key stored in your relay environment, not in the form.

Configure stable field keys first

Open the form in the Everest Forms builder and inspect each field’s advanced settings. For the fields your relay needs, use descriptive meta keys such as full_name, email, company, and message.

Avoid mapping your integration to display labels such as “Your Email Address” or “Tell us about your project.” Labels are content and can change during copy edits. Meta keys are the better long-lived integration identifier.

Make the email field required in Everest Forms. Frontend validation improves the visitor experience, but still treat its value as untrusted at the relay. A bot, direct request, broken integration, or unexpected field configuration can bypass the assumptions you made in the form builder.

Add the webhook connection

In the relevant Everest Forms form, open Settings > Webhook, enable the webhook, and configure the connection:

Request URL: https://forms.example.com/hooks/everest-contact
Request Method: POST
Request Format: JSON
Request Headers: add a static secret header for your relay, such as X-Everest-Webhook-Secret

The static header value should be a long random secret generated for this one integration. It is not the Volanea key. For example, your relay might expect a value stored as EVEREST_WEBHOOK_SECRET.

Do not use a secret in a query string. URLs are commonly retained in access logs, proxy logs, analytics tools, browser history during testing, and error reports. A header is better, and HTTPS is required, but it is still a credential: limit access to the WordPress administration area and avoid dumping incoming headers into application logs.

Know the trigger precisely

The event that begins the flow is a visitor submitting the Everest Forms form. A successful submission causes Everest Forms to send the configured outbound request to your Request URL.

This distinction matters when you plan the email. The email is connected to submission acceptance, not necessarily to a payment succeeding, an administrator approving an entry, or a human reviewing the lead. If you need one of those later states, keep the confirmation email separate from any post-review or post-payment email workflow.

Store authentication in the right place

There are two secrets in this design, and they have different jobs.

The Everest-to-relay secret

Store a random shared secret in the Everest Forms webhook’s request-header configuration. The relay compares it with its own EVEREST_WEBHOOK_SECRET environment variable.

This header proves that the request came from someone who knows the integration configuration. It is useful because the endpoint is publicly reachable. However, it should not be treated as a substitute for normal WordPress security, HTTPS, rate limits, payload validation, and monitoring.

The Volanea API key

The Volanea API key should not live in Everest Forms at all. Store it only in the relay’s server-side secret store or environment configuration, for example:

VOLANEA_API_KEY=sk_...
EVEREST_WEBHOOK_SECRET=replace-with-a-long-random-value
VOLANEA_FROM_EMAIL="Website Team <hello@example.com>"
SALES_INBOX=sales@example.com

Never place VOLANEA_API_KEY in a JavaScript bundle, a WordPress page, a hidden form field, a front-end AJAX request, a query parameter, or a client-visible configuration object. Anyone who can inspect the page or intercept browser traffic could reuse a leaked secret key to send email as your account.

A server-side relay has another operational advantage: key rotation. You can issue a replacement key, change one environment variable, deploy, confirm sends work, and then revoke the old key. There is no need to edit every Everest form or expose the email credential to WordPress users who only need to maintain form settings.

For more endpoint syntax and authentication details, use the Volanea email API reference as the source of truth when implementing your production relay.

Working relay code: map an Everest Forms submission to Volanea

The following Node.js example uses Express. It accepts an Everest Forms JSON submission, checks the relay secret, validates form fields, escapes user-supplied text before inserting it into HTML, and sends an internal lead notification through Volanea.

It uses the hidden submission_token field as the idempotency value. That field must be generated uniquely per submission. If you do not have a stable submission identifier in the payload, add a hidden field whose value is generated before submission, or adapt the relay to persist a fingerprint and delivery state in a database.

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

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

const {
  EVEREST_WEBHOOK_SECRET,
  VOLANEA_API_KEY,
  VOLANEA_FROM_EMAIL,
  SALES_INBOX
} = process.env;

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

function validEmail(value = "") {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(String(value));
}

function sameSecret(received, expected) {
  if (!received || !expected) return false;

  const a = Buffer.from(received);
  const b = Buffer.from(expected);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

app.post("/hooks/everest-contact", async (req, res) => {
  const relaySecret = req.get("X-Everest-Webhook-Secret");

  if (!sameSecret(relaySecret, EVEREST_WEBHOOK_SECRET)) {
    return res.status(401).json({ error: "Unauthorized webhook request" });
  }

  // Everest Forms JSON webhook payload: field meta key -> submitted value.
  const {
    full_name,
    email,
    company = "",
    message,
    submission_token
  } = req.body ?? {};

  if (!full_name || !email || !message || !submission_token) {
    return res.status(422).json({
      error: "Missing one or more required form values"
    });
  }

  if (!validEmail(email)) {
    return res.status(422).json({ error: "Invalid submitter email" });
  }

  const safeName = escapeHtml(full_name);
  const safeEmail = escapeHtml(email);
  const safeCompany = escapeHtml(company);
  const safeMessage = escapeHtml(message).replace(/\r?\n/g, "<br>");

  const emailPayload = {
    from: VOLANEA_FROM_EMAIL,
    to: [SALES_INBOX],
    replyTo: email,
    subject: `New website enquiry from ${full_name}`,
    html: `
      <h1>New Everest Forms submission</h1>
      <p><strong>Name:</strong> ${safeName}</p>
      <p><strong>Email:</strong> ${safeEmail}</p>
      <p><strong>Company:</strong> ${safeCompany || "—"}</p>
      <p><strong>Message:</strong><br>${safeMessage}</p>
    `
  };

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

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

  if (!response.ok) {
    console.error("Volanea send failed", {
      status: response.status,
      result,
      submissionToken: submission_token
    });

    return res.status(502).json({
      error: "Email provider request failed"
    });
  }

  return res.status(200).json({
    accepted: true,
    email: result
  });
});

app.listen(process.env.PORT || 3000, () => {
  console.log("Everest Forms relay is listening");
});

What the field mapping does

The mapping is explicit rather than magical:

Everest Forms JSON key	Relay purpose	Volanea email field
`full_name`	Identifies the submitter	Included in the subject and HTML body
`email`	Contact address supplied by the visitor	Used as `replyTo` for the internal notification
`company`	Optional qualification detail	Included in the HTML body
`message`	Main enquiry text	Included in the HTML body
`submission_token`	Unique submission identity	Included in `Idempotency-Key`

The recipient in this example is your internal sales inbox, not the visitor. That keeps the first use case simple: each form submission becomes a reliable lead notification with Reply configured to address the person who submitted the form.

If you want to send an acknowledgment to the visitor as well, make it a separate email with a separate idempotency suffix, such as everest-contact:${submission_token}:customer-receipt. Never blindly use form text as raw HTML. Escape it first, and do not allow the visitor to control sender addresses, privileged recipients, API options, or headers.

Build a useful email, not just a working request

A form-to-email integration should preserve context without creating a deliverability or security problem.

Use a verified sender you control

Set from to an address on a verified domain you own, such as Website Team <hello@example.com>. Do not set the visitor’s email as the From address. Doing so can break alignment and make spoofing or reply handling harder to manage.

Use replyTo for the visitor’s address when the email is an internal alert. Your team can hit Reply and continue the conversation with the prospect, while the message still originates from your verified domain.

Keep subject lines deterministic

A subject such as New website enquiry from Jordan Lee is helpful, but it contains visitor-provided text. Limit its length and strip line breaks before production use to avoid malformed mail headers or unreadable subjects.

A more controlled alternative is New contact request — website, with the name visible only in the message body. This makes inbox filtering more predictable and reduces the chance that unusual form input creates confusing notifications.

Send a customer confirmation separately

An acknowledgment email is often valuable, particularly for quote requests, event registrations, support requests, and applications. It should have a different purpose and content from the internal notification.

For example, a customer confirmation could say that the request was received, set response expectations, and include a safe copy of the relevant details. It should not promise availability, pricing, or approval unless those statements are genuinely automated and accurate.

If you send both emails, model them as two independently idempotent sends. One successful internal notification must not make you assume the acknowledgment succeeded, and vice versa.

Test the entire submission path before publishing

Testing only the Volanea API call is not enough. The risk is usually in the join between the form payload and your mapping.

Use a non-production form or a temporary test page first. Submit examples that represent real-world variation:

A normal submission with every field populated.
A submission with optional fields blank.
A name or company containing apostrophes, ampersands, and angle brackets.
A multiline message.
An invalid or unexpectedly formatted email sent directly to the relay.
A repeat delivery using the same submission_token.

Confirm what Everest Forms really sends

During setup, point the Request URL at a controlled request inspector or add carefully redacted relay logging. Capture the actual JSON body generated by your exact form.

This is particularly important if you add advanced Everest Forms fields. Checkbox values may be arrays, address values may be structured, repeater fields may carry repeated data, and optional conditional fields may not appear in every submission. A production relay should tolerate missing optional keys and reject missing required ones with a clear error.

Do not log full payloads indefinitely. Contact forms often include names, addresses, telephone numbers, messages, and sometimes information that should not live in logs. Record only what is necessary for diagnosis, such as a submission token, outcome, status code, and a redacted destination.

Check email outcomes separately from HTTP success

A 200 response from your relay means the relay accepted and handled the webhook request. It does not automatically prove the email reached an inbox.

Likewise, a successful Volanea API response means the provider accepted the send request, not that every recipient will receive it. Watch your sending activity and delivery events for bounces, suppressions, rejects, and delivery outcomes. A clean webhook-to-API handoff is only one layer of a reliable email program.

When this breaks: Everest Forms webhook failure modes

Every integration fails somewhere eventually. The practical question is whether it fails quietly, duplicates a customer email, exposes a useful diagnostic, or blocks form submission.

Retries can produce duplicate sends

A webhook sender may retry after a connection error, timeout, or uncertain response. The worst case is when your relay sent the message to Volanea successfully but the response back to Everest Forms was interrupted. Everest Forms may consider the request failed and send it again.

That is why the example sends an Idempotency-Key derived from submission_token. Volanea supports idempotency keys for safe retries. Reusing the same key for the same logical email lets a retry resolve without creating a second message.

The key must be stable for the event. Do not generate a random UUID inside the relay on every request; that would turn every retry into a brand-new send. Use a form-generated unique ID, entry identifier if your payload provides one, or a persisted event record.

Webhook timeouts can make the form feel unreliable

The outbound webhook executes after the form submission path, and a slow relay or downstream email API can make the experience brittle. Your relay should do only the work needed to validate, map, submit, and respond.

Avoid doing slow CRM lookups, enrichment calls, PDF generation, image transformations, or large attachment processing synchronously in this endpoint. If you need those, persist the validated submission and process the extra work through a queue.

A practical pattern is:

Verify the request and validate the payload.
Create or identify the idempotent event.
Submit the essential notification to Volanea.
Return a concise success response.
Process nonessential work asynchronously.

If your form has high volume or the business consequences of missed leads are significant, use a durable queue and persist send state. Then you can retry delivery even if Volanea or your relay has a temporary outage.

Fields may be missing on some submissions or plans

Everest Forms makes fields optional, conditionally visible, and configurable. A payload that worked in your test can lack company, message, or another value in production when a conditional branch changes.

Also distinguish core form capability from premium features. Everest Forms’ outbound Webhook feature is listed as a Premium-plan feature. If the site is running a plan without it, do not promise a direct webhook route; use the official Zapier integration or another server-side automation bridge instead.

Your relay should default optional fields, enforce essential fields, and return 422 Unprocessable Entity for a malformed submission. That response is more actionable than allowing an API call with missing recipient or malformed content.

Header mismatch returns unauthorized requests

If every webhook returns 401, compare the configured static request header with the relay’s expected header name and value. Look for accidental whitespace, stale secrets after rotation, or a proxy that strips custom headers.

Use an explicit header such as X-Everest-Webhook-Secret, not Authorization, for the Everest-to-relay layer. This keeps it conceptually separate from Volanea’s API authorization and makes logs easier to interpret.

A direct form submission bypasses assumptions

Browser validation is not a security boundary. A malicious client can submit unexpected JSON directly to a public endpoint, manipulate field values, or attempt HTML injection in a message.

The relay must validate email syntax, constrain lengths, escape HTML output, and allow only server-controlled sender and destination addresses. For high-risk forms, add rate limiting, bot protection at the form layer, and a database-backed deduplication record.

Volanea rejects the send request

If the relay receives a non-success response from Volanea, retain the HTTP status and a redacted response in structured logs. Typical causes include an invalid key, a sender address or domain that is not ready to send, malformed recipients, or suppression rules.

Do not return the provider’s raw response to the website visitor. It can disclose internal configuration details. Return a generic error to Everest Forms, alert your team through logs or monitoring, and investigate in the email platform’s send records.

Alternatives when a direct relay is not your best fit

The webhook relay is the most direct approach for developers because it gives you full control of validation, email construction, secrets, and idempotency. But it is not the only route.

Use Zapier as middleware

Everest Forms has an official Zapier integration, and its documentation identifies New Form Submission as the trigger. This is suitable when your team prefers a managed automation layer and does not want to host a public endpoint.

However, do not put a Volanea secret key into a browser-side step or unreviewed client configuration. If your Zapier workflow uses a generic webhook action to call Volanea, the credential should be stored in Zapier’s secured connection or action configuration, with access limited to the people who maintain the automation.

Zapier can simplify routing and notifications, but you still need to think about retries and duplicates. Use a stable submission identifier in the idempotency key whenever the action can retry.

Use Make or another automation tool

Make can play the same middleware role if it can receive the Everest Forms webhook and issue an authenticated HTTP request to the email API. The core rules remain the same:

Keep the API key in the platform’s secured connection or variable store.
Map fields explicitly.
Validate missing fields before sending.
Use a stable idempotency value.
Capture failures in an error-handling path.

For a low-volume internal alert, an automation platform can be perfectly reasonable. For customer-facing confirmations, regulated data, high volume, or complex business rules, a relay you own is usually easier to audit and test.

Use Everest Forms’ normal email notifications for simple cases

Everest Forms includes built-in email notification settings. Those are appropriate when you simply need WordPress to notify an administrator or a user after form submission.

Use the Volanea relay pattern when email is part of an application workflow: you need API-level observability, a sender domain managed for deliverability, idempotent retries, custom logic, reusable transactional patterns, or a clean boundary between form collection and message delivery.

Deliverability and privacy considerations

A contact form integration affects more than code. It creates a stream of real email, which means it affects sender reputation, inbox workflow, and personal-data handling.

Keep transactional and promotional intent separate

A submission acknowledgment is transactional when it confirms something the visitor just requested. Adding a visitor to a marketing campaign is a separate consent question.

Do not treat “submitted a contact form” as automatic permission to send promotional mail unless the form clearly captures the appropriate consent and your program follows the applicable rules. Keep the confirmation useful and specific to the form action.

Verify recipient addresses before sending customer mail

Everest Forms’ email field validates the general format on the frontend, but format validation cannot prove a mailbox is active, safe, or wanted. For higher-risk flows—such as waitlists, account creation, or quotes—consider verifying addresses before adding them to subsequent workflows.

You can use the free email address verification tool when testing a workflow or checking individual addresses. Do not use verification as a substitute for consent or suppression management.

Avoid including sensitive data in emails

Email is not an ideal place for passwords, payment details, government IDs, medical information, or anything a recipient should not have in an inbox. If your Everest Form collects sensitive information, send an internal notification that says a secure submission is available, then have staff view the protected data in the appropriate system.

The same applies to logs. The relay’s log should identify the event without permanently duplicating every field submitted through your website.

A production checklist

Before enabling the form on a live page, confirm the following.

Conclusion

The reliable way to send email from Everest Forms with Volanea is not a fictional plug-and-play app. It is a controlled webhook integration: an Everest Forms submission triggers a JSON POST to your relay, the relay validates and maps the field data, and Volanea sends the resulting transactional email through its REST API.

This small architectural boundary solves the important problems: the Volanea key stays server-side, form data is not trusted blindly, emails can use a verified sender and sensible reply-to behavior, and idempotency protects against duplicate sends when delivery is retried. Start with one internal notification, capture the real payload from your form, and add customer confirmations or downstream workflows only after the core path is observable and repeatable.

FAQ

Does Everest Forms have a native Volanea integration?

No. Everest Forms does not offer a native Volanea app or marketplace plugin. Use its Premium Webhook feature to call a secure relay, then call Volanea from that relay.

What triggers the email send?

The trigger is a form submission. When a visitor submits the configured Everest Forms form, its webhook sends the form data to your relay, which decides whether and how to send the email.

Can I put my Volanea API key in Everest Forms webhook headers?

Technically, a webhook can send custom headers, but it is not the recommended design. Keep the Volanea key only in your server-side relay environment. Configure Everest Forms with a separate limited webhook secret instead.

How do I prevent duplicate emails after retries?

Use Volanea’s Idempotency-Key header and derive it from a stable per-submission identifier, such as a unique hidden submission_token. Reuse the same key for retries of the same logical email.

What if my Everest Forms plan does not include Webhook?

Use Everest Forms’ official Zapier integration or another middleware approach rather than claiming a direct outbound webhook exists. Keep the Volanea key in the automation platform’s secure connection settings or in a server-side relay—not in client-visible code.

How to Send Email from Everest Forms with Volanea