Send email from Landingi without exposing an email API key by using Landingi’s built-in form webhook as the trigger and a server-side relay as the secure sending boundary. This setup sends a confirmation immediately after a visitor submits a form, while Volanea handles the actual transactional email request.

Landingi does not have a native Volanea app, Marketplace listing, or one-click connector. The supported route is its form-level Webhook integration: when a visitor submits a form, Landingi sends the connected fields to an endpoint you control. That endpoint validates the request, maps the lead into an email message, and calls Volanea’s POST /v1/send API.

The important design choice is the relay. Landingi can send outbound POST requests and can attach request headers, but its POST integration sends data as a query string rather than as Volanea’s JSON request body. More importantly, your Volanea secret key should remain in server-side environment variables, not in a landing-page configuration, browser script, or form markup.

What triggers the email in Landingi

The concrete trigger is a form submission. In Landingi, open the landing page editor, select the Form widget, open Settings, then go to the Integrations tab and choose Webhook.

A visitor completing and submitting that form starts the flow. Landingi processes the form and posts the fields you connected in the Webhook configuration to your request URL. This is not an automation based on a CRM stage change, a manually created lead, or a delayed workflow event. It is specifically tied to the visitor submitting the form on the published landing page, pop-up, or lightbox.

That distinction matters for the email you send. A form-submission email is best suited to a direct acknowledgement, such as:

a download or resource-delivery email;
a webinar registration confirmation;
a demo-request acknowledgement;
an application-received receipt;
a double-confirmation message that explains the next step;
an internal alert to a sales or support mailbox.

Do not use this event as a reason to immediately send a broad promotional sequence. A visitor may have asked for a guide, a consultation, or an event seat—not necessarily consented to ongoing marketing. Keep the first message tightly connected to the form’s purpose and make any future campaign enrollment depend on the consent language and rules that apply to your audience.

Why the recommended setup uses a relay

The most reliable architecture is:

Visitor submits a Landingi form
        ↓
Landingi Webhook integration sends POST fields
        ↓
Your HTTPS relay validates and normalizes the payload
        ↓
Relay calls Volanea POST /v1/send with JSON
        ↓
Volanea accepts, queues, and tracks the email

It may seem tempting to point Landingi directly at https://api.volanea.com/v1/send and add Authorization: Bearer ... in the Webhook request headers. Avoid that approach.

First, Landingi’s POST integration documents its data format as a query string. Volanea’s send endpoint expects a JSON email payload containing fields such as the sender, recipient, subject, and content. A direct request would force you to make form-field names mimic an email API body, but it still would not provide a dependable JSON transformation layer.

Second, the API key is a credential with authority to send email through your account. It belongs in a secret manager or environment variable on infrastructure you control. Even if a platform configuration field is not rendered in the landing page HTML, storing a high-value sending credential in a no-code form integration makes routine maintenance, access review, rotation, and incident response harder than they need to be.

Third, a relay gives you the operational controls a landing-page webhook does not: request authentication, field validation, rate limits, duplicate prevention, logging, analytics context, and a safe response when the email provider is temporarily unavailable.

For a simple serverless implementation, the relay can be a Vercel Function, Netlify Function, Cloudflare Worker, AWS Lambda behind API Gateway, or a route in an existing Node, Python, Ruby, PHP, or Go application. The relay does not need a database to send a first email, although a shared store is strongly recommended once traffic or duplicate risk matters.

Configure the Landingi Webhook integration

Start by creating the form fields you need. For this example, use visible fields named email, first_name, and company. The names on your actual form can differ, but use stable, understandable names and map them deliberately.

In the Landingi editor:

Select the form and open Settings.
Open the Integrations tab.
Choose Webhook.
Set Request URL to your relay endpoint, such as https://hooks.example.com/landingi/lead.
Set Request method to POST.
Connect the Landingi form fields to the names your relay expects.
Add a fixed request parameter such as source=landingi and, if useful, form_name=demo-request.
Add a request header for a relay-specific secret, such as X-Landingi-Token: <random-value>.
Save, publish, and submit a real test entry.

Use a random relay token, not the Volanea API key, in the Landingi request headers. Its only job is to let your relay reject random public traffic. Generate a high-entropy value and store the same value as LANDINGI_WEBHOOK_TOKEN in your relay’s server-side secrets.

