Lytics can decide who should receive a message based on profile data and audience membership; Volanea can handle the actual delivery. This guide explains how to send email from Lytics by using Lytics’ outbound webhook capability and a secure server-side relay that calls the Volanea REST API.

This is intentionally not a marketplace-installation guide. Volanea does not provide a native Lytics application, marketplace listing, or client-side plug-in. The reliable integration pattern is: a person qualifies for an audience in Lytics, Lytics posts an event to an endpoint you control, and that endpoint validates the request, maps the profile data, and asks Volanea to send the email.

That separation is useful. Lytics remains the customer-data and audience-decision layer, while Volanea remains the delivery layer. It also keeps a sending credential out of browser code and out of a third-party webhook payload.

What this Lytics-to-Volanea integration does

The concrete trigger is an audience membership event in Lytics: a profile enters an audience whose definition represents the event you care about. For example, an audience might contain profiles that have submitted a lead form, completed onboarding, reached a high-intent score, renewed a subscription, or have not visited in 30 days.

Configure a webhook action for that audience’s entry event. When a profile qualifies, Lytics sends an HTTP POST to your server. Your server then constructs an email request and sends it to Volanea.

The full request path looks like this:

A customer action or imported event updates a Lytics profile.
Lytics recalculates audience membership.
The profile enters the selected audience.
The audience webhook posts profile and audience context to your HTTPS endpoint.
Your endpoint verifies that the request is expected and extracts approved fields.
Your endpoint calls the Volanea email API with a server-side API key.
Volanea accepts the message for delivery and returns a provider message identifier.
Your application records the event and message identifier for support, suppression, and duplicate protection.

An audience entry is not the same thing as a form submission at the instant it happens. A form submission can be one input into a profile, but the outbound action is driven by the profile becoming a member of an audience. That distinction matters when you set expectations around timing: profile ingestion, identity resolution, and audience evaluation can happen before the webhook is emitted.

Why use an audience webhook rather than send directly from a browser

It is tempting to put an email API call in a web form, tag manager, or personalization script. Do not do that. A Volanea API key is a sending credential. If it appears in JavaScript delivered to a browser, a mobile application bundle, a public repository, or a client-visible tag-manager configuration, anyone who can retrieve it may be able to send mail under your account.

A webhook relay solves the security problem and creates a useful control point. It lets you enforce rules that neither an audience definition nor an email provider should have to infer:

Permit only expected audience IDs or audience names.
Require a valid recipient email address before attempting delivery.
Block personal-data fields that are not needed in an email.
Select a template from a short allowlist rather than from an arbitrary incoming value.
Attach a deterministic idempotency key to prevent repeated event delivery from producing repeated email.
Log provider responses without logging an API key or a full sensitive profile.

The relay can be a small serverless function, an API route in an existing application, a worker, or a conventional web service. It does not need to be a large integration platform. In many cases, the code is shorter than the operational safeguards around it.

For request formats, authentication, and current sending examples, keep the implementation aligned with the Volanea email API reference. The key point for this integration is that the Volanea request is made by your server, not by Lytics in a way that exposes Volanea credentials.

Build the Lytics audience that starts the send

Start with the business condition, not the email template. A clear audience definition makes it easier to reason about eligibility and prevents accidental sends to a broad segment.

For a welcome-email workflow, an audience might express all of the following conditions:

The profile has a known email address.
The profile has a consent or subscription status that permits this type of email.
The profile has the event or attribute indicating signup completion.
The profile has not already received the welcome message.
The profile is not suppressed, bounced, or marked as unsubscribed in the source system.

For an operational message, the consent condition may be different from a marketing campaign. A receipt, password-reset notice, or service interruption notice is generally driven by the transaction itself. A promotion, re-engagement email, or newsletter is a marketing message and should use the consent model, unsubscribe handling, and audience rules appropriate to your jurisdiction and product.

Choose an entry event deliberately

An audience can change for many reasons: a new event arrives, an attribute is corrected, an identity is merged, an import finishes, or an existing profile is reevaluated. The email should normally be tied to entering the audience, rather than merely being present in it.

Consider a renewal reminder audience. If the rule is simply “renewal date is within seven days,” a profile may remain eligible for several evaluations. An entry-based webhook is a better starting point than a periodic bulk export because it captures the transition into eligibility. Still, use a durable send marker or an idempotency key, because a profile can leave and later re-enter an audience, and because delivery systems can retry webhook requests.

Include only fields the email requires

Your webhook payload should contain the recipient email, a stable profile identifier, the audience identifier or a known event name, and the few personalization values required for the message. Do not forward an entire customer profile merely because it is available.

A welcome email may require email, first_name, account_name, and a profile_id. It does not require a customer’s full event history, device identifiers, location history, or unrelated attributes. Smaller payloads reduce exposure, simplify debugging, and make payload-contract changes easier to manage.

The payload contract between Lytics and your relay

A webhook is an HTTP request, not an email request. Treat the body from Lytics as an integration contract that your endpoint validates before it reaches Volanea.

The exact set of profile attributes available to an audience action depends on the fields collected in your Lytics account and the profile data made available to the action. A practical payload shape is a JSON object containing the audience context plus a nested profile object. The relay below expects this contract:

{
  "event": "audience.entered",
  "audience": {
    "id": "welcome-qualified",
    "name": "Welcome qualified"
  },
  "profile": {
    "id": "lytics-profile-01HZY8Q8S1",
    "email": "ada@example.com",
    "first_name": "Ada",
    "plan": "starter",
    "consent_email_marketing": true
  },
  "occurred_at": "2026-10-08T14:20:00.000Z"
}

In the Lytics webhook configuration, map the profile’s stable ID, email field, and approved attributes into the outgoing JSON body. Use a stable Lytics profile identifier rather than email as the principal event identifier. Email can change; a stable profile ID makes duplicate control and audit trails more reliable.

Do not assume every profile has every attribute. Older imports, anonymous visitors, merged profiles, and data sources with different schemas can create partial records. A missing first_name should result in a sensible greeting. A missing or malformed email should result in a rejected webhook event, not a guessed recipient.

Treat audience and template names as allowlisted values

Do not let an inbound template field choose an arbitrary Volanea template or raw HTML. Your endpoint should decide which message is allowed for a given audience. This avoids a configuration mistake becoming an unintended mail-sending surface.

For example, welcome-qualified may map only to welcome-v2; trial-expiring may map only to trial-expiring-v1. If Lytics sends an unrecognized audience ID, return an error and investigate rather than sending a generic fallback message.

Working server-side example: webhook to Volanea REST API

The following Node.js example is an Express handler. It accepts the JSON contract above, validates it, uses an idempotency key derived from the audience event, and calls Volanea from the server. Put this behind HTTPS, authenticate the inbound webhook according to the authentication mechanism available in your Lytics webhook configuration, and replace environment-variable values with your own.

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

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

const allowedAudiences = {
  "welcome-qualified": {
    templateId: "welcome-v2",
    from: "Acme Team <hello@updates.example.com>",
    subject: "Welcome to Acme, {{first_name}}"
  }
};

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

app.post("/webhooks/lytics/audience-entry", async (req, res) => {
  // Example shared-secret check. Store this only in server-side environment vars.
  if (req.get("x-lytics-webhook-secret") !== process.env.LYTICS_WEBHOOK_SECRET) {
    return res.status(401).json({ error: "unauthorized webhook" });
  }

  const { event, audience, profile, occurred_at: occurredAt } = req.body ?? {};
  const audienceId = audience?.id;
  const profileId = profile?.id;
  const email = profile?.email;
  const firstName = typeof profile?.first_name === "string"
    ? profile.first_name.trim()
    : "there";

  if (event !== "audience.entered") {
    return res.status(202).json({ ignored: "not an audience-entry event" });
  }

  if (!allowedAudiences[audienceId]) {
    return res.status(400).json({ error: "audience is not approved for sending" });
  }

  if (!profileId || !validEmail(email)) {
    return res.status(422).json({ error: "profile id and valid email are required" });
  }

  if (profile?.consent_email_marketing !== true) {
    return res.status(202).json({ ignored: "marketing consent is absent" });
  }

  const message = allowedAudiences[audienceId];
  const idempotencyKey = crypto
    .createHash("sha256")
    .update(`${audienceId}:${profileId}:${occurredAt}`)
    .digest("hex");

  // In production, insert idempotencyKey into a database with a unique constraint
  // before sending. If it already exists, return 200 without sending again.
  const volaneaResponse = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify({
      from: message.from,
      to: [{ email, name: firstName === "there" ? undefined : firstName }],
      subject: message.subject.replace("{{first_name}}", firstName),
      template_id: message.templateId,
      variables: {
        first_name: firstName,
        plan: profile?.plan ?? "",
        lytics_profile_id: profileId
      },
      tags: [
        { name: "source", value: "lytics" },
        { name: "audience", value: audienceId }
      ]
    })
  });

  const responseBody = await volaneaResponse.json().catch(() => ({}));
  if (!volaneaResponse.ok) {
    console.error("Volanea send failed", {
      status: volaneaResponse.status,
      audienceId,
      profileId,
      providerError: responseBody
    });
    return res.status(502).json({ error: "email provider rejected the send" });
  }

  // Persist audienceId, profileId, occurredAt, idempotencyKey, and provider message ID.
  return res.status(202).json({ accepted: true, message: responseBody });
});

app.listen(3000);

The mapping is explicit: profile.email becomes the Volanea recipient email, profile.first_name becomes the recipient name and template variable, and profile.id becomes an internal correlation value. The Lytics audience ID determines which approved sender and template can be used.

Before deploying, confirm current request field names, template behavior, and idempotency support in the Volanea documentation. Email APIs may distinguish between inline HTML messages and stored templates, and the correct field name should match the sending mode you choose.

Keep Volanea credentials out of Lytics and the browser

The Volanea API key belongs in the secret store or encrypted environment-variable system attached to your relay: for example, a cloud function’s secret manager, a worker secret, or your application’s deployment environment. It should be read at runtime as VOLANEA_API_KEY and never included in the Lytics webhook body.

Lytics only needs the URL for your relay and, where supported by your webhook configuration, an inbound authentication value for your endpoint. A separate random shared secret is appropriate for that purpose. It gives your endpoint a way to reject unauthenticated posts without giving Lytics the credential that can send mail.

Use separate secrets for separate directions:

LYTICS_WEBHOOK_SECRET authenticates Lytics to your relay.
VOLANEA_API_KEY authenticates your relay to Volanea.
Your database credentials, logging tokens, and deployment credentials remain separate again.

Rotate a secret when staff access changes, a credential appears in logs, a repository scan detects it, or you cannot establish where it has been used. Rotation is much easier if credentials are held in a deployment secret manager rather than copied into multiple audience configurations or hard-coded integration scripts.

Design the email for deliverability and consent

A technically successful API call is not the same as a delivered or welcome email. The sending domain should be authenticated with the DNS records required by your sending platform, the visible From domain should align with your brand, and the content should match the user action that placed the person into the audience.

Avoid using an audience webhook as a shortcut around unsubscribes or suppression lists. Marketing email requires an operational unsubscribe process and a source of truth for marketing permission. If consent changes outside Lytics, update the relevant profile attribute quickly enough that the audience no longer qualifies the person.

For high-value lifecycle messages, use a narrow audience and a message that explains why it arrived. “You started a trial” is clearer than a generic promotion. The resulting engagement signals are generally healthier than sending a broad message to every profile with a nonempty email field.

Separate transactional and marketing logic

You may operate both message types through the same relay, but do not combine their eligibility rules casually. A password reset should be initiated by an explicit application event and sent to the account holder, not by an audience built from behavioral data. A re-engagement campaign should use an audience that incorporates marketing consent and suppression status.

Keeping distinct audience IDs, templates, tags, and sender identities also makes reporting easier. If complaint or bounce rates rise, you can identify whether the problem is the lifecycle audience, a particular data source, or the content itself.

When this breaks: failures specific to this hop

The Lytics-to-relay hop is where many integrations fail quietly. Build for the failure modes before using it for a large audience.

Webhook retries can create duplicate sends

A webhook sender may retry when it cannot establish a connection, receives a timeout, or receives a non-success HTTP response. From Lytics’ perspective, a timeout can be ambiguous: your relay may have sent the Volanea request successfully but failed before returning its response. A retry can then create a second send.

Return a successful response only after you have recorded the event in durable storage, or place the event onto a durable queue and return success after that enqueue completes. Use a database unique constraint on an idempotency key such as audience_id + profile_id + occurred_at. Do not rely only on an in-memory cache, which disappears during restarts and does not coordinate across multiple instances.

If Volanea supports an idempotency header for the endpoint you use, send the same key on retried provider requests as an additional guard. Your own database remains important because it protects the entire path, including repeated deliveries from Lytics.

Webhook timeouts should not contain email work

An outbound webhook has a finite timeout. If your relay does DNS lookups, template rendering, database writes, and a provider call before responding, it may exceed that deadline. The sender can retry even though the first invocation is still running.

A stronger architecture is receive, validate, deduplicate, queue, and acknowledge. A background worker then calls Volanea and records the provider response. This is especially important when an audience change can create a burst of events after an import or a rule update.

Set observability around both sides of the boundary: webhook receipt rate, validation failures, queue age, Volanea acceptance rate, provider errors, and duplicate-suppression count. Alert on a growing queue or an unusual jump in 4xx validation errors; those usually indicate a schema or configuration change rather than a delivery-provider outage.

Profile fields may be absent or differently named

Lytics profile schemas reflect the data you collect and make available. A field available for one source or account configuration may not be present on another profile, and some data-access or product-plan configurations can limit fields exposed to downstream actions. Do not make a send depend on an optional personalization field without a fallback.

Required fields should be validated explicitly. If email is absent, malformed, or not approved for the message type, reject or ignore the event and log a privacy-safe diagnostic such as a profile ID and missing-field name. Never replace an absent address with a guessed one, and do not log full profile bodies by default.

Audience rule edits can trigger unexpected volume

Changing the criteria of an existing audience can cause many profiles to enter it at once. Before enabling the webhook action for a changed rule, estimate membership and test with an internal or seed audience. Consider a feature flag in your relay that accepts and records events but does not send until a launch window is approved.

A send cap is another useful circuit breaker. If a welcome audience normally sends 300 messages per hour and suddenly produces 30,000, pause the worker and investigate the rule, identity merge, or import that caused the change.

Test the integration before enabling production sends

Use a test audience and a mailbox you control. First confirm that the profile enters the audience and that Lytics reaches the relay. Then confirm field values, template rendering, Volanea acceptance, and arrival in the mailbox.

A practical test matrix includes:

A complete profile with consent, expected to send one email.
A profile with no first_name, expected to receive the fallback greeting.
A profile with no email, expected to be rejected without a provider call.
A profile without marketing consent, expected to be ignored for a marketing template.
The same webhook delivered twice, expected to create one provider send.
An unknown audience ID, expected to be rejected.
A temporary Volanea failure, expected to be queued or retried according to your policy.

Record the Lytics profile ID, audience ID, webhook receipt time, idempotency key, and Volanea message identifier in one searchable event record. That record is what support staff need when someone asks why they did or did not receive an email.

Alternatives when a relay is not available

If your team cannot deploy a small endpoint, an automation service can act as middleware: receive a Lytics webhook, transform the JSON, and call an HTTP endpoint for Volanea. This can be useful for a limited proof of concept, but it does not remove the need for secret storage, validation, consent checks, and duplicate handling.

A no-code scenario can also make retry behavior harder to reason about at scale. Check whether the automation tool retries a failed HTTP action, whether it stores request history containing personal data, and whether it supports durable idempotency. For production lifecycle email, a small owned relay or worker often gives better control and lower long-term operational risk.

Another alternative is to have Lytics influence the application through audience membership while the application itself sends the email in response to a first-party business event. That is usually preferable for true transactional mail, where an order, account, or security event—not audience membership—is the authoritative source.

Operational checklist for a durable deployment

Before enabling the webhook on a live audience, verify the following:

The audience represents a specific, consent-aware eligibility condition.
The webhook body contains only required, approved profile fields.
The relay accepts HTTPS requests and authenticates inbound calls.
The Volanea API key exists only in server-side secret storage.
Audience IDs map to an allowlisted sender and template.
The relay validates recipient addresses and handles missing optional fields.
A durable idempotency record exists before an email can be sent twice.
Provider errors, queue failures, and rejected payloads are monitored.
Your sending domain authentication, unsubscribe process, and suppression handling are ready.
A sudden audience-volume change cannot send an unreviewed burst of mail.

This pattern creates a clean boundary: Lytics determines that a person has entered an eligible audience, while Volanea delivers a deliberately selected message with server-controlled credentials. It is flexible enough for welcome sequences, trial milestones, renewal reminders, and other audience-driven communications without pretending that a native Lytics plug-in exists.

FAQ

Can Lytics send directly through the Volanea API?

Lytics can initiate the workflow through an audience webhook, but the Volanea API key should be used by a server-side relay you control. Do not place the sending key in browser code or in client-visible configuration.

What event should trigger the webhook?

Use an audience-entry event for a narrowly defined audience. For example, a profile enters an audience after it has a valid email, the required consent, and a completed-signup attribute.

How do I stop duplicate emails after webhook retries?

Create a deterministic idempotency key from the audience ID, stable Lytics profile ID, and event timestamp or event ID. Store it with a database unique constraint before sending, and reuse it when calling the provider if the API supports idempotency.

What happens if a Lytics profile has no email address?

Validate the payload at the relay and reject or ignore the event without calling Volanea. Log the stable profile ID and missing-field reason, not the full profile payload.

Should transactional and marketing messages use the same audience?

Usually no. Transactional mail should be driven by the authoritative application event, while marketing audiences must incorporate the correct consent, suppression, and unsubscribe logic.

How to Send Email From Lytics With the Volanea API