How to Send Email from Personizely with Volanea

Personizely can capture a visitor’s details at the moment they submit a form, while Volanea can deliver the email that should follow. This guide explains how to send email from Personizely without exposing a sending key in browser code or pretending there is a native Personizely app for Volanea.

The practical architecture is simple: a Personizely form submission triggers its Webhook integration, the webhook reaches an endpoint you control, and that endpoint validates and maps the lead data before calling Volanea’s REST email API. The extra relay is important. It is where you can keep credentials private, reject malformed requests, prevent duplicate messages, and make sound decisions about consent.

What this integration does—and does not do

Personizely is a website conversion and personalization product. Its forms can collect lead data from visitors, including an email address and any fields that you add to the form. A completed Personizely form is the concrete event that starts this integration: a visitor submits the form.

Volanea is the delivery layer. The relay turns the form-submission data into one transactional email request, such as a welcome email, a requested resource, an account-interest acknowledgement, or a handoff notification to an internal team.

This is not a marketplace installation. Volanea does not provide a native Personizely listing, embedded app, or one-click connector. The supported pattern is an outbound HTTP webhook from Personizely to a server-side endpoint, followed by a REST call from that endpoint to Volanea.

That distinction changes how you should think about the connection:

• Personizely owns the visitor interaction and the form-submit event.
• Your relay owns validation, authentication, consent checks, duplicate protection, and message selection.
• Volanea owns the actual email submission and delivery infrastructure.
• The browser should never receive, store, or send with your Volanea API key.

This approach is modestly more technical than connecting two apps in a marketplace, but it is more controllable. It also lets you evolve the email logic without rebuilding a live popup or form campaign every time your welcome copy changes.

The Personizely trigger: a form submission

Build the flow around a Personizely form that captures an email address. The trigger is not merely that a popup was displayed or that a visitor viewed a campaign. It is the successful form submission that creates usable lead data and should be treated as the start of an email workflow.

Before connecting a webhook, decide which form should trigger the send. A newsletter capture form, an ebook-request form, a waitlist form, and a quote-request form do not necessarily deserve the same email. Using a distinct form or an explicit hidden field for the message type makes downstream handling much safer.

Define the minimum form data

At minimum, collect an email field. For a more personal acknowledgement, collect first name as well. If the form is tied to a specific offer, include a stable value that identifies the offer or campaign; do not infer it from the popup’s visual title later.

A useful conceptual record looks like this:

{
  "email": "ada@example.com",
  "first_name": "Ada",
  "lead_source": "personizely",
  "message_type": "ebook-request",
  "consent_email": true
}

The names in your Personizely form may differ. Your relay should map the actual submitted field names deliberately rather than assuming every campaign uses first_name or consent_email.

Send only after an explicit submission

Avoid triggering an email from a display, page view, exit intent, or form start. Those events are useful for onsite conversion analysis, but they do not establish that a visitor supplied a deliverable address or requested a follow-up.

For marketing-oriented email, the form should clearly explain what the visitor is asking for and, where applicable, capture a consent choice. A resource delivery email may be expected immediately after a request; a promotional sequence may require a different consent standard depending on the recipient’s location and your use case. Your relay is a good place to enforce that distinction.

Configure Personizely to post to your relay

Use Personizely’s Webhook integration for the form or campaign that collects the lead. The webhook destination must be an HTTPS URL that your application controls, for example:

https://hooks.example.com/personizely/lead

The destination is your relay, not Volanea’s email endpoint. Do not point Personizely directly at the sending API just because the request appears simple. A direct connection would require putting the Volanea authorization credential into a third-party configuration and would leave you with limited control over validation and duplicate sends.

The webhook request body should include the submitted email and any other data your relay needs. Use JSON when the webhook configuration permits choosing a content type. The following is the payload shape this guide expects the Personizely webhook to deliver to the relay:

{
  "email": "ada@example.com",
  "first_name": "Ada",
  "message_type": "ebook-request",
  "consent_email": true,
  "form_id": "ebook-popup",
  "submitted_at": "2026-09-23T14:20:00.000Z"
}

The important part is not the example values; it is that your configured form-field names and your server code agree. If your Personizely form exports a field as Email, email_address, or a nested value rather than email, update the mapper below. Do not “fix” this only in a template: normalization belongs in server-side code where it can be tested.

Keep a test endpoint separate

