How to Send Email from Triggerbee with Volanea

Send email from Triggerbee with Volanea by using a Triggerbee Automation webhook as the event source and a small server-side endpoint as the sending layer. Triggerbee can POST visitor and session data to an external URL, while the relay securely maps that data into a Volanea REST API request without exposing your email API key.

There is no native Volanea app, Triggerbee marketplace listing, or one-click plugin for this connection. That is not a blocker: Triggerbee’s documented Execute webhook Automation action is the appropriate outbound integration mechanism. The practical architecture is:

1. A visitor completes a Triggerbee event, such as submitting a campaign form.
2. A Triggerbee Automation runs and POSTs its visitor/session JSON payload to your webhook endpoint.
3. Your server validates and normalizes the incoming payload.
4. Your server calls Volanea’s POST /v1/send endpoint using a secret API key stored only in server-side environment variables.
5. Volanea queues the transactional message and records the send for operational follow-up.

This pattern gives marketers control over the onsite trigger while keeping the email credential, routing rules, duplicate protection, and error handling in a place developers can audit and maintain.

What the Triggerbee-to-Volanea integration does

Triggerbee is built around onsite experiences, visitor profiles, forms, goals, and Automations. A Triggerbee Automation can react to a campaign interaction or a custom behavior such as a completed goal, then run an action. Its webhook action makes an HTTP POST request containing JSON about the visitor and session.

Volanea is the delivery layer in this setup. Rather than having Triggerbee itself compose an authenticated email API call, the relay receives Triggerbee’s event and makes a separate, controlled Volanea request. This division matters because an email-sending secret is powerful: anyone who gets it may be able to send from your authenticated domain.

The resulting flow works especially well for messages that should happen immediately after an onsite action:

• A confirmation after a visitor submits a newsletter or waitlist form.
• A sales alert when a high-intent visitor requests a demo.
• A download link after a gated-content campaign conversion.
• A follow-up after a visitor reaches a conversion goal.
• An internal notification when a campaign survey response needs attention.
• A customer acknowledgement after a form records consent or a preference.

This is a transactional event pipeline, not a replacement for carefully designed lifecycle campaigns. If the recipient has asked for a single confirmation, use one event-driven send. If you need a multi-step nurture program, use a consent-aware workflow and a suitable marketing-email process instead of firing a fresh transactional request for every page interaction.

The concrete Triggerbee trigger: Form submission

The clearest implementation starts with Triggerbee’s Form submission Automation trigger. Triggerbee documents this trigger for campaign forms: in Automations, create an automation, choose Form submission as the trigger, and select the relevant campaign. Then add Execute webhook as the action.

That makes the business event unambiguous: the email starts when a visitor submits a particular Triggerbee campaign form. It is a better trigger than “visited page” for a confirmation email because a form submission supplies a clear visitor action, often includes an email address, and can capture an explicit consent choice.

You can use other documented Automation trigger types when they better match the message. Triggerbee describes campaign automations tied to a specific campaign, while custom automations can use triggers such as Completed goal and Visited page. For example, a product-interest goal could create an internal alert, or a completed purchase goal could send a customer receipt only when your broader system has already determined that a receipt is appropriate.

For this guide, configure the Automation as follows:

1. Open Automations in Triggerbee.
2. Create a new automation.
3. Choose Form submission as the trigger.
4. Select the Triggerbee campaign containing your signup, request, or lead form.
5. Add the Execute webhook action from the Triggerbee library.
6. Enter your server-side webhook URL, such as https://events.example.com/triggerbee/form-submitted.
7. Keep Triggerbee’s Use the new format option enabled, as Triggerbee recommends for webhook automations.
8. Name and save the automation.
9. Submit a test form with a real test inbox before activating customer-facing follow-up.

Do not put https://api.volanea.com/v1/send directly into the Triggerbee webhook URL. The Triggerbee webhook action is designed to deliver its own visitor/session payload to a receiving web app. It is not a safe place to embed the Volanea credential or transform a Triggerbee payload into an email API request.

