How to Send Email from Lead Liaison with Volanea

Lead Liaison can identify the moment a prospect takes meaningful action; Volanea can deliver the message that should follow. This guide explains how to send email from Lead Liaison through Volanea without pretending there is a native marketplace app or one-click plugin.

The practical integration pattern is an automation-triggered outbound webhook from Lead Liaison to a server-side relay. That relay validates the request, maps Lead Liaison prospect and form data into an email payload, then calls the Volanea REST API. It keeps the Volanea API key off the browser and out of Lead Liaison merge fields, gives you a clear place to manage idempotency, and makes failures observable.

This is especially useful for operational messages that are triggered by marketing activity but should be delivered by your application email infrastructure: form-confirmation emails, consultation requests, sales-routing notices, resource-delivery emails, onboarding notices, and internal alerts.

What this integration does—and does not do

Lead Liaison is the event source in this setup. A Lead Liaison automation starts when a prospect reaches a defined condition, such as submitting a form or being created as a prospect. The automation sends an outbound HTTP request containing the relevant prospect data to infrastructure you control.

Volanea is the sending service. Your relay converts the incoming event into a REST request to Volanea, including the recipient, sender, subject, and email content. Volanea then handles the transactional delivery request through the sending domain and API credentials configured in your Volanea account.

There is an important boundary here: this is not a native Lead Liaison application, marketplace listing, or embedded Volanea connector. You are connecting two systems with a webhook and API workflow. That distinction matters because it determines where credentials live, how retries behave, who owns data transformation, and how you troubleshoot a failed email.

The recommended flow is:

1. A Lead Liaison prospect triggers an automation.
2. Lead Liaison posts a compact JSON event to your HTTPS relay endpoint.
3. The relay validates the request and required fields.
4. The relay derives a stable idempotency key from the Lead Liaison event.
5. The relay calls Volanea’s email endpoint with the mapped message payload.
6. The relay records the result and returns a fast success response to Lead Liaison.

For a production implementation, the relay should be a serverless function, backend route, queue worker ingress endpoint, or small integration service—not JavaScript embedded in a landing page.

Choose the Lead Liaison trigger deliberately

The best trigger for a first email is usually a form submission. It is specific, understandable to marketers, and naturally contains the contextual information needed to compose a useful message.

For example, imagine a prospect submits a “Request a Demo” form. In Lead Liaison, create an automation whose entry condition is the form-submission activity for that exact form. The action in that automation should be the outbound webhook or HTTP-post action, configured to send the prospect and form values to your relay endpoint.

A form-submission trigger is preferable to a generic prospect-update trigger for a confirmation email because prospect records can be updated for many unrelated reasons. A scoring change, enrichment update, page visit, CRM sync, or salesperson edit may all update a prospect. If each update can trigger email, you can easily create accidental duplicates.

Good trigger choices

Use the narrowest Lead Liaison event that expresses the business intent:

• Form submission: Send a receipt, resource link, demo-request confirmation, or follow-up message.
• Prospect created: Notify an internal sales mailbox that a new known prospect has appeared.
• Tag or segment entry: Send an operational message after a qualification rule is met.
• Lifecycle or stage change: Notify a team when a prospect becomes sales-ready, provided the stage is managed consistently.
• Appointment or event-related activity: Send a confirmation or internal coordination email when the underlying record contains the required details.

For this guide, the concrete trigger is a Lead Liaison form submission event for a form named Request a Demo. The automation posts the values captured from that submission, along with the prospect identity, to the relay.

Avoid using a broad activity trigger for the first version

A broad “prospect updated” style workflow sounds flexible, but it makes the integration harder to reason about. You must decide whether a change to every field should send email, whether a CRM synchronization should count, and how rapidly repeated updates should be collapsed.

Start with one form and one message type. Once you have logs, idempotency, and delivery behavior working, you can add more automation branches. This approach also makes it easier to identify whether a message originated in Lead Liaison, your relay, or Volanea.

Configure the outbound webhook in Lead Liaison

