How to Send Email from Getform with Volanea

If you need to send email from Getform, the dependable pattern is to use a Getform form-submission webhook, transform the submission on a server you control, and send the resulting message through Volanea’s REST API. This keeps your email credentials private while giving you complete control over recipients, content, validation, and duplicate prevention.

Getform is the event source in this setup: a visitor submits a form, Getform accepts the submission, and Getform posts the submitted fields to your webhook URL. Volanea is the delivery layer: your relay converts those fields into an email request and sends it using the API key stored only in server-side secrets.

This is intentionally not a marketplace-installation guide. Volanea does not provide a native Getform application, plugin, or marketplace listing. The webhook-plus-relay approach is more flexible than a fixed integration, but it also means you must explicitly design the boundary between public form data and a privileged email-sending API.

What starts the email send in Getform?

The trigger is a form submission. A browser, mobile app, or other client submits fields to the Getform endpoint for your form. Once Getform has received that submission, its webhook integration can make an outbound HTTP request to the URL you configured.

That distinction matters. Your browser should submit to Getform; it should not call Volanea directly. The browser is an untrusted environment, while the Volanea key can authorize mail delivery from your sending domain.

A practical contact-form flow looks like this:

1. A visitor completes fields such as name, email, subject, and message.
2. The visitor’s browser posts the form to Getform.
3. Getform records the submission and posts its submission payload to your relay webhook.
4. The relay checks that the request is authentic and that the fields are safe to use.
5. The relay calls Volanea’s email endpoint with an approved sender, recipient, subject, and HTML or text body.
6. Volanea accepts the request and handles the delivery process.

The key operational benefit is that the send happens after Getform has processed the form, rather than while a visitor is waiting for a page response. The key trade-off is that the two systems are asynchronous: a successful browser submission does not by itself prove that a notification email was sent.

Use separate messages for separate jobs

A single submission frequently creates two different messages:

• An internal notification to a shared support or sales inbox.
• A confirmation email to the person who completed the form.

Treat these as separate email jobs. An internal notification can safely use a fixed recipient that you define in an environment variable. A confirmation email uses the submitter’s address, but only after validation and only when the form makes that outcome clear to the visitor.

Do not blindly set your from address to the submitted email field. That commonly causes SPF, DKIM, DMARC, and reply-routing problems because the visitor does not control your authenticated sending domain. Use a verified address on your own domain as from, and use the visitor’s address as reply_to for the internal notification.

The integration architecture: Getform webhook to a secure relay

Getform webhooks deliver submission data to an HTTP endpoint. They do not turn arbitrary submission fields into a Volanea email request for you, and a direct webhook target has no safe place to perform the field transformation, recipient policy, idempotency checks, and error handling needed for transactional email.

The small middle layer can be a Cloudflare Worker, Vercel Function, Netlify Function, AWS Lambda behind an HTTP endpoint, or an application route in the server framework you already use. The choice matters less than the security properties:

• It accepts requests only over HTTPS.
• It verifies a shared webhook secret or another verification mechanism you control.
• It has access to server-side environment variables.
• It validates all fields before building an email request.
• It returns quickly enough that Getform does not treat the webhook as timed out.
• It stores an idempotency record before or while sending, so retries do not send the same notification repeatedly.

Think of the relay as an adapter, not as a second form backend. It should be small, deterministic, observable, and narrow in scope. It should not accept a visitor-provided to, from, HTML template, or API key.

Why a direct Getform-to-Volanea request is not the right fit

An email API expects a request shaped around email concepts: sender identity, recipient list, subject, content, and optional reply-to or tags. A Getform submission is shaped around the inputs in your form. The latter is intentionally flexible: one form might have full_name and project_budget; another might have email, message, and an uploaded file.

Because those shapes differ, a direct webhook target cannot safely infer your email policy. A relay explicitly maps one to the other. It is also the only place to keep a Volanea API key out of client-visible JavaScript and out of a public HTML form.

If you cannot deploy a relay, use an automation platform that can receive a Getform submission and make an authenticated HTTP request to an email API. That is a reasonable no-code option for low-volume workflows, but review its task pricing, retry behavior, data retention, and secret storage before using it for customer communications. For production contact forms, a small relay is usually easier to audit and test.

Configure the Getform submission webhook

In Getform, open the form that receives the submission and add a webhook integration that points to your relay’s public HTTPS endpoint, for example:

https://forms.example.com/webhooks/getform/contact

Use the webhook facility associated with the specific form, not a URL embedded in your client-side application. The event you want is the form submission event. Send a test submission from the actual form after saving the webhook configuration; a hand-built JSON request is useful for local development, but it cannot prove that your configured Getform form has the intended field names.