Create a development webhook URL before connecting a production campaign. Submit the Personizely form yourself with a controlled test address, inspect the exact JSON your receiver logs, then write mappings from that captured request.

This matters because form configurations change. A marketer may rename a field, publish a localized form with fewer fields, or clone an older campaign whose consent field has a different key. Treat the webhook payload as an external contract: inspect it, validate it, and version it where possible.

Why the Volanea API key belongs only on the server

Your Volanea API key authenticates sending activity. Anyone who obtains it may be able to submit mail through your account, consume your allowance, damage sending reputation, or probe your setup. It must not appear in Personizely-facing JavaScript, a page-source variable, a public webhook URL, client-side tag-manager code, or an email template.

Store the key in the secret store or environment configuration for the service that hosts your relay. A conventional environment variable is:

VOLANEA_API_KEY=replace-with-a-server-side-secret

The relay reads that variable at runtime and adds it as an authorization header only while making the server-to-server call to Volanea. Personizely receives no Volanea credential at all. Its only job is to post lead data to your endpoint.

Use a second secret to authenticate Personizely to the relay. One straightforward option is a long random value in a request header, such as X-Webhook-Secret. If your Personizely webhook configuration cannot attach a private header, include an unguessable secret in the endpoint path and put an additional layer such as IP controls, a gateway, or a signed intermediary in front of it. A URL secret is better than an openly unauthenticated receiver, but a header-based secret is preferable because it is less likely to land in logs.

Rotate both secrets independently. Rotating a Personizely webhook secret should not require rotating your Volanea sending credential, and rotating a Volanea key should not require editing the form campaign.

For endpoint and authentication details in your account, consult the email API setup guides before deploying. Keep the relay configuration outside source control, and ensure logs redact authorization headers.

Map the webhook payload to a Volanea email request

The relay should perform four jobs before it asks Volanea to send anything:

1. Authenticate the incoming webhook.
2. Validate and normalize the submitted fields.
3. Decide whether this form submission is eligible for an email.
4. Construct one explicit Volanea request with a stable idempotency key.

Here is an Express example that receives the JSON shape shown above. It maps the Personizely fields to a welcome/resource-delivery email and makes the Volanea REST request server-side.

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

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

const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY;
const PERSONIZELY_WEBHOOK_SECRET = process.env.PERSONIZELY_WEBHOOK_SECRET;
const FROM = "Example Team <hello@example.com>";

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