In the Lead Liaison automation associated with the form submission, add the platform’s outbound webhook or HTTP POST action. Point it at a dedicated HTTPS endpoint owned by your application, such as:

https://integrations.example.com/leadliaison/demo-request

Do not point the Lead Liaison action directly at a browser route, a static site, or a public client-side script. The receiving endpoint must execute server-side code because it will eventually use the Volanea API key.

Configure the webhook to send JSON, if the action supports a JSON request body. Keep the payload intentionally small. The relay does not need every Lead Liaison field, activity, or tracking attribute to send a confirmation email.

A practical body for the Request a Demo form-submission automation looks like this:

{
  "event_type": "form_submission",
  "event_id": "{{submission_id}}",
  "occurred_at": "{{submission_date}}",
  "form_name": "Request a Demo",
  "prospect": {
    "id": "{{prospect_id}}",
    "email": "{{email}}",
    "first_name": "{{first_name}}",
    "last_name": "{{last_name}}",
    "company": "{{company}}"
  },
  "form": {
    "demo_interest": "{{demo_interest}}",
    "message": "{{message}}"
  }
}

The merge-token syntax shown above is representative of the values you should insert through Lead Liaison’s automation editor. Use the exact token picker and field names available in your account rather than typing unverified token text by hand. Lead Liaison fields are often customized, and an account may label the same business concept differently—for example, Work Email, Email Address, or a custom Business Email field.

The important part is the resulting request shape. Your relay should receive a compact object containing:

• a stable event or submission identifier;
• a timestamp;
• the automation context, such as the form name;
• the prospect’s email address and name; and
• only the custom fields needed for the message.

If Lead Liaison’s webhook action only supports form-encoded fields rather than a raw JSON body in your account, use the same names as individual POST parameters and normalize them in the relay. Do not abandon the integration merely because the transport format differs; the email mapping logic remains the same.

Keep the Volanea API key on the server

The Volanea API key belongs in the relay’s secret manager or encrypted server-side environment configuration. It does not belong in Lead Liaison custom fields, a publicly readable page, browser JavaScript, URL query parameters, or a template that marketers can download and copy.

A safe deployment usually stores values similar to these as protected environment variables:

VOLANEA_API_KEY=...
LEAD_LIAISON_WEBHOOK_SECRET=...
VOLANEA_FROM_EMAIL=notifications@example.com
VOLANEA_FROM_NAME=Example Company

The relay reads VOLANEA_API_KEY at runtime and attaches it to the outgoing Volanea request. Lead Liaison never needs to know the Volanea credential. This is more than a security preference: a client-visible key can be harvested and used to send unauthorized mail from your account, consume your sending allowance, damage deliverability, or create a security incident.

Use a separate shared secret for the Lead Liaison-to-relay hop where possible. For example, configure a long random value as an HTTP header or include it in a server-side credential setting supported by your webhook configuration, then compare it in constant time at the relay. The secret for authenticating Lead Liaison should not be the same as the Volanea API key.

If your Lead Liaison webhook action cannot set a custom header or securely store an outbound secret, put an integration service such as Make or Zapier between Lead Liaison and your relay, or use a relay URL protected by an unguessable path plus additional server-side controls. An unguessable URL alone is not equivalent to request authentication, but it is better than exposing the Volanea credential in an automation payload.

For endpoint, authentication, and message-object details, keep your implementation aligned with the Volanea email API reference rather than treating a copied integration snippet as permanent documentation.

Map a Lead Liaison form submission into a Volanea email

Your relay is where Lead Liaison data becomes an email. It is also where you should validate input before any send request is made.

The mapping for a demo confirmation is straightforward:

Do not let the form choose from, the API key, arbitrary headers, or raw recipient lists. A public form can be submitted by anyone, and letting untrusted input control envelope-like email properties opens the door to abuse.

The following Node.js example shows the complete transformation. It assumes your server receives the JSON payload shown above and that Volanea’s REST sending endpoint is configured in the API client used by your application. Replace the endpoint and authentication header only if your current Volanea API reference specifies a different version or authentication format.

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

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