The submission payload is based on the field names in your form. For a conventional contact form whose controls are named name, email, subject, and message, the useful body is an object of submitted values like this:

{
  "name": "Avery Chen",
  "email": "avery@example.net",
  "subject": "Question about enterprise sending",
  "message": "Could someone contact me about our monthly volume?"
}

The important point is not the example values; it is the names. If your markup uses full_name rather than name, or inquiry rather than message, your relay must use those actual names. Keep a saved raw test payload from your own Getform webhook delivery and write tests against it.

Make the form schema intentional

Use stable name attributes and avoid changing them casually. A label can change from “Work email” to “Business email” without affecting the integration, but changing the underlying input name from email to work_email changes the payload contract.

For a notification workflow, a concise schema is often best:

Do not rely on an optional field being present. A visitor can omit it, a form can be revised, an integration may be configured for a different form, and some Getform features or payload details can vary by account plan and form configuration. Your handler should define defaults, reject required fields that are absent, and log the schema mismatch without exposing the submitted content in public error messages.

Map a Getform payload into a Volanea email request

Below is a complete JavaScript relay example for a serverless environment with the standard Fetch API. It accepts the submitted fields, verifies a webhook secret carried in a header you configure for the webhook, validates the input, escapes user-controlled text, and makes the Volanea REST send request.

Set VOLANEA_API_KEY, VOLANEA_FROM, CONTACT_INBOX, and GETFORM_WEBHOOK_SECRET as server-side environment variables. The API request uses Volanea’s REST email-send endpoint and bearer authentication; consult the email API reference and setup guides when selecting optional fields, sender-domain setup, or provider-specific delivery settings.

// Example: /webhooks/getform/contact
// Runtime: a server-side Fetch-compatible function (Worker, serverless function,
// or an app route adapted to expose Request/Response).

const VOLANEA_SEND_URL = "https://api.volanea.com/v1/emails";

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

function validEmail(value) {
  // A deliberately modest syntax check; do not treat it as mailbox verification.
  return typeof value === "string" && /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
}

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    // Configure this secret as a custom webhook header on the Getform side.
    // Never put VOLANEA_API_KEY in this header or in the form itself.
    if (request.headers.get("x-webhook-secret") !== env.GETFORM_WEBHOOK_SECRET) {
      return new Response("Unauthorized", { status: 401 });
    }

    let submission;
    try {
      submission = await request.json();
    } catch {
      return new Response("Invalid JSON", { status: 400 });
    }

    // These keys must match the `name` attributes in your Getform form.
    const name = String(submission.name ?? "").trim().slice(0, 120);
    const email = String(submission.email ?? "").trim().toLowerCase();
    const suppliedSubject = String(submission.subject ?? "").trim().slice(0, 160);
    const message = String(submission.message ?? "").trim().slice(0, 10000);

    if (!name || !validEmail(email) || !message) {
      return new Response("Required submission fields are missing or invalid", {
        status: 422
      });
    }

    const subject = suppliedSubject
      ? `Contact form: ${suppliedSubject}`
      : `Contact form message from ${name}`;

    const emailRequest = {
      from: env.VOLANEA_FROM,
      to: [env.CONTACT_INBOX],
      reply_to: email,
      subject,
      text: `Name: ${name}\nEmail: ${email}\n\n${message}`,
      html: `<h2>New contact-form submission</h2>
<p><strong>Name:</strong> ${escapeHtml(name)}<br>
<strong>Email:</strong> ${escapeHtml(email)}</p>
<p><strong>Message:</strong></p>
<p>${escapeHtml(message).replace(/\n/g, "<br>")}</p>`
    };

    const response = await fetch(VOLANEA_SEND_URL, {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify(emailRequest)
    });

    if (!response.ok) {
      const detail = await response.text();
      console.error("Volanea send failed", response.status, detail);
      // A non-2xx response tells Getform the webhook did not complete.
      // Add idempotency before enabling automatic retries in production.
      return new Response("Email provider request failed", { status: 502 });
    }

    return Response.json({ accepted: true }, { status: 202 });
  }
};

The mapping is deliberate: env.VOLANEA_FROM and env.CONTACT_INBOX are fixed by your organization; the submitter’s address becomes reply_to; and visitor content is escaped before it enters HTML. The text version remains useful for recipients who prefer plain-text mail and as a straightforward representation for incident investigation.

Add an acknowledgment email carefully

A separate confirmation send can be helpful after a support or sales inquiry. Build it as a second, distinct request after the internal notification succeeds. Keep the recipient set to the validated email, use a fixed from address, and do not promise a response time you cannot meet.