Your Webhook configuration is also where you decide what information reaches the relay. Connect the email field explicitly. If you want personalization, connect the first-name field too. A company name, selected interest, page label, language, campaign identifier, or consent value can be useful, but send only data you actually need for the message and its audit trail.

Landingi also supports additional request parameters. These are helpful for static context that does not need to appear in the visible form, such as a form label or source system. They are not a substitute for trustworthy user identity, and they should not be treated as proof that the recipient consented to marketing.

The payload Landingi sends

Landingi documents its POST integration as sending form data in query string format. In practical terms, your webhook receiver should accept a URL-encoded body rather than assume JSON.

With the field mapping described above, a representative request body is:

email=alex%40example.com&first_name=Alex&company=Northstar+Labs&source=landingi&form_name=demo-request

After URL decoding, the relay receives the equivalent values:

{
  "email": "alex@example.com",
  "first_name": "Alex",
  "company": "Northstar Labs",
  "source": "landingi",
  "form_name": "demo-request"
}

The exact field names and values are determined by the form fields and mappings you configure. Landingi does not automatically invent a universal lead schema containing a submission ID, page ID, timestamp, UTM bundle, consent record, and every field visible elsewhere in the product. Your receiver should therefore be tolerant of optional fields and strict about the few fields required to send an email.

For this use case, the minimum required field is usually email. Treat first_name and company as optional. If you add a required checkbox for terms, privacy acknowledgement, or marketing permission, make sure the submitted value is mapped and that your relay interprets it correctly rather than relying on a display-only label.

Field mapping for a confirmation email

A practical mapping can look like this:

Landingi field or parameter	Relay variable	Volanea use
`email`	`recipient`	`to`
`first_name`	`firstName`	greeting and text content
`company`	`company`	optional message personalization
`form_name`	`formName`	email metadata or message copy
`source`	`source`	internal metadata or logging

Never map user-controlled form input into the sender address, authorization header, API endpoint, or arbitrary email headers. The visitor’s input should influence content only after validation and escaping. Your verified sender address, reply-to address, subject prefix, and Volanea API key should be controlled by server-side configuration.

Working relay code: Landingi query string to Volanea JSON

The following Node.js and Express example accepts Landingi’s URL-encoded POST, checks a relay token, validates the lead email, creates safe message content, and sends it through Volanea.

Install Express first:

npm install express

Set these server-side environment variables in your hosting provider’s secret settings:

VOLANEA_API_KEY=sk_live_replace_with_your_secret_key
LANDINGI_WEBHOOK_TOKEN=replace_with_a_long_random_relay_token
VOLANEA_FROM="Northstar Team <hello@updates.example.com>"
VOLANEA_REPLY_TO=sales@example.com

The domain used in VOLANEA_FROM must already be verified in Volanea. Do not use a visitor-provided address as the from value. Put the visitor’s address in the recipient field for an acknowledgement email, or use it in a safely escaped internal-notification body.

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

const app = express();

// Landingi POST integrations send query-string / URL-encoded form fields.
app.use(express.urlencoded({ extended: false }));

const {
  VOLANEA_API_KEY,
  LANDINGI_WEBHOOK_TOKEN,
  VOLANEA_FROM,
  VOLANEA_REPLY_TO
} = process.env;

if (!VOLANEA_API_KEY || !LANDINGI_WEBHOOK_TOKEN || !VOLANEA_FROM) {
  throw new Error("Missing required server-side environment variables");
}

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

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

function isEmail(value) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
}