const required = (value, field) => {
  if (typeof value !== "string" || value.trim() === "") {
    throw new Error(`Missing required field: ${field}`);
  }
  return value.trim();
};

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

const safeEqual = (a, b) => {
  const left = Buffer.from(a || "");
  const right = Buffer.from(b || "");
  return left.length === right.length && crypto.timingSafeEqual(left, right);
};

app.post("/leadliaison/demo-request", async (req, res) => {
  // Authenticate Lead Liaison to your relay with a dedicated secret.
  if (!safeEqual(req.get("x-integration-secret"), process.env.LEAD_LIAISON_WEBHOOK_SECRET)) {
    return res.status(401).json({ error: "Unauthorized webhook" });
  }

  try {
    const eventId = required(req.body.event_id, "event_id");
    const email = required(req.body?.prospect?.email, "prospect.email");
    const firstName = req.body?.prospect?.first_name?.trim() || "there";
    const company = req.body?.prospect?.company?.trim() || "your company";
    const demoInterest = req.body?.form?.demo_interest?.trim() || "your request";

    // Replace this with Redis, Postgres, DynamoDB, or your queue's dedupe facility.
    // If eventId was already processed, return 200 without calling Volanea again.
    const alreadyProcessed = await hasProcessed(`leadliaison:${eventId}`);
    if (alreadyProcessed) {
      return res.status(200).json({ ok: true, duplicate: true });
    }

    const html = `
      <p>Hi ${escapeHtml(firstName)},</p>
      <p>Thanks for requesting a demo for ${escapeHtml(company)}.</p>
      <p>We received your interest in: <strong>${escapeHtml(demoInterest)}</strong>.</p>
      <p>Our team will be in touch shortly.</p>
    `;

    const text = [
      `Hi ${firstName},`,
      "",
      `Thanks for requesting a demo for ${company}.`,
      `We received your interest in: ${demoInterest}.`,
      "",
      "Our team will be in touch shortly."
    ].join("\n");

    const volaneaResponse = await fetch("https://api.volanea.com/v1/emails", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        from: {
          email: process.env.VOLANEA_FROM_EMAIL,
          name: process.env.VOLANEA_FROM_NAME
        },
        to: [{ email, name: firstName === "there" ? undefined : firstName }],
        subject: "We received your demo request",
        html,
        text,
        tags: [
          { name: "source", value: "leadliaison" },
          { name: "event", value: "form_submission" },
          { name: "form", value: "request_a_demo" }
        ]
      })
    });

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

    await markProcessed(`leadliaison:${eventId}`, {
      sentAt: new Date().toISOString(),
      volaneaResponse: responseBody
    });

    return res.status(200).json({ ok: true });
  } catch (error) {
    console.error("Lead Liaison integration error", error);
    return res.status(400).json({ error: error.message });
  }
});

The hasProcessed and markProcessed functions are intentionally left as storage adapters because the right implementation depends on your stack. A small integration may use a database table with a unique index on event_id; a larger implementation may use Redis with a time-to-live plus durable event logging.

The key behavior is not optional: mark an event as processed only after Volanea accepts the send request, and return a successful response for a known duplicate event. That is what turns retries into safe replays instead of duplicate confirmation emails.

Use an idempotency strategy before going live

Webhooks are generally delivered with at-least-once behavior. In plain language, Lead Liaison or an intermediary can retry a request if the first delivery appears to have failed. The original request may actually have reached your server and caused Volanea to accept the email, but the success response might have been delayed or lost.

Without idempotency, the retry sends the same email again.

Use the most stable submission or activity identifier Lead Liaison exposes as your primary key. If the automation payload cannot include a unique submission ID, construct a fallback key from multiple fields, such as prospect ID, form identifier, and normalized event timestamp. A fallback is less reliable than a genuine event ID because two legitimate submissions can happen close together.

A useful database record might include:

idempotency_key: leadliaison:submission:123456
prospect_id: 78910
form_name: Request a Demo
recipient: alex@example.com
volanea_message_id: provider response value
status: accepted
created_at: 2026-09-21T14:32:10Z