The real Triggerbee webhook payload and field mapping

Triggerbee POSTs JSON with a top-level visit object. The exact shape varies because visitor data may or may not exist for a session, and Fields only appears when custom or form data is available. Triggerbee’s documented standard data includes session and visitor identifiers, timestamp, identifier, location, goals, and revenue. Its richer example adds PersonalData, Fields, Consent, tags, and UTM data.

A representative Form submission event using Triggerbee’s documented new webhook format looks like this:

{
  "visit": {
    "SessionId": 107582864,
    "Uid": 2693256119,
    "Time": "2026-01-21T10:25:26",
    "Identifier": "someone@example.com",
    "NetName": null,
    "GeoLocation": "Stockholm, Sweden",
    "Tags": ["Customer"],
    "Goals": [
      "Completed purchase",
      "Submitted the form \"Signup 2.0\""
    ],
    "Revenue": 1500,
    "Consent": {
      "Title": "Signup 2.0",
      "CurrentWebsiteUrl": "https://example.com/",
      "AcceptedTitle": null,
      "AcceptedUrl": null,
      "PolicyUrl": "https://privacypolicy.example.com/privacy",
      "PolicyText": "I consent to the privacy policy",
      "IsCheckboxPresent": "false",
      "PolicyVersionDate": "2022-11-23T16:55:39.111",
      "PolicyRevisionNumber": "5"
    },
    "PersonalData": {
      "Email": "someone@example.com",
      "Name": "Firstname Lastname",
      "FirstName": "Firstname",
      "LastName": "Lastname",
      "Organization": null,
      "Phone": "0707123456",
      "Username": null,
      "Title": null
    },
    "Fields": {
      "Date1": "2024-02-23",
      "responseListId": "7aaa39bf-93e3-4dcc-a68e-4455f326d92e",
      "submitPath": "/product/lamp-black/"
    },
    "Utm": {
      "Time": "2026-01-21T10:18:37+00:00",
      "CampaignName": "myUTMCampaign",
      "Source": "myUTMSource",
      "Medium": "myUTMMedium"
    }
  },
  "text": "Someone visited your website and completed a form submission goal.",
  "blocks": null
}

The most important mapping principle is not to assume every field will be present. For an email recipient, prefer visit.PersonalData.Email, then use visit.Identifier only as a fallback after validating that it is an email address. An identifier may be absent, or your implementation may use another identity value in some sessions.

A practical mapping table looks like this:

Do not merge all of Fields into an HTML email automatically. Form field names and values may change as marketers edit campaigns, and user-provided text can contain markup, misleading content, or sensitive personal data. Map individual fields deliberately and escape every value placed into HTML.

Build the secure webhook relay

The relay can be an Express application, a serverless function, a Cloudflare Worker, a Next.js route handler, or any server-side environment that can receive HTTPS requests and make outbound HTTPS calls. The key requirement is that it runs away from the visitor’s browser and outside any client-visible Triggerbee configuration.

The following Express example receives the Triggerbee payload, validates the recipient, escapes personal data, creates a stable idempotency key, and calls Volanea. It uses the documented Volanea send endpoint, POST https://api.volanea.com/v1/send, with Bearer authentication, JSON content, and the Idempotency-Key header.

import "dotenv/config";
import crypto from "node:crypto";
import express from "express";

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

const emailPattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

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