For newsletter or marketing follow-up, an inquiry form is not automatically permission. Capture explicit consent with a dedicated field, preserve the consent evidence, and route promotional communications through the appropriate consent-aware workflow. Transactional acknowledgment and marketing subscription are different purposes.

Keep the Volanea API key out of Getform and the browser

The Volanea API key belongs in the relay’s secret manager or encrypted server-side environment-variable store. It does not belong in your HTML, frontend bundle, mobile application, publicly readable deployment configuration, Getform hidden fields, or a client-visible Getform configuration.

Strictly speaking, the key should not live “on the Getform side” at all. Getform should know only the relay URL and, where supported by your webhook configuration, a separate shared webhook secret. The relay holds the Volanea key and is the only component permitted to use it.

This separation limits the blast radius of a compromised browser session or copied frontend code. If a public key can send mail, an attacker can use your authenticated sender identity for spam, phishing, or costly traffic. A webhook secret has a narrower job: it lets your relay reject arbitrary internet requests pretending to be Getform submissions.

Minimum secret-management checklist

• Create a dedicated Volanea API key for this integration rather than sharing a broad key across unrelated systems.
• Store it in the deployment platform’s encrypted secret store and expose it only to the relay runtime.
• Use a verified from address on a domain you control.
• Rotate the key if it appears in a repository, browser bundle, log, screenshot, or ticket.
• Redact Authorization headers and email-provider responses from normal application logs.
• Restrict access to the deployment project and secret manager to the people who operate the integration.

A shared webhook secret should also be long, random, and rotated when the integration ownership changes. Do not treat an obscure webhook URL as authentication. URLs are routinely leaked through logs, browser history, monitoring systems, and screenshots.

Validate content before it becomes email

A form endpoint receives internet input. Even when Getform validates required fields, the relay must enforce email-specific rules because it is making the privileged decision to send a message.

Start with structural validation: required fields exist, strings are within expected bounds, and the email field has a reasonable syntax. Then apply business validation: Is this form permitted to notify the sales inbox? Is the selected product valid? Is the message from a honeypot-marked bot? Is the submitter allowed to receive an acknowledgment?

Escape all text inserted into HTML. The code example uses escapeHtml because a visitor can submit markup, angle brackets, quotes, and misleading text. Escaping does not make the input trustworthy for every context, but it prevents that data from becoming live HTML in the message body.

For recipient addresses collected in forms, syntax validation is not delivery validation. Before an expensive onboarding sequence or a critical passwordless flow, consider using an address-quality check such as the free email address verification tool. For a normal internal contact notification, a lightweight syntax check plus reply_to is usually sufficient.

When this breaks: diagnose the Getform-to-email hop

Webhook integrations fail at boundaries. Build for those failures before a high-value lead or support request disappears into an unmonitored error log.

Retries can create duplicate emails

A webhook sender may retry when your endpoint returns a non-success status, closes a connection, or exceeds its timeout. The failure can happen after Volanea accepted the email but before your relay returned its success response. In that case, a retry can produce a second email.

Solve this with idempotency. Use a stable submission identifier if the Getform webhook provides one in the delivery you receive. Store it in a durable database or key-value store with a status such as processing or sent. If the same ID arrives again, return a successful response without sending another internal notification.

If your webhook body contains only form fields and no stable submission ID, create a short-lived fingerprint from canonicalized values plus a narrow time window. That is less reliable: two genuine identical submissions could be suppressed, while a retry with a slightly altered value may still duplicate. Prefer an actual submission identifier whenever your Getform delivery exposes one.

Webhook timeouts cause ambiguity

Do not wait for slow downstream work before responding if your relay has a queue available. Validate and record the event, enqueue the email job, then return a success response promptly. A worker can perform the Volanea request afterward and retry failures under your own controlled policy.

For smaller installations that send synchronously, keep the handler lean: no long third-party enrichment calls, no large file processing, and no serial calls that do not affect the notification. Log duration, response status, and a correlation ID. You need those three data points to distinguish a Getform timeout from an email API rejection.

Fields can be missing or shaped differently

Payload assumptions break when a form is edited, an optional input is blank, a checkbox is unchecked, file handling is enabled, or an integration capability differs by Getform account plan or configuration. A webhook that worked for a four-field contact form may not have the same field behavior after you add uploads, multi-select controls, or conditional questions.

Defend against this by keeping a schema contract in version control and testing at least these cases:

1. A valid complete submission.
2. A submission without every optional field.
3. A malformed or non-JSON request.
4. An invalid submitter email.
5. A repeated delivery of the same submission.
6. A provider error after the relay has accepted the webhook.