app.post("/personizely/lead", async (req, res) => {
  // Keep the Personizely-to-relay credential separate from the Volanea key.
  if (req.get("X-Webhook-Secret") !== PERSONIZELY_WEBHOOK_SECRET) {
    return res.status(401).json({ error: "unauthorized webhook" });
  }

  const {
    email,
    first_name: firstName = "there",
    message_type: messageType,
    consent_email: consentEmail,
    form_id: formId = "unknown",
    submitted_at: submittedAt = new Date().toISOString()
  } = req.body;

  if (!validEmail(email)) {
    return res.status(422).json({ error: "missing or invalid email" });
  }

  // Only this explicitly consented resource request is eligible in this example.
  if (messageType !== "ebook-request" || consentEmail !== true) {
    return res.status(204).end();
  }

  const normalizedEmail = email.trim().toLowerCase();
  const safeName = String(firstName).trim().slice(0, 80) || "there";

  // Use a submission identifier supplied by Personizely if available.
  // This fallback is deterministic for the same lead/form/time combination.
  const idempotencyKey = crypto
    .createHash("sha256")
    .update(`${normalizedEmail}|${formId}|${submittedAt}|${messageType}`)
    .digest("hex");

  const volaneaPayload = {
    from: FROM,
    to: [normalizedEmail],
    subject: "Your requested guide",
    html: `<p>Hi ${safeName},</p><p>Thanks for requesting the guide.</p><p><a href="https://example.com/guide">Download it here</a>.</p>`,
    text: `Hi ${safeName},\n\nThanks for requesting the guide. Download it: https://example.com/guide`
  };

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

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

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

app.listen(process.env.PORT || 3000);

The mapping is intentional:

Do not insert raw form values into HTML as the short example does for a production system. Escape HTML-special characters, limit field lengths, and avoid accepting arbitrary HTML, URLs, sender identities, subjects, or recipient lists from a public form submission. The visitor can control form input; the relay must control email behavior.

Design the email as a transactional response, not a loose blast

A Personizely form is often the start of a high-intent moment. The visitor asked for something, joined a list, or expressed interest. The first email should make that exchange clear and timely.

For an ebook request, the email should state what was requested and provide the resource. For a waitlist form, acknowledge the waitlist rather than implying an account exists. For a sales-interest form, confirm that the request was received and set a realistic expectation for the next step.

Choose sender identity carefully

Use a verified domain and a recognizable sender name. The from address in the relay must be one you have authorized for sending, not an address that came from the Personizely form. A form visitor’s address belongs in to, never in from.

Set reply handling intentionally. If a recipient replies to a resource request or sales enquiry, ensure the reply reaches a monitored inbox or an appropriate support workflow. A no-reply sender may be operationally convenient but is often a poor experience for a lead who has just asked a question.

Keep templates controlled

Store template selection in your service, not in a public form field. A good pattern is a server-side map such as ebook-request to a specific subject, text body, HTML body, and approved resource URL. This makes it impossible for a manipulated request to turn your endpoint into a generic email sender.

If you need multiple locales, map a validated locale code to a known template. Do not accept a full subject line or HTML block from the webhook payload. The only user-generated values should be narrowly scoped merge data after validation and output encoding.

Add idempotency before you go live

Webhooks are generally at-least-once delivery mechanisms. In practical terms, that means the same Personizely submission can reach your endpoint more than once. A network interruption can leave Personizely unsure whether the receiver accepted the request, which may lead to a retry. Your endpoint can also fail after Volanea accepted a send but before it returned a response to Personizely.

Without duplicate protection, one lead can receive two or more identical emails. That is particularly damaging for welcome messages, coupon emails, and resource deliveries because it makes the system look unreliable.

The Idempotency-Key header in the example creates a deterministic identifier. For production, improve it by using a true submission or event identifier supplied in the incoming payload whenever one exists. Store that key in your own database with statuses such as received, sending, sent, and failed.

A robust sequence looks like this:

1. Receive the Personizely form-submission webhook.
2. Authenticate and validate it.
3. Atomically record the event key as in progress.
4. Return a duplicate-safe response immediately if the key was already sent.
5. Submit the Volanea request using the same key.
6. Mark the record sent only after a successful provider response.
7. Return a successful HTTP response to Personizely.

Do not use only the recipient address as a deduplication key. A person may legitimately submit two different forms or request two separate resources. Include a submission ID, form identifier, message type, or a carefully chosen time boundary.

When this breaks

Failures at this integration boundary are usually ordinary operational issues, not mysterious email failures. Plan for them explicitly.

Personizely retries cause duplicate sends

If the webhook receiver does not return a successful response in time, Personizely may retry the event. A retry can also happen after an intermittent network failure. Your relay must assume this is possible and must make duplicate delivery harmless through idempotency.

Persist the event key before calling Volanea, not after. Otherwise two simultaneous retries can both see no prior record and each send a message. Database uniqueness constraints or a transactional lock are safer than an in-memory Set, which disappears during a deployment or restart.

Webhook timeouts create ambiguity

Do not make the webhook handler do slow enrichment calls, PDF generation, CRM searches, or multiple downstream API calls before replying. The longer the handler runs, the more likely a timeout becomes.

For high-volume or multi-step workflows, authenticate and enqueue the normalized event, then return a 2xx response quickly. A worker can call Volanea afterward. The queue should retain the idempotency key so a worker retry does not create a second email.

Payload fields are absent or changed

Not every Personizely plan, form configuration, or campaign variant necessarily exposes the same lead data. A form without a first-name field will not produce a first name. A consent checkbox may not be present in an older campaign. A cloned form can use a different field key.

Treat optional fields as optional, provide safe defaults, and fail closed for fields that are required for compliance or routing. In the example, missing first_name becomes “there,” while a missing valid email produces a 422 response and missing consent prevents the send. Log the field names received, but avoid logging complete addresses or sensitive answers unnecessarily.

Volanea rejects the request

A non-2xx Volanea response usually means the relay should not tell Personizely that processing succeeded. Record the response status and a redacted body, then decide whether the failure is retryable. Authentication, invalid sender, and malformed payload problems require configuration fixes; temporary upstream errors may be queued for retry with exponential backoff.

A recipient-level issue is different from a webhook failure. If Volanea later reports a hard bounce or suppression, do not keep triggering the same message to that address after every form submission. Maintain a suppression-aware contact process and consider checking addresses before a costly follow-up with the email address verification tool.

Test the complete path safely

Test the form in a staging campaign or with targeting that only you can see. Submit a real inbox you control, then check each boundary: Personizely submission, relay receipt, outbound Volanea request, inbox delivery, and reply behavior.

Use this pre-launch checklist:

• The Personizely form visibly tells visitors what email they will receive.
• The webhook URL is HTTPS and protected with a secret or equivalent control.
• The Volanea API key exists only in server-side secret storage.
• The receiver rejects missing or invalid recipient addresses.
• The receiver uses an idempotency record that survives restarts.
• The sender domain and From address are authorized for Volanea sending.
• HTML escaping and text alternatives are present.
• Logs redact authorization headers and minimize personal data.
• A monitoring alert exists for repeated 4xx or 5xx responses.

Also test negative cases. Submit the form without an optional name, send an intentionally malformed request to the receiver, replay the same payload, and temporarily use an invalid sender in a non-production environment. The system should demonstrate predictable behavior: invalid data is rejected, repeated events do not duplicate email, and provider errors are visible to operators.

Alternatives when a relay is not available

A lightweight serverless function is usually the best relay. Cloudflare Workers, AWS Lambda, Vercel Functions, Netlify Functions, or a route in your existing application can all perform the same basic role. Choose the environment your team can monitor and deploy safely.

If you cannot host an HTTP endpoint, a no-code middleware product can receive a Personizely-triggered event and make a custom HTTP request to Volanea. That can be useful for early validation, but apply the same principles: store the Volanea credential in the middleware’s protected connection or secret facility, map fields explicitly, and add a duplicate strategy. Do not put a bearer token in a browser-visible webhook URL or query string.

A middleware flow is often weaker for idempotency and long-term auditing than a small owned relay. It may also have task limits, timeout constraints, and less control over retries. For a one-off internal notification it can be adequate; for every new lead or a customer-facing delivery email, server-side code is normally the sturdier option.

Operational metrics worth watching

The integration is healthy only when both the data flow and the email outcome are healthy. Track webhook receipt count, authenticated request count, validation failures, duplicates suppressed, Volanea acceptance rate, provider errors, and the time from form submission to acceptance.

Separate conversion metrics from delivery metrics. A high Personizely form-submit rate does not mean messages are reaching inboxes. Conversely, a low delivery rate may indicate malformed addresses, an unverified sender, suppression, or a bug in your mapper rather than a problem with the form itself.

Review sudden changes in form_id, message type, or missing fields. Those often reveal a published campaign change before it becomes a broad customer-impact issue. Preserve enough event metadata to diagnose a problem, while minimizing retention of visitor data and honoring your privacy obligations.

Conclusion

To send email from Personizely with Volanea, use the Personizely form-submission webhook as the trigger and route it through a protected server-side relay. The relay validates the submitted lead data, applies consent and template rules, derives an idempotency key, and makes the authenticated Volanea REST request.

That design avoids exposing your sending credential, prevents common retry-driven duplicates, and gives you a reliable place to manage changing form fields. Start with one clear form event and one narrowly defined email, test replay and timeout behavior, then expand the mapping only when the first path is observable and dependable.

FAQ

Does Volanea have a native Personizely integration?

No. Use Personizely’s outbound webhook capability with a server-side relay that calls Volanea’s REST API. This is preferable to trying to expose an email API credential in a client-side or public configuration.

What triggers the Volanea email?

A visitor submitting a Personizely form triggers the webhook. The relay should then validate the submitted email, consent state, and message type before it submits an email to Volanea.

Can I send directly from a Personizely webhook to Volanea?

Do not send directly if it requires placing the Volanea API key in the Personizely configuration. Send to an endpoint you control first, where the Volanea key is held as a server-side secret and the request can be authenticated and deduplicated.

How do I stop duplicate welcome emails?

Use a persistent idempotency key based on a Personizely submission identifier where available. Record the key before sending, reuse it on the Volanea request, and return a successful duplicate-safe response when the same webhook is delivered again.

What happens if first name or consent is missing?

Make optional personalization fields safe by using defaults, but fail closed for data required by your policy. A missing first name can become a generic greeting; missing consent should prevent a marketing-oriented message from being sent.