How to Send Email From LiveChat With Volanea

Send email from LiveChat without copying conversations into another tool manually. The reliable approach is to let LiveChat notify a server-side endpoint about a chat event, then have that endpoint validate the request, decide whether an email is warranted, and call Volanea’s email API.

There is one important limitation to make clear at the outset: Volanea does not provide a native LiveChat Marketplace app or a one-click LiveChat plugin. That is not a blocker, but it changes the architecture. A production integration needs either a small middleware service you control or an automation platform such as Zapier or Make. For teams that need control over message content, recipient consent, retries, and duplicate prevention, middleware is usually the better option.

What the LiveChat-to-email flow looks like

The direct integration has three distinct hops:

1. A visitor or agent creates a new event in a LiveChat thread, such as a message.
2. LiveChat delivers an event_created webhook to your HTTPS endpoint.
3. Your endpoint validates and filters the event, then sends an email through Volanea’s REST API.

The concrete LiveChat trigger in this guide is the event_created webhook action. LiveChat emits it when a new event is created in a chat thread. A visitor text message is represented as an event whose type is message and whose text contains the message body. That makes it useful for practical cases such as a lead request, a request for a transcript, an after-hours escalation, or a notification to a sales inbox.

This distinction matters. A chat is not itself an email event, and not every message should become email. A robust integration makes an explicit decision about which events qualify before it sends anything. For example, you may email a sales team only when a visitor message contains an intent such as “book a demo,” or send a follow-up only after a chat has been deactivated and the visitor has consented to receive email.

LiveChat documents webhook actions and payloads in its Configuration API webhook documentation. The webhook is created for a LiveChat app or integration with the appropriate authorization, rather than by adding a Volanea app from a marketplace.

Why middleware is required

A LiveChat webhook is an HTTP notification. It is not an email templating environment, and it is not a safe location to put a second vendor’s long-lived API credential. The URL you register with LiveChat should point to an endpoint that you operate, such as a serverless function, container service, edge worker, or application backend.

That middleware does five jobs that are difficult or unsafe to do in a direct browser-based setup:

• It verifies that the inbound request is genuinely associated with your LiveChat webhook configuration.
• It interprets LiveChat’s event payload and ignores events that do not meet your business rule.
• It enriches the event with approved data from your CRM or application, where needed.
• It stores an idempotency record before sending, so delivery retries do not create duplicate emails.
• It keeps the Volanea API key in a server-side secret store and makes the REST request.

Do not place the Volanea API key in a chat widget script, a public web page, a mobile application bundle, a LiveChat message, or a URL query parameter. Anything delivered to a visitor’s browser is client-visible and must be treated as public. A leaked sending key can be used to send unauthorized mail, damage domain reputation, and create costly incident response work.

Instead, keep the key as a server-side environment variable such as VOLANEA_API_KEY, in your hosting provider’s encrypted secrets manager. LiveChat only needs the webhook destination URL and the webhook secret used to authenticate the inbound notification. The Volanea key never belongs in LiveChat’s visitor-facing configuration.

Configure the event_created webhook in LiveChat

LiveChat’s webhook model is part of its developer platform and Configuration API. In a typical implementation, an authorized backend or installation flow creates a webhook that points to your endpoint. The webhook action for this guide is event_created.

Your endpoint must be publicly reachable over HTTPS. During development, use a secure tunnel only for testing, then replace it with a stable production URL before enabling the workflow for real conversations. A webhook endpoint should return a successful response quickly; do not wait for a slow enrichment request, large database operation, or email provider response if your architecture can avoid it.

The webhook registration conceptually needs these values:

• Action: event_created
• URL: your HTTPS receiver, for example https://automation.example.com/livechat/event-created
• Secret key: a high-entropy secret that your receiver uses to verify the inbound webhook