Return a clear machine-readable failure to the webhook sender, but never include private email content in that response. Put detailed diagnostics in protected logs with retention rules appropriate for form data.

Authentication failures are usually configuration failures

A 401 from your relay normally means the webhook secret is absent or wrong. A 401 or 403 from Volanea normally means the API key is missing, revoked, malformed, or not available to that deployed environment. A delivery rejection can also indicate that the from identity is not verified or does not match your sending-domain configuration.

Test secrets in the deployed environment, not only locally. Many deployment platforms distinguish preview, staging, and production secrets; a locally successful request says little about whether production has the correct variables.

Deliverability choices for form-triggered mail

Contact-form mail is transactional communication, but it can still damage deliverability if it resembles unsolicited mail, uses spoofed senders, or sends duplicate bursts. The cleanest pattern is an authenticated organization-controlled sender such as forms@example.com, a stable display name, and a visitor address in reply_to.

Keep operational notifications separate from bulk campaigns. A contact-form notification is typically low-volume, event-driven, and addressed to a known internal inbox. A marketing email sent to every person who happens to submit a question has different consent, content, suppression, and engagement requirements.

Content also matters. Include the context recipients need—name, address, message, form name, and submitted time—but do not forward hidden form fields, anti-spam tokens, or raw metadata as customer-visible content. If the message may contain sensitive information, minimize the email content and link authenticated staff to a secure internal record instead.

Testing and observing the integration

Before publishing the form, run an end-to-end test using a real Getform submission. Confirm each boundary separately:

• Getform records the submission.
• Getform reaches the relay URL.
• The relay accepts the configured authentication method.
• The field names map to the expected variables.
• Volanea accepts the request.
• The internal recipient receives the email with the correct sender and reply-to.

Use a test inbox you control and send cases with punctuation, Unicode characters, line breaks, empty optional fields, and HTML-like text. These are the cases that reveal broken escaping and encoding assumptions.

Add a correlation ID to your logs and, if your chosen Volanea API options support it, to the outbound message metadata or tags. Do not use the submitter’s raw email address as a correlation ID. A random ID or a hashed internal submission ID is safer for log searches.

Monitor more than successful HTTP status codes. Track webhook received count, rejected validation count, deduplicated count, Volanea acceptance count, provider error count, and queue age if you use asynchronous processing. A sudden drop in accepted submissions can indicate a changed Getform field name; a spike in duplicate suppression can indicate retries or an endpoint performance regression.

Alternatives when you cannot run a relay

A no-code automation service can bridge a Getform submission trigger to an HTTP request. The pattern is still the same: Getform emits a submission, the automation maps fields, and an authenticated request sends email. Keep the Volanea key in the automation platform’s protected connection or secret facility, never in a field supplied by the visitor.

This route is useful for prototypes and internal workflows, especially when non-developers need to own the mapping. Its limitations are operational rather than conceptual: task quotas, execution latency, branching limits, provider outages, and less control over idempotency can become material as volume grows.

A relay is the stronger choice when you need any of the following:

• Strict recipient allowlists or dynamic routing rules.
• Reliable duplicate suppression.
• Custom templates with safe rendering.
• Data minimization or regional processing requirements.
• Detailed logs and alerting under your own retention policy.
• A clear route to queues, retries, and dead-letter handling.

Conclusion

To send email from Getform with Volanea, use Getform’s form-submission webhook as the trigger and place a secure server-side relay between the form backend and the email API. Map the exact form field names to a fixed sender, controlled recipient policy, sanitized subject and body, and a validated reply-to address.

The relay is not needless complexity. It is where you protect the Volanea API key, prevent a public form from becoming an open mail relay, handle webhook retries, and make changes to your form schema without silently breaking notifications. Start with one internal notification, test it end to end, then add confirmation messages, queues, and idempotency as the workflow becomes more important.

FAQ

Does Volanea have a native Getform integration?

No. This setup uses Getform’s outbound webhook capability and your own relay or automation layer; it is not an installable Getform marketplace plugin.

What Getform event triggers the Volanea email?

A form submission triggers the flow. After Getform receives the submitted form data, it sends the configured webhook request to your relay, which then calls Volanea.

Where should I put the Volanea API key?

Store it only in server-side secrets for the relay or in the protected secret store of your automation platform. Do not put it in browser code, hidden form fields, or a public Getform configuration.

Can I use the form submitter’s email as the From address?

No. Use a verified address on your own sending domain as from and set the submitter’s validated address as reply_to for internal notifications.

How do I stop duplicate emails when Getform retries a webhook?

Record a stable Getform submission ID before sending and treat later deliveries of that ID as already processed. If no stable ID is available in your delivery, use a short-lived fingerprint only as a fallback.