app.post("/landingi/lead", async (req, res) => {
  // This token protects the relay. It is not the Volanea API key.
  if (req.get("X-Landingi-Token") !== LANDINGI_WEBHOOK_TOKEN) {
    return res.status(401).json({ error: "Unauthorized webhook" });
  }

  const recipient = cleanText(req.body.email).toLowerCase();
  const firstName = cleanText(req.body.first_name) || "there";
  const company = cleanText(req.body.company);
  const formName = cleanText(req.body.form_name) || "your request";
  const source = cleanText(req.body.source) || "landingi";

  if (!isEmail(recipient)) {
    return res.status(422).json({ error: "A valid email field is required" });
  }

  // Stable for an identical submitted payload. For production, combine this
  // with a Redis/database idempotency record and a sensible expiry window.
  const normalizedEvent = JSON.stringify({
    recipient,
    firstName,
    company,
    formName,
    source
  });
  const idempotencyKey = `landingi-${crypto
    .createHash("sha256")
    .update(normalizedEvent)
    .digest("hex")}`;

  const safeName = escapeHtml(firstName);
  const safeCompany = escapeHtml(company);
  const companyLine = company
    ? `<p>We noted that you are with ${safeCompany}.</p>`
    : "";

  const emailPayload = {
    from: VOLANEA_FROM,
    to: recipient,
    replyTo: VOLANEA_REPLY_TO,
    subject: "We received your request",
    text: `Hi ${firstName},\n\nThanks for submitting ${formName}. Our team will be in touch shortly.${company ? ` We noted that you are with ${company}.` : ""}\n\nNorthstar Team`,
    html: `<p>Hi ${safeName},</p><p>Thanks for submitting ${escapeHtml(formName)}. Our team will be in touch shortly.</p>${companyLine}<p>Northstar Team</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": idempotencyKey
    },
    body: JSON.stringify(emailPayload)
  });

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

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

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

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

This code deliberately uses both text and html. Plain text gives recipients and mailbox clients a usable fallback, while HTML provides a readable branded confirmation. Keep the HTML simple: a short, clear acknowledgement is more dependable than a heavy marketing layout for a message that should arrive immediately after form submission.

The payload also uses Authorization: Bearer <secret-key>, Content-Type: application/json, and an Idempotency-Key when it calls Volanea. The relay—not Landingi and not the visitor’s browser—owns those headers.

For templates maintained in Volanea, replace the inline subject, text, and html with the documented template-based fields for your account and pass only the variables the template needs. That approach is often better when non-developers need to update copy without changing application code. Review the email API reference and setup guides before moving a production message to a stored template.

Protect the Volanea API key

The answer to “where does the Volanea API key live on the Landingi side?” should be: nowhere.

Landingi stores only two integration values needed to reach your relay:

the relay’s HTTPS request URL; and
a dedicated relay authentication token in the Webhook request headers.

The Volanea secret key lives only in the relay’s protected environment variables or secret manager. That boundary is important even if you trust everyone with access to your Landingi workspace. A sending key can create unexpected sending volume, damage domain reputation, expose customer data through email activity, and make a compromised configuration more expensive to clean up.

Do not put a Volanea secret key in any of these places:

custom JavaScript embedded on a Landingi page;
a hidden form field;
a URL query parameter;
front-end build-time environment variables that are shipped to visitors;
a public Git repository or copied code snippet;
an email template variable or page-level HTML block.

Use a separate relay token for Landingi. It should be scoped conceptually to one incoming webhook integration and have no ability to send email by itself. If it leaks, rotate it in both the Landingi Webhook settings and your relay secrets. If the Volanea key leaks, rotate or revoke it in Volanea, update the relay secret, review send activity, and treat the event as a credential incident.

Add defense beyond a shared header

A static header token is a useful first gate, but it is not the whole security model. A production relay should also:

accept requests only over HTTPS;
enforce a small request-body limit;
validate the recipient and expected field lengths;
rate-limit abusive traffic by route and, where appropriate, source IP;
reject unexpected methods and content types;
log a request correlation ID without logging unnecessary lead data;
restrict the email copy, sender, and destination logic to known rules.

If your environment supports a private network boundary, WAF, or application-level access policy, put the relay behind it where that does not block Landingi’s outbound request. Do not depend solely on IP allowlisting unless Landingi publishes and maintains a suitable outbound IP range for your use case.

Make the confirmation email useful and deliverable

The email is a transactional acknowledgement of an action. Treat it as part of the landing-page experience, not as an unrelated campaign.

A strong confirmation message answers four questions quickly:

Did you receive my submission?
What exactly did I ask for or sign up for?
What happens next and when?
How can I contact someone if I made a mistake?

For example, a demo-request confirmation might say that the request was received, name the product or topic requested, set an expected response window, and provide a reply-to address. A content-download confirmation should include the promised download link or explain where it is available. A webinar confirmation should restate the date, time zone, joining method, and cancellation path.

Use a sender address on a domain you have verified in Volanea, and make the visible sender identity recognizable. A verified domain alone does not guarantee inbox placement, but it is foundational. Keep the subject precise, avoid overusing all-caps language and urgency, and ensure the content actually matches what the visitor did.

Do not send sensitive data submitted through a Landingi form back to the visitor in full. A confirmation email is not the right place to echo passwords, payment data, identification documents, full support narratives, or confidential business information. If the form collects something sensitive, acknowledge receipt generically and route the sensitive data through your protected system.

Prevent duplicate sends from retries and repeat submissions

A webhook is not the same thing as a perfectly-once event bus. If Landingi submits a webhook and does not receive a timely successful response, an upstream retry is possible. A network failure can also occur after Volanea accepts an email but before your relay receives the response. Without duplicate protection, one form submission can produce two or more confirmation emails.

Volanea supports an Idempotency-Key header on the send request. The key must identify the underlying business event, not a single HTTP attempt. Reusing the same key on a retry tells the API that this is intended to be the same logical send.

The example uses a hash of normalized event data. That is adequate to demonstrate the mechanics, but it has an important trade-off: an identical form submission made later could produce the same hash. In a real deployment, use a shared idempotency store such as Redis or a database table:

derive a short-lived fingerprint from the normalized Landingi payload;
look up the fingerprint in the store;
if it exists, return the earlier accepted response without sending again;
if it does not exist, generate a new random Volanea idempotency key;
save the fingerprint, generated key, and provider result with a TTL appropriate to your form.

This approach distinguishes retry handling from a visitor intentionally submitting the form again weeks later. Choose the deduplication window based on the user experience. For a webinar registration, ten to thirty minutes may be reasonable. For a high-intent demo request, you may want a longer window plus a CRM-level duplicate policy. Do not silently deduplicate indefinitely without considering legitimate resubmissions.

A shared store is essential if your relay runs on multiple serverless instances. An in-memory JavaScript Map works only within a single warm process and will not reliably protect against concurrent requests or cold starts.

When this breaks: Landingi-to-relay troubleshooting

Most failures happen at one of three hops: the form never calls Landingi’s configured integration, Landingi cannot get a timely successful response from the relay, or the relay cannot send through Volanea. Debug them in that order.

The form submits but no email arrives

First, submit the published page yourself with a controlled test address. Confirm that the correct Form widget is being edited and that the active form has the Webhook integration saved. A form copied from another page, an A/B variant, a pop-up, or a lightbox can have different settings from the version you inspected.

Next, inspect relay logs. If there is no incoming request, verify the request URL, publish status, and selected POST method. If there is a request but the relay returns 422, the mapped email field is absent or invalid. If it returns 401, the X-Landingi-Token value in Landingi does not match the server-side secret.

Landingi retries and recipients receive duplicates

A webhook timeout is the common cause. Your relay should validate the request, send the email, store the result, and return a compact 200 response promptly. Do not place slow CRM enrichment, AI generation, spreadsheet writes, or long-running downstream jobs in the synchronous path before responding.

Use the idempotency pattern described above. Log the incoming payload fingerprint, the generated idempotency key, the Volanea response status, and a correlation ID. When an apparent duplicate is reported, you can then determine whether it was a Landingi retry, an intentional second form submission, or an application bug.

The relay times out even though Volanea is healthy

Check the relay’s hosting timeout, DNS resolution, regional network restrictions, and body-parser configuration. Ensure the endpoint accepts application/x-www-form-urlencoded data. A common integration mistake is writing a JSON-only handler and then treating Landingi’s query-string body as an empty object.

Also keep the response body tiny. The relay should return a success acknowledgement to Landingi, not wait for unrelated background work. If you need to enrich a contact, notify a sales tool, or launch a campaign, put those tasks on a queue after the core acknowledgement send is safely recorded.

Expected payload fields are missing

Landingi forwards the fields connected in the form’s Webhook configuration plus any request parameters you add. A field shown in another lead-management view, a value collected by an unrelated integration, or a UTM value that was never captured into a form field will not automatically be part of this webhook body.

Check the field mapping on the exact published form and test with a request inspector or relay logging in a non-production environment. Treat optional fields as optional in code. For example, do not fail a confirmation email because company was not supplied; only the recipient email should normally be mandatory.

Plan and feature availability can also create confusion when teams copy configurations between accounts. Landingi’s current pricing describes POST and Webhook among the Build plan’s automation and integration features, but product access and account limits can change. Verify the features available in the specific account before designing a flow around fields, editing controls, or lead-management behavior that your team cannot access.

Volanea returns an error

A 401 or 403 usually points to the Volanea credential or sender setup. Confirm that the relay has the current API key and that VOLANEA_FROM uses a verified sending domain. A 400-class response often means the mapped payload is invalid, such as a malformed recipient address or missing required content. A 429 or 5xx response calls for controlled retry behavior in your relay or queue, using the same idempotency key for the same logical send.

Do not automatically retry every 4xx error. Validation and authentication failures require a configuration or data fix. Retrying them only creates noise. Retry only transient conditions, use bounded exponential backoff, and alert someone when a lead confirmation cannot be sent after the retry policy is exhausted.

Use Zapier or Make when you need a no-code middle layer

A custom relay is the strongest option when key protection, deterministic validation, and duplicate control matter. But Landingi also supports Zapier and Make workflows, and either can be used as an intermediate layer when maintaining code is not practical.

The flow becomes:

Landingi form submission → Zapier or Make webhook/workflow → HTTP request to Volanea

This is useful for a lightweight internal-notification use case or a team that already manages automations in one of those platforms. Keep the same security principles: store the Volanea API key in the automation platform’s protected connection or secret configuration, not in a field that is sent from the browser; map only approved fields; and include an idempotency strategy if the platform supports a stable event identifier or datastore.

The trade-off is control. A custom relay can enforce your exact validation rules, retain a durable deduplication record, redact logs, and evolve alongside your product. An automation platform can be faster to launch but may have its own task limits, execution histories, retry semantics, and constraints on secret handling. Use the route that your team can operate confidently.

Test the full path before publishing a campaign

Treat this as an integration test, not just a form-design task. Test from the published landing page with a real mailbox and test both normal and malformed inputs.

Use this checklist:

Confirm the Landingi form maps email to the expected webhook field name.
Confirm the relay receives URL-encoded POST data.
Verify that an incorrect relay token receives 401 and does not call Volanea.
Verify that an invalid email receives 422 and does not call Volanea.
Submit a valid form and confirm the relay logs a successful Volanea response.
Confirm the message appears in the recipient inbox and uses the expected verified sender domain.
Submit the same payload twice during your duplicate-protection window and confirm the recipient does not receive duplicate mail.
Change an optional field such as company and confirm the email remains readable when it is blank.
Test the same configuration on every relevant landing page, pop-up, lightbox, and experiment variant.

Once the path is stable, review the economics of the volume you expect from paid campaigns, lead magnets, and confirmation sends. Volanea’s transactional email pricing can help you evaluate the sending plan against real form volume rather than an estimate based only on page traffic.

Conclusion

To send email from Landingi with Volanea, use Landingi’s form-level Webhook integration as the trigger, not an imaginary native plug-in. Map the form fields to an HTTPS relay, accept Landingi’s query-string POST body, validate the lead, and call Volanea’s POST /v1/send endpoint with a server-side Bearer key and an idempotency key.

This design keeps the key out of page-visible configuration, gives you a clean place to handle missing fields and retries, and turns a landing-page form submission into a reliable transactional email event. Start with one short confirmation email, log every hop, and add automation only after the core path is observable and safe.

FAQ

Can Landingi send directly to Volanea?

Landingi can send outbound POST requests through its Webhook integration, but its POST data is sent as a query string while Volanea’s send endpoint uses a JSON email payload. A small server-side relay is the recommended translation and security layer. It also keeps the Volanea secret key out of Landingi and the browser.

What Landingi event sends the email?

The trigger is a visitor submitting the configured Form widget. In the form’s Settings and Integrations tab, configure a Webhook with the POST method and connect the form fields to your relay’s expected parameter names.

Where should the Volanea API key be stored?

Store it only in server-side environment variables or a secret manager used by your relay. Do not store it in Landingi form fields, page JavaScript, a client-side environment variable, or a public URL. Landingi should hold only the relay URL and, optionally, a separate relay authentication token.

How do I stop duplicate confirmation emails?

Use Volanea’s Idempotency-Key header and keep a durable short-term deduplication record in Redis or a database. The key must represent the same underlying form submission across retries, not a newly generated value for every HTTP attempt.

Why is the email field missing in my webhook payload?

The field was likely not connected in the Webhook mapping for that exact form, variant, pop-up, or lightbox. Landingi sends the form fields and additional request parameters you configure; it does not automatically include every lead attribute available elsewhere in the account.

How to Send Email From Landingi With Volanea