LiveChat’s Configuration API includes a create_webhook action. Because API authorization and installation details vary by the type of LiveChat app you are building, use the current LiveChat developer documentation for the exact authorization flow, scopes, and app configuration. Do not hard-code an agent’s personal access token into deployed code.

A good deployment pattern is to create the webhook during app installation, save the returned webhook ID, and delete or replace it during uninstallation or endpoint rotation. This prevents abandoned webhook registrations from continuing to call an endpoint after an integration has changed hands.

Choose a narrowly defined send rule

Before writing code, define what causes an email. “Every visitor message” is usually too broad and can surprise both staff and visitors. A better rule uses fields that are present in the event and context known by your application.

For example, a sales-alert rule might be:

• Accept only event.type === "message".
• Accept only messages authored by visitors, not agents or bots.
• Require non-empty event.text.
• Match a deliberate command, form-like phrase, or an internal property set by another workflow.
• Send only one alert per chat thread during a defined interval.

For a customer follow-up, do not infer marketing permission from the fact that someone started a chat. Use consent collected separately and retain an auditable record of when and how it was granted. Operational messages and promotional campaigns have different compliance and expectation requirements.

Understand the LiveChat webhook payload

The event_created webhook gives the receiving service identifiers for the chat and thread plus the new event. For a text message, the important portion resembles the following shape:

{
  "chat_id": "PJ0MRSHTDG",
  "thread_id": "K600PKZON8",
  "event": {
    "id": "Q20N9CKRX2",
    "created_at": "2026-10-08T12:34:56.000000+00:00",
    "author_id": "b7eff798-f8df-4364-8059-649c35c9ed0c",
    "recipients": "all",
    "type": "message",
    "text": "Please send me the enterprise pricing details."
  }
}

Treat this as an event notification, not as a complete customer record. The webhook payload may not contain a verified email address, a person’s name, a marketing-consent state, or every custom property your email template needs. If your workflow needs those values, look them up in your own application or retrieve chat details through the appropriate LiveChat API after receiving the webhook.

This is also why using the visitor’s message text as an email recipient is never appropriate. A message is content, not identity. Recipients should come from a trusted source: a monitored internal mailbox for an alert, a verified account email in your database, or a visitor email collected with explicit consent and validated before use.

Map fields deliberately

For an internal notification email, the mapping is straightforward:

Do not interpolate event.text directly into HTML. Visitor content can contain markup-like characters or malicious links. Escape it before inserting it into HTML, and retain a plain-text alternative for mail clients that do not render HTML.

Working webhook receiver and Volanea API call

The example below uses Node.js with Express. It receives a LiveChat event_created payload, filters it to visitor-like text messages, prevents duplicates using event.id, escapes the content, and sends a notification through Volanea.

The exact sender address must be from a domain you have configured and authenticated for sending. Set ALERT_RECIPIENT to an internal mailbox that has a reason to receive these alerts. For Volanea’s current endpoint, request schema, sender-domain setup, and authentication requirements, consult the email API reference and setup guides before deploying.

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

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

const {
  LIVECHAT_WEBHOOK_SECRET,
  VOLANEA_API_KEY,
  VOLANEA_API_URL = "https://api.volanea.com/v1/emails",
  ALERT_RECIPIENT,
  MAIL_FROM = "LiveChat alerts <alerts@mail.example.com>"
} = process.env;

// Replace with Redis, Postgres, or another durable shared store in production.
// A process-local Set is shown only to make the idempotency behavior visible.
const processedEventIds = new Set();

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

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

app.post("/livechat/event-created", async (req, res) => {
  // Check the webhook secret using the mechanism configured for your LiveChat webhook.
  // Keep this secret server-side; never expose it in widget JavaScript.
  const suppliedSecret = req.get("x-livechat-webhook-secret") || "";
  if (!safeEqual(suppliedSecret, LIVECHAT_WEBHOOK_SECRET)) {
    return res.status(401).json({ error: "Unauthorized webhook" });
  }

  const { chat_id, thread_id, event } = req.body || {};

  // This integration sends an internal notification for text messages only.
  if (!event || event.type !== "message" || typeof event.text !== "string") {
    return res.status(204).end();
  }

  const message = event.text.trim();
  if (!message || !event.id) {
    return res.status(204).end();
  }

  // Example business rule: alert only on a deliberate lead phrase.
  if (!/enterprise pricing|book a demo|sales/i.test(message)) {
    return res.status(204).end();
  }

  // Idempotency must be durable and atomic in production.
  if (processedEventIds.has(event.id)) {
    return res.status(200).json({ duplicate: true });
  }
  processedEventIds.add(event.id);

  const escapedMessage = escapeHtml(message);
  const text = [
    "A LiveChat visitor requested follow-up.",
    `Chat: ${chat_id}`,
    `Thread: ${thread_id}`,
    `Event: ${event.id}`,
    `Created: ${event.created_at || "unknown"}`,
    "",
    message
  ].join("\n");

  const emailPayload = {
    from: MAIL_FROM,
    to: [ALERT_RECIPIENT],
    subject: `LiveChat sales request (${chat_id})`,
    text,
    html: `
      <p><strong>A LiveChat visitor requested follow-up.</strong></p>
      <ul>
        <li>Chat: ${escapeHtml(chat_id)}</li>
        <li>Thread: ${escapeHtml(thread_id)}</li>
        <li>Event: ${escapeHtml(event.id)}</li>
        <li>Created: ${escapeHtml(event.created_at || "unknown")}</li>
      </ul>
      <p>${escapedMessage.replaceAll("\n", "<br>")}</p>
    `
  };

  const response = await fetch(VOLANEA_API_URL, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Idempotency-Key": `livechat-event-${event.id}`
    },
    body: JSON.stringify(emailPayload)
  });

  if (!response.ok) {
    // In production, remove the event ID only after recording the failure safely,
    // then retry through a queue rather than relying on an in-memory Set.
    processedEventIds.delete(event.id);
    const detail = await response.text();
    console.error("Volanea send failed", response.status, detail);
    return res.status(502).json({ error: "Email provider request failed" });
  }

  return res.status(200).json({ sent: true, event_id: event.id });
});

app.listen(3000, () => console.log("Listening on port 3000"));

There are two separate forms of authentication in that example. The LiveChat webhook secret authenticates the inbound hop from LiveChat to your service. The Volanea API key authenticates the outbound hop from your service to Volanea. Keep both in a secret manager, rotate them when staff or systems change, and avoid logging either one.

If your LiveChat webhook authentication configuration uses a signature format rather than the illustrative header shown above, implement the verification exactly as LiveChat specifies. Do not replace signature verification with a simple source-IP check. IP ranges can change, and a cryptographic secret or signature is the control designed for webhook authenticity.

Make the send asynchronous and retry-safe

A webhook handler sits between two systems that can retry independently. That is the central reliability challenge in this integration.

LiveChat may retry a delivery when it does not receive a timely successful HTTP response. Your own service may retry a failed Volanea request. A network failure can occur after Volanea accepts the request but before your service receives the response. Without idempotency, one visitor message can generate two or more emails.

Use the LiveChat event.id as the stable deduplication key. Store it in a durable database with a unique constraint before or while submitting a send job. The simplest table needs fields such as event_id, chat_id, status, provider_message_id, attempt_count, and timestamps. A unique index on event_id means that concurrent webhook attempts cannot both create a send job.

A durable queue improves the response path:

1. Receive and authenticate the LiveChat webhook.
2. Validate the event and create a unique send-job row keyed by event.id.
3. Return a 2xx response to LiveChat promptly.
4. Let a worker send the Volanea request and record the result.
5. Retry transient provider or network failures with bounded exponential backoff.

This design is more dependable than treating the incoming webhook request as the only place where an email can be sent. It also gives your team a record of what happened when someone asks why a notification was late or missing.

When this breaks

Every integration eventually encounters malformed data, timeouts, credential rotation, or a change in a source system. Plan for these LiveChat-to-Volanea failure modes rather than discovering them after a missed lead.

LiveChat retries create duplicate sends

If your endpoint times out or returns a non-success status after the email has already been accepted, LiveChat can attempt delivery again. A second request contains the same event identity. Deduplicate with event.id, use a database-level uniqueness constraint, and pass the same idempotency value downstream when Volanea supports idempotency for the endpoint you use.

Do not use only chat_id as the key. One chat can contain many messages, so it would suppress legitimate later events. Conversely, do not use the current timestamp; it changes on every retry and defeats deduplication.

Your webhook endpoint exceeds the timeout

Webhook systems expect a quick acknowledgement. Long-running work—CRM lookups, AI classification, attachment retrieval, or waiting on a provider response—can cause timeouts. LiveChat then has no way to know whether your work succeeded and may retry.

Acknowledge after you have durably accepted the job, then do the slow work asynchronously. Monitor latency at the receiver separately from email delivery latency. If you must process synchronously at first, set strict internal timeouts and ensure the duplicate guard is written before the outbound call.

Expected fields are not present

A message event commonly has event.text, but not every LiveChat event is a text message. Rich messages, system events, files, chat property changes, and events created by agents or bots can have different fields. Some customer details or custom properties may require a follow-up API lookup, and available data can depend on your LiveChat configuration, permissions, and feature use.

Defend against absent fields explicitly. Require event.type === "message" and a string event.text before using the content. Use fallbacks for optional timestamps. If a recipient address comes from a LiveChat property, reject missing or invalid values rather than attempting a send with an empty or guessed address.

The API key or sending domain is not ready

A 401 or 403 response usually indicates an authentication or authorization issue; a sender-related validation response can indicate that the from domain has not been configured correctly. Keep sending configuration separate from application code, use a sender address on an authenticated domain, and alert on repeated provider failures.

Do not “solve” a sender-domain problem by switching to a free personal address. That can reduce alignment, harm deliverability, and make operational mail harder to audit. Authenticate the domain you intend to use for the workflow and keep transactional alerts on a clearly owned sender identity.

Email content becomes unsafe or unhelpful

Visitor-provided text can include HTML, URLs, misleading instructions, or sensitive information. Escape text in HTML email, include a plain-text part, and keep the notification concise. If teams reply to alerts, give them a secure internal route to the original conversation rather than encouraging them to reply to an unmonitored sender address.

For highly sensitive chats, consider sending a minimal alert that says a conversation requires attention, with an internal chat identifier, instead of copying the entire message into email. Email is often forwarded and retained longer than the chat system.

Test the integration before enabling it

Start with a dedicated test group, test inbox, and test sender domain. Make the business rule easy to trigger in a controlled environment, then verify both the happy path and the failure path.

A practical test checklist includes:

• Send a normal visitor text message that matches the trigger rule and confirm exactly one email arrives.
• Send a message that does not match and confirm no email is sent.
• Deliver the same webhook payload twice and confirm the second delivery is marked as a duplicate.
• Send an event without text and confirm the endpoint returns safely without a provider call.
• Temporarily make the Volanea request fail and confirm the job is retried without creating multiple notifications.
• Confirm no API key, webhook secret, visitor email address, or full message content appears in application logs unnecessarily.
• Confirm the from domain and reply handling are correct in a real receiving mailbox, not only in a provider dashboard.

Also test recipient rules. For an internal alert, ensure the destination is a fixed, authorized mailbox or an approved on-call list. For a customer follow-up, test only with an address you control and a documented consent path. This protects both deliverability and customer trust.

Zapier or Make as an alternative

If you do not operate backend infrastructure, Zapier or Make can provide the middleware layer. Both platforms support automation workflows and can connect LiveChat events to an HTTP request or email-related action, depending on the connectors and plan available to your account.

The trade-off is control. A no-code workflow can be fast to prototype, but you still need to answer the same production questions: where the Volanea key is stored, how duplicate events are handled, what happens on timeout, and whether the trigger exposes every field you need. Store the Volanea credential in the platform’s encrypted connection or secret facility, never in a text field that is exposed in task history or browser-side code.

Use a code-based receiver when any of these are true:

• You need exact event_created payload handling rather than a simplified connector trigger.
• You need atomic deduplication based on event.id.
• You need CRM enrichment, consent checks, or custom audience logic.
• You need to control security logging, retention, and access to message content.
• You expect meaningful volume and want predictable operational behavior.

Use an automation platform for a limited, low-risk alert when the connector exposes the event and fields you need, the recipient is internal, and the workflow includes a clear duplicate policy. Even then, test its retry behavior carefully; visual automation does not remove distributed-systems failure modes.

Deliverability and content practices for chat-triggered email

This integration is often used for internal notifications first, where deliverability is relatively straightforward. The moment you send to visitors, it becomes a customer-email workflow and deserves stricter controls.

Keep transactional and promotional intent separate. A visitor who asks for help may reasonably expect a transcript or a case update, but may not expect a newsletter. Send only messages that match the context and consent you have recorded. Use a recognizable sender name, a domain aligned with your organization, and a reply path monitored by people who can help.

For follow-ups, do not paste an entire chat transcript by default. A concise summary, a case reference, and a secure link to the relevant account area are often better. This reduces accidental disclosure if the recipient forwards the email or if a shared mailbox receives it.

Operationally, watch for sudden changes in volume. A misconfigured trigger condition can turn a busy chat queue into hundreds of emails in minutes. Rate-limit the worker, alert on unusual send counts, and make it easy to disable the webhook or send job consumer without redeploying your entire application.

A practical production checklist

Before considering the integration complete, verify the following:

• The LiveChat webhook uses the event_created action and points to a production HTTPS endpoint.
• Inbound requests are authenticated using the secret or signature method LiveChat documents.
• The Volanea key is stored only in server-side secrets or an encrypted automation credential store.
• The webhook handler filters on event type, message content, author context, and a documented business rule.
• The handler never treats chat text as a recipient address or trusted HTML.
• A durable idempotency record is keyed by event.id.
• The outbound email job is queued or otherwise isolated from webhook-response timing.
• The sender domain is configured for Volanea and the sender identity is intentional.
• Failure alerts cover webhook authentication failures, queue failures, provider errors, and unusual send volume.
• The workflow has been tested with duplicate payloads, missing fields, and provider errors.

With those controls in place, LiveChat becomes a useful source of real-time customer signals while Volanea handles the actual email send. The result is more flexible than a marketplace plugin: you can decide exactly which conversations produce email, who receives it, and how each send is tracked.

FAQ

Can I install Volanea from the LiveChat Marketplace?

No. Volanea does not ship a native LiveChat Marketplace app or plugin. Use a LiveChat webhook with your own middleware service, or use an automation platform that can receive LiveChat events and make a server-side API request.

What LiveChat event should trigger the email?

Use LiveChat’s event_created webhook when the send should begin from a newly created chat event, such as a text message. Filter the payload so that only the message types and content that match your business rule can create an email.

Where should I store the Volanea API key?

Store it in the server-side environment or encrypted secrets facility used by your middleware or automation platform. Never put it in a LiveChat widget script, a public frontend configuration file, a chat message, or a URL.

How do I stop duplicate emails after a webhook retry?

Use event.id from the LiveChat webhook as an idempotency key. Save it in a durable database with a unique constraint before sending, and reuse that identifier in the provider request when the API supports an idempotency header.

Can I email the visitor who started the chat?

Only if you obtained a valid address from a trusted source and have the appropriate consent and purpose for that email. A LiveChat message event alone is not proof of an email address or marketing permission.