Keep this record long enough to cover the maximum retry window you expect, plus operational investigation time. For a confirmation email, retaining deduplication data for several days is often sensible. For business-critical messages, a durable event log is better than a short-lived cache.

When this breaks

A good integration anticipates the failure modes of this exact Lead Liaison-to-relay-to-Volanea hop. The most common issues are not exotic API problems; they are retries, timeouts, missing data, and assumptions that a field will always exist.

Lead Liaison retries and duplicate sends

If Lead Liaison does not receive a timely 2xx response from your relay, it may retry the webhook according to its delivery behavior or the behavior of any middleware in the path. A retry is appropriate from the sender’s perspective, but it becomes a duplicate-email risk if Volanea accepted the original request.

Mitigation: use the Lead Liaison submission or event ID as the idempotency key. Store it before returning success, and make repeated deliveries return 200 OK with a duplicate indicator in your internal logs. Do not rely on “the user probably will not submit twice”; real retries and legitimate repeat submissions are different cases.

Webhook timeout before the provider call finishes

If your relay waits for a slow downstream operation, Lead Liaison can time out even when the send later succeeds. A long-running template lookup, database lock, DNS issue, or provider latency can produce this pattern.

Mitigation: make the webhook endpoint fast. Validate the request, write a durable job or event record, return success, and send through Volanea asynchronously from a worker when message latency is not critical. If you do send synchronously, set conservative outbound timeouts and log enough data to determine whether Volanea accepted the request.

Missing prospect or form fields

Not every prospect record is complete. A form can omit an optional company field. A lead may have been created through a different capture path. Field availability can also vary with Lead Liaison configuration, permissions, enabled features, and the particular form being used.

Mitigation: classify fields before building the email:

• Required: recipient email and event ID. Reject or quarantine events missing these values.
• Optional: first name, company, product interest, message text. Use safe defaults.
• Sensitive: phone number, revenue, notes, tracking history, and internal qualification data. Do not put these into an email unless the recipient and purpose clearly justify it.

The example uses there and your company as safe fallbacks. In a real brand voice, you may prefer a less personalized version of the template when the first name is missing.

Invalid or unverified recipient addresses

A Lead Liaison field can contain a typo, a shared inbox, a placeholder, or an address collected without clear consent. Passing every string containing @ into your sending system is a poor long-term deliverability strategy.

Mitigation: validate basic formatting at the relay, honor your consent and suppression rules, and consider checking questionable addresses before high-value campaigns or workflows. For a quick pre-send check in operational tooling, use the email address verification tool. Verification is not a replacement for consent or suppression management, but it can help catch obvious bad inputs before they become bounces.

Sender domain is not ready in Volanea

The webhook can work perfectly while Volanea rejects or limits the message because the sender identity is not authorized or the sending domain has not completed DNS setup.

Mitigation: configure and verify the sending domain before enabling the Lead Liaison automation. Use a consistent From address owned by your organization, keep the subject line tied to the form action, and avoid changing sender identities dynamically from Lead Liaison fields.

A webhook endpoint is publicly reachable but not authenticated

A public webhook URL will eventually be discovered, guessed, leaked, or scanned. If an attacker can post arbitrary JSON to it and your relay sends email, they may be able to abuse your account.

Mitigation: verify a dedicated webhook secret, allow only expected methods and content types, rate-limit the route, validate schemas, and ensure untrusted form values cannot control sender, headers, recipient arrays, or arbitrary HTML.

Build email content for transactional expectations

A form-confirmation email should confirm an action, set a clear expectation, and give the recipient a legitimate way to identify why they received it. It should not quietly become a promotional newsletter.

For a demo-request confirmation, include:

• a plain-language acknowledgement that the request was received;
• the relevant topic or request details when useful;
• a realistic next step, such as when the team will respond;
• your company identity; and
• a plain-text alternative to the HTML body.

Keep the first version short. Long, image-heavy marketing content is more likely to be treated like a campaign and is harder to test across clients. The purpose of this integration is to connect a meaningful Lead Liaison action to a dependable application-style email—not to recreate a full campaign builder in webhook code.

Where a message is promotional rather than transactional, evaluate whether the audience has the right consent status and whether Lead Liaison’s campaign tools are a better fit. The same technical path can send either kind of email, but the operational and compliance expectations differ.

Test the full path with controlled data

Do not activate the automation for every live form submission until you have tested the whole chain. Create a test form, a test prospect, or a narrowly scoped automation condition that only matches an internal address.

Test these cases in order:

1. A complete submission with a valid internal recipient address.
2. A submission with no first name.
3. A submission with no company value.
4. A malformed email address.
5. The same event delivered twice.
6. A simulated Volanea API failure.
7. A relay timeout or temporary storage failure.

For each test, capture the Lead Liaison event ID, the relay request ID, the deduplication key, the Volanea response status, and the resulting provider message identifier when available. These identifiers let you answer the question that matters during an incident: “Was an email actually accepted for this exact Lead Liaison submission?”

Also test the rendered message in common mailbox providers. Data from a CRM or marketing automation platform often contains punctuation, ampersands, apostrophes, or pasted HTML. Escape untrusted text before including it in HTML, and always produce a clean text version.

Operational improvements after the first workflow

Once the basic confirmation email is reliable, the same architecture can support several useful workflows. Keep each event type explicit rather than building one giant webhook that guesses intent from whichever fields happen to be present.

You might add endpoints or event types for:

• internal sales alerts after high-intent form submissions;
• a resource-delivery email after a gated-content form is submitted;
• a handoff notification when a prospect enters a sales-qualified stage;
• an alert to an account manager when a known account re-engages; and
• a support or onboarding notice when a customer-related custom field changes.

For each new workflow, create a separate template and a separate idempotency namespace. leadliaison:demo-request:123 and leadliaison:resource-download:123 should not collide merely because they are associated with the same prospect.

Tagging Volanea sends with source and event metadata is also valuable. Tags such as source=leadliaison, event=form_submission, and form=request_a_demo make it easier to filter delivery events, identify a problematic workflow, and compare response behavior by automation.

Finally, monitor the cost and sending volume implications as you expand. An automation that fires on every record update can create far more messages than a form-specific workflow. Review transactional email sending plans and usage before moving a high-volume Lead Liaison process into production.

Conclusion

The dependable way to send email from Lead Liaison with Volanea is to treat Lead Liaison as the automation event source and Volanea as the email delivery layer, with a secure server-side relay in between. Start from a precise trigger such as a Request a Demo form submission, post only the fields you need, validate them at the relay, and use a stable submission ID to make retries safe.

Do not expose the Volanea API key in Lead Liaison fields or client-side code. Do not assume every prospect field will be available. Do not consider a webhook successful merely because the endpoint was called—log the final sending outcome and preserve enough event data to investigate it.

With those safeguards in place, you gain a flexible integration without a native plugin: Lead Liaison determines when an event matters, your application owns the business logic, and Volanea handles the actual email send.

FAQ

Can I send directly from Lead Liaison to Volanea without a relay?

Only do so if your Lead Liaison webhook configuration can securely send the authentication format required by Volanea without exposing the API key. In most production setups, a relay is the safer choice because it protects credentials, validates input, handles idempotency, and gives you better logs.

What Lead Liaison event should trigger the email?

For a confirmation message, use the automation condition tied to the specific form submission that represents the request. It is more reliable than a broad prospect-update condition, which can fire for unrelated updates.

How do I prevent duplicate emails when Lead Liaison retries a webhook?

Include the most stable submission or event identifier in the webhook payload. Store it as a unique idempotency key in your relay. If the same event arrives again, return success without sending another Volanea email.

What happens if the prospect does not have a first name or company value?

Treat those fields as optional. Use a neutral greeting and omit or replace missing context. Email address and a stable event ID should be the core required fields for a basic confirmation workflow.

Where should I store the Volanea API key?

Store it only in server-side encrypted configuration, such as a secret manager or protected environment variable used by your relay. Never put it in a Lead Liaison custom field, a public webpage, browser code, or a webhook URL.