app.post("/triggerbee/form-submitted", async (req, res) => {
  const visit = req.body?.visit ?? {};
  const personal = visit.PersonalData ?? {};
  const fields = visit.Fields ?? {};

  // Triggerbee may omit PersonalData.Email. Identifier is only a fallback.
  const recipient = String(personal.Email ?? visit.Identifier ?? "")
    .trim()
    .toLowerCase();

  if (!emailPattern.test(recipient)) {
    console.warn("Triggerbee event skipped: no valid email", {
      sessionId: visit.SessionId,
      uid: visit.Uid
    });
    return res.status(202).json({ accepted: true, skipped: "missing_valid_email" });
  }

  const firstName = escapeHtml(personal.FirstName || "there");
  const submitPath = escapeHtml(fields.submitPath || "");

  // Same logical Triggerbee event = same idempotency key on retries.
  const eventIdentity = [
    "triggerbee-form-confirmation",
    visit.SessionId ?? "no-session",
    visit.Uid ?? "no-uid",
    visit.Time ?? "no-time",
    recipient
  ].join(":");

  const idempotencyKey = crypto
    .createHash("sha256")
    .update(eventIdentity)
    .digest("hex");

  const volaneaPayload = {
    from: "Example Team <hello@example.com>",
    to: recipient,
    subject: "Thanks for your submission",
    html: `
      <p>Hi ${firstName},</p>
      <p>Thanks for getting in touch. We received your submission.</p>
      ${submitPath ? `<p>Submitted from: ${submitPath}</p>` : ""}
      <p>We will follow up shortly.</p>
    `,
    text: `Hi ${personal.FirstName || "there"},\n\nThanks for getting in touch. We received your submission.\n\nWe will follow up shortly.`,
    type: "transactional"
  };

  try {
    const response = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${process.env.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", {
        status: response.status,
        sessionId: visit.SessionId,
        responseBody
      });
      return res.status(502).json({ accepted: false, upstream: "volanea" });
    }

    console.info("Volanea message accepted", {
      sessionId: visit.SessionId,
      recipient,
      idempotencyKey
    });

    return res.status(200).json({ accepted: true });
  } catch (error) {
    console.error("Volanea request error", {
      sessionId: visit.SessionId,
      message: error.message
    });
    return res.status(502).json({ accepted: false, upstream: "volanea" });
  }
});

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

Replace hello@example.com with an address on a domain verified in Volanea. A valid-looking address is not enough: the sending domain must be authenticated before you use it for production mail. Keep the HTML and text versions aligned. Plain text remains valuable for recipient accessibility, mailbox compatibility, and a clear fallback when rich HTML is not preferred.

The code deliberately returns 202 for a webhook that lacks a usable recipient. That tells Triggerbee the event reached your endpoint while preventing pointless delivery retries for data that cannot become an email. Whether you instead want a hard failure depends on your operations model, but do not repeatedly retry an event that can never meet basic email requirements.

Where the Volanea API key belongs

The Volanea API key does not belong in Triggerbee, a Triggerbee campaign script, browser JavaScript, a form field, or a publicly inspectable webhook URL. In this integration, Triggerbee holds only the destination URL for your receiving service. The Volanea secret lives in the relay’s secret manager or environment-variable system as VOLANEA_API_KEY.

For a local Express deployment, that might mean a .env file excluded from version control:

VOLANEA_API_KEY=sk_your_secret_key
PORT=3000

In production, store the same value in your hosting provider’s encrypted secret store, not in source code or a copied deployment configuration file. Use a distinct key per environment where possible, such as a test key for staging and a production key for live sends. This limits the impact of an accidental leak and makes it possible to rotate one environment without disrupting another.

There are two different credentials to think about:

• Volanea API key: kept only by the server-side relay; it authorizes email sends.
• Webhook endpoint protection: used to limit who can submit events to your relay; it should not be confused with the Volanea credential.

Triggerbee’s documented webhook setup describes entering a URL and receiving a POST payload; it does not document a configurable custom authorization-header field in that setup. Therefore, do not claim that Triggerbee will send a bespoke Authorization header unless your account’s current product UI and documentation explicitly confirm it. A safer baseline is to expose an unguessable endpoint path, place it behind your own gateway controls, apply rate limits, and validate the payload shape. If your infrastructure supports it, add network-level controls and monitoring too.

An opaque path is not a substitute for full cryptographic webhook verification. Treat it as one layer in a defense-in-depth design. Crucially, even if someone discovers the Triggerbee endpoint URL, they still must not gain access to your Volanea API key.

For more endpoint fields, key scopes, and sending behavior, consult the email API reference and setup guides while implementing the relay.

Make duplicate sends impossible in normal retries

Webhook delivery is usually at-least-once, not exactly-once. A sender can retry because it did not receive a timely success response, even when your relay had already started work. A temporary network break can also occur after Volanea accepted the request but before your relay received its response. Without a duplicate strategy, the safe operational behavior—retrying—can create two confirmation emails.

Use Volanea’s Idempotency-Key header for each logical Triggerbee event. The key must be stable across retries of one event and different for a genuinely separate form submission. That is why the example derives the key from an event label plus SessionId, Uid, Time, and recipient. Do not generate a random UUID independently on every HTTP attempt; doing that would tell Volanea each retry is a new send.

There are two levels of protection worth using:

1. Volanea idempotency: pass the same Idempotency-Key whenever the exact logical send is retried.
2. Your own event ledger: persist the event identity and resulting Volanea response in a database with a uniqueness constraint. This is especially valuable when multiple workers, regions, or integrations could process the same Triggerbee event.

The second layer lets you make decisions before attempting the Volanea request. For example, a table keyed by triggerbee:SessionId:Time:messageType can record processing, accepted, and failed states. An atomic insert prevents two concurrent invocations from both sending while a downstream request is still in flight.

Be intentional about the event identity. SessionId alone may be too broad if the same visitor submits two separate forms during one session. An entire JSON-body hash may be too narrow if unimportant metadata changes between deliveries. Combine the fields that identify the business action, then test the behavior with repeat submissions and retried deliveries.

When this breaks: diagnose the specific hop

Every integration has failure modes. The useful question is where the failure happened: did Triggerbee not emit an Automation event, did the webhook fail to reach your relay, did the relay reject data, or did Volanea reject or later suppress the email?

Triggerbee retries create duplicate sends

A webhook timeout is the classic duplicate scenario. Your relay calls Volanea, Volanea accepts the message, but the relay does not return a response to Triggerbee quickly enough. Triggerbee may retry the webhook. If the retry produces a new Volanea idempotency key—or no key—you can send a duplicate confirmation.

Fix: return a success response only after your event is safely recorded, use one deterministic key for that event, and consider an asynchronous queue. If you enqueue first, respond quickly to Triggerbee after the queue write succeeds; a worker can then make the Volanea request with the stored idempotency key.

The webhook times out

Do not make the Triggerbee request wait on slow database queries, template rendering from another service, analytics calls, or nonessential enrichment. The handler should validate the payload, persist or enqueue the work, and complete the minimum required send action promptly.

Fix: keep the synchronous path short. Put CRM lookups, reporting, enrichment, and other optional work in background jobs. Log the Triggerbee SessionId, Uid, and Time so the event can be traced across Triggerbee, your service, and Volanea.

Payload fields are missing

Triggerbee explicitly notes that webhook payloads differ based on what data is available for the visitor and session. PersonalData, Fields, consent data, or UTM values may be absent. This can happen when a campaign does not collect a field, an anonymous visitor has not been identified, a field name changes, or a configuration differs between environments.

Fix: use optional access for every non-guaranteed field, define a recipient fallback policy, and test a payload with only Triggerbee’s standard visitor/session fields. For recipient confirmation emails, skip safely when no valid email exists. For internal lead alerts, send to a fixed internal address and include a clear “email unavailable” marker instead of treating missing visitor email as an exception.

The sender address is rejected

Volanea can reject a request when the from address is not on a verified sending domain. This is a configuration issue, not a Triggerbee payload issue.

Fix: use a fixed, verified From address stored in server-side configuration. Do not map the From address from a Triggerbee form field, visitor profile, or URL parameter. A visitor-provided value belongs, at most, in reply context after validation—not as the authenticated sender.

The recipient address is invalid or suppressed

A form may contain a typo, disposable mailbox, malformed address, or an address previously suppressed after delivery failures or opt-out handling. A request accepted for processing is not a guarantee that a message reached an inbox.

Fix: validate syntax before calling Volanea, respect suppression outcomes, and avoid retrying permanent validation failures. For lead-generation forms where address quality matters, use an address check before beginning a sales sequence; the free email address verification tool can help with one-off checks and testing.

Triggerbee Automation never fires

If no request reaches the relay, investigate the Triggerbee side first. Check that the Automation is active, that it uses the intended Form submission trigger and campaign, and that the visitor actually completed the form action that the Automation watches. Also confirm that the webhook URL is reachable publicly over HTTPS.

Fix: capture a test request on a request-inspection endpoint during setup, then point the Automation back to your production relay. Compare the captured JSON with the assumptions in your mapper. This is more reliable than building against an imagined payload shape.

A 200-level Volanea response is mistaken for inbox delivery

A successful send response means the API accepted the email for processing; it is not proof that a recipient opened it or that every mailbox provider placed it in the inbox. Downstream outcomes can include accepted, delivered, bounced, suppressed, or engagement events depending on the email lifecycle.

Fix: treat API acceptance, delivery events, and engagement metrics as separate states. Build alerts around persistent API errors, sudden increases in invalid recipients, and unexpected suppression patterns rather than claiming delivery based only on the initial request.

Use a queue when the email is business-critical

The direct relay example is a useful starting point, but high-value workflows deserve a queue or durable event store between Triggerbee and Volanea. The flow becomes:

1. Triggerbee sends the form-submission webhook.
2. The endpoint validates the minimum required structure.
3. The endpoint atomically saves a message job using its deterministic event key.
4. The endpoint returns a fast success response.
5. A worker sends the job through Volanea with the same stored idempotency key.
6. The worker records the response and retries only temporary failures.

This architecture separates webhook receipt from message delivery. It also improves observability because you can inspect pending, completed, skipped, and failed jobs without searching application logs after the fact.

Classify failures before retrying them. Network errors and many 5xx responses may be temporary. An invalid recipient, malformed request, unauthorized key, or unverified sender is usually a configuration or data issue that should be surfaced for correction rather than retried repeatedly. Retry limits, exponential backoff, and a dead-letter review path keep one malformed campaign configuration from producing endless traffic.

A queue is also the right place to enforce business rules such as “send only one welcome confirmation per address per 24 hours” or “send the sales alert only if revenue exceeds a threshold.” Those rules should be explicit and testable, not hidden in a loosely structured email template.

Consent, personalization, and content safety

A form submission can establish a useful transactional trigger, but it does not automatically authorize every kind of future marketing email. Design the email category around the action taken. A message confirming that you received a request is different from subscribing the visitor to a promotional series.

Triggerbee can provide consent-related data in its webhook payload when available, including the policy text, policy URL, checkbox-related details, and campaign context. Store the subset you need for your compliance records, but do not rely on a raw string comparison as your entire consent model. The decisive factor is how your form, privacy notice, audience rules, and local obligations define permission.

Personalization also needs guardrails. First names and free-text fields should be HTML-escaped. URLs should be constrained to approved hostnames before being placed in buttons. Values such as submitPath may be useful in internal notifications but are rarely necessary in customer confirmation content. The fewer raw fields you echo back, the lower the chance of leaking unexpected data or producing confusing mail.

Keep separate templates or code paths for customer-facing and internal messages. A customer acknowledgement should be minimal, predictable, and branded. An internal lead alert can include campaign name, UTM data, session context, and captured fields needed for follow-up. Mixing these two audiences in one template usually creates either an overly invasive customer message or an unhelpfully sparse internal notification.

Testing the integration before launch

Test the whole path, not just the Volanea API call. A successful curl request proves that your key and sender configuration work, but it does not prove Triggerbee chooses the intended campaign event or maps fields as expected.

Use this launch checklist:

• Submit the exact Triggerbee form as an anonymous visitor.
• Submit it again as an identified visitor with profile data.
• Submit it with an address in PersonalData.Email.
• Test a payload where only Identifier contains the email address.
• Test a payload with no usable email and confirm the relay skips it safely.
• Submit twice intentionally and verify that two distinct submissions produce the desired business outcome.
• Replay the exact same captured payload and verify the idempotency strategy prevents a duplicate send.
• Temporarily simulate a Volanea network failure and inspect retry behavior.
• Confirm the From address uses a verified Volanea domain.
• Inspect the final HTML and text email in multiple mailbox clients.
• Check that no logs print the Volanea API key or unnecessary full personal-data payloads.

Use a dedicated test recipient list. Avoid testing live confirmation workflows against real prospects, particularly when the campaign could add people to a sales process or marketing audience. Make the test subject visibly identifiable, such as [Test] Triggerbee form confirmation, until the event mapping is proven.

Alternatives: Zapier, Make, and direct middleware

Triggerbee also offers a Zapier integration that can trigger a Zap when someone signs up or converts in a Triggerbee campaign. Zapier can be a practical option when your team already manages automation there and wants to route Triggerbee activity through other systems before email is sent.

However, do not place a long-lived Volanea key in a client-side step or an exposed webhook configuration. If you use Zapier or Make, store secrets in their protected connection or secret facilities where available, limit who can edit the workflow, and still use deterministic idempotency. For sensitive or high-volume workflows, a small owned middleware service gives you stronger control over logs, security boundaries, response behavior, and duplicate handling.

Choose the route based on the operational need:

• Direct Triggerbee webhook to your relay: best for developers who need control, reliability, and custom logic.
• Triggerbee to Zapier or Make to a protected relay: useful for low-code orchestration with a server-side email boundary.
• Triggerbee native integration to another email platform: useful only when that platform is already your chosen sending system; it is not a Volanea integration.

The direct webhook relay is generally the clearest path when the goal is to send immediate, personalized transactional email from a verified domain while retaining ownership of the sending credential.

Conclusion

To send email from Triggerbee with Volanea, build around the tools that actually exist: Triggerbee Automations, the Form submission trigger, and the Execute webhook action. Send Triggerbee’s POST payload to a server-side relay, map the documented visit fields defensively, and call POST /v1/send with a Bearer-authenticated Volanea key that never appears in the browser or Triggerbee campaign configuration.

The details that make this production-ready are not the first successful email. They are the controls around it: verified sender domains, strict field validation, escaped personalization, short webhook response paths, deterministic Idempotency-Key values, durable logging, and a plan for missing data and retried deliveries. Get those pieces right and Triggerbee can become a reliable event source for timely Volanea email.

FAQ

Does Triggerbee have a native Volanea integration?

No. Triggerbee does not have a native Volanea app, marketplace listing, or plugin for this connection. Use a Triggerbee Automation with the Execute webhook action to send event data to your own server-side relay.

What Triggerbee event should trigger the email?

For a signup, request, or lead-confirmation flow, use Triggerbee’s Form submission Automation trigger and select the specific campaign containing the form. For other workflows, a campaign interaction or a custom Automation trigger such as Completed goal may be a better fit.

Can I send the Triggerbee webhook directly to Volanea?

No. Triggerbee sends its own visitor/session JSON payload, while Volanea expects an email-send request with authenticated headers and email fields. A relay safely transforms the Triggerbee payload and keeps the Volanea API key private.

Where should I store the Volanea API key?

Store it only in the server-side relay’s environment variables or secret manager, such as VOLANEA_API_KEY. Never expose it in a Triggerbee campaign script, public webhook URL, browser code, or form configuration.

How do I stop duplicate emails when Triggerbee retries a webhook?

Create a stable Idempotency-Key from the logical Triggerbee event—for example, message type plus SessionId, Uid, Time, and recipient—and reuse it for every retry of that same event. For critical workflows, also persist the event in a database with an atomic uniqueness constraint before sending.