Bonjoro is built around personal video messages, but a Bonjoro event can also be a useful signal for operational email. This guide shows how to send email from Bonjoro through Volanea without exposing an email API key or pretending there is a native Bonjoro-to-Volanea marketplace connection.

The integration model: Bonjoro event, middleware, Volanea email

Bonjoro does not provide a native Volanea app or marketplace plugin. The practical integration is an automation route: Bonjoro supplies an event to an automation platform such as Zapier or Make, that platform calls a small server endpoint you control, and the endpoint sends the final email through Volanea’s REST API.

This architecture is worth being explicit about because there are two different messages involved:

  1. A Bonjoro message or activity is the event that starts the workflow.
  2. A Volanea email is a separate transactional email sent because that event happened.

For example, a customer-success team may create a Bonjoro for a newly upgraded account. That creation can trigger an internal notification to the account owner, a confirmation email with next steps, or an operational message to a connected system. It should not silently replace the actual Bonjoro video message.

The route looks like this:

Bonjoro: New Bonjoro Created
        ↓
Zapier or Make: map and POST only approved fields
        ↓
Your HTTPS middleware endpoint
        ↓
Volanea REST API
        ↓
Recipient inbox

This has an important security benefit: the Volanea key stays on a server you operate. Bonjoro and the automation platform only need permission to invoke a restricted endpoint; they do not need the credential that can send email for your domain.

What actually triggers the send in Bonjoro

The concrete trigger for this pattern is Bonjoro’s New Bonjoro event in its Zapier integration. Zapier describes that trigger as firing when a new Bonjoro is created. In Make, use the corresponding Bonjoro watch trigger available in the Bonjoro application and inspect the module’s output before building mappings.

“Created” matters. It means the automation begins when the Bonjoro record is created, not necessarily when a recipient watches the video, replies, or receives an email notification. If your process needs a post-send or post-view action, first confirm that the integration exposes that specific event. Do not treat “new” as a synonym for “sent” or “viewed.”

Choose the event that matches the business promise

Before connecting anything, write a plain-language rule. A good rule has one event, one audience, and one intended outcome:

  • “When a success manager creates a Bonjoro for an Enterprise contact, email the assigned account executive.”
  • “When a Bonjoro is created after a completed onboarding form, send the customer a written checklist.”
  • “When a Bonjoro is created for a trial account, notify the internal onboarding queue.”

Avoid rules such as “send an email whenever anything happens in Bonjoro.” Those rules are hard to explain to recipients, difficult to test, and likely to generate duplicates when a human creates a draft, corrects details, and creates another Bonjoro.

A creation trigger is particularly useful for internal workflow notifications because it is timely and does not depend on recipient behavior. It is less suitable for claiming that a customer has watched a video, completed onboarding, or interacted with the message. Those are separate states and must be driven by a separately verified trigger or an event from the system that owns the state.

Filter before sending

Put a Filter step immediately after the Bonjoro trigger in Zapier, or a filter between the Bonjoro module and HTTP module in Make. Common conditions include a matching template, a known tag, a valid recipient email, a lifecycle stage passed in from the source system, or an internal-only flag.

The filter has two jobs. First, it prevents a broad trigger from turning every Bonjoro into a mail event. Second, it ensures that the middleware receives enough data to make a safe decision. An API request can be technically valid while still being a bad message to send; filtering is where you stop that category of error.

Why a middleware route is the right implementation

A direct browser request from a Bonjoro page, embedded form, or client-side script is not appropriate for sending with Volanea. Any API key placed in browser JavaScript, a public URL, or a front-end configuration can be copied and used to send unauthorized email.

The same principle applies to a no-code automation action. A custom Webhooks action can technically carry an authorization header, but it makes secret rotation, access reviews, request validation, and replay handling harder. It also gives every editor of that automation a route to a sending credential. For a production sending domain, use the automation tool as a transport to your endpoint, not as the permanent home of your Volanea secret.

Your middleware can be a small serverless function, an edge function with a secure secret store, a conventional API service, or an automation platform’s secure code environment if it supports server-side secrets and appropriate controls. The implementation needs only a few responsibilities:

  1. Authenticate the request from Zapier or Make.
  2. Validate and normalize the event data.
  3. Reject messages that do not meet policy.
  4. deduplicate retry deliveries.
  5. call Volanea with the server-side API key.
  6. return a clear, fast status code.

A small endpoint is not needless complexity. It gives you one controlled place to apply rules that are otherwise scattered across visual automation steps: recipient allowlists, suppression checks, audit logs, idempotency, template selection, and error handling.

Keep the initial endpoint narrow

Start with a single endpoint such as POST /integrations/bonjoro/email. Require a separate shared secret in an Authorization header from Zapier or Make. This is not the Volanea API key. It is a distinct integration secret used only to prove that the request is allowed to reach your middleware.

Limit the request body to fields the endpoint needs. A useful initial contract is a Bonjoro identifier, recipient details, sender details if available, a template or tag, and any approved custom field needed for the email. Do not forward every field merely because an automation platform can map it.

Keeping the contract narrow reduces privacy exposure and makes contract changes visible. If someone adds a field later, it should be an intentional product and compliance decision, not an accidental consequence of selecting “all data” in a webhook step.

The payload shape in this integration

Because this route uses Bonjoro’s Zapier or Make integration rather than an unverified direct outbound Bonjoro webhook, there is no native Bonjoro HTTP webhook body to paste into Volanea. The automation platform receives the Bonjoro event and constructs the HTTP body sent to your middleware.

That distinction is useful: you control the payload contract. Configure the Webhooks by Zapier POST action, or Make’s HTTP Make a request module, to send JSON in the following shape. Map each value from the output of the Bonjoro New Bonjoro trigger in your own account.

{
  "event": "bonjoro.new_bonjoro",
  "bonjoro_id": "{{Bonjoro ID from the trigger}}",
  "recipient": {
    "email": "{{Recipient email from the trigger}}",
    "first_name": "{{Recipient first name from the trigger}}",
    "last_name": "{{Recipient last name from the trigger}}"
  },
  "bonjoro": {
    "template_name": "{{Template name from the trigger}}",
    "video_url": "{{Video URL from the trigger}}"
  },
  "context": {
    "account_name": "{{Mapped account or custom field}}",
    "owner_email": "{{Mapped owner email or custom field}}"
  }
}

The strings in double braces are mapping instructions, not literal values. Zapier and Make render field selectors differently in their editors, so select the equivalent output token from the Bonjoro trigger rather than typing the braces. Run a test with a real non-production Bonjoro and compare the received JSON with the example before enabling the workflow.

Map based on observed fields, not assumptions

Bonjoro data availability can differ by trigger, connected source, plan, and the way a Bonjoro was created. In particular, custom fields, source-system properties, template metadata, and a video link may not be present in every trigger sample. An empty mapping can become an empty string, a missing property, or a platform-specific null value.

Treat the trigger test panel as the source of truth for the fields available to your account. If recipient.email is absent, do not attempt to infer it from a name. If the workflow depends on a CRM owner email or lifecycle stage, pass that data into Bonjoro in a documented way or retrieve it from the system that owns it. Do not make delivery depend on a field that appears only in one sample record.

For a first production version, it is often safer to require only:

  • a stable Bonjoro ID for deduplication;
  • a valid recipient email;
  • a first name, if personalization is optional;
  • a template or event classification; and
  • one link or piece of context that is known to be available.

Everything else should be optional and guarded with defaults.

Working middleware code and Volanea field mapping

The following Node.js example accepts the JSON contract above and sends a Volanea email. It deliberately builds the Volanea request on the server, where VOLANEA_API_KEY is stored as an environment secret.

Use the endpoint and request fields from the Volanea REST API reference for your account if your API version differs. The important mapping is the same: Bonjoro’s recipient fields become the Volanea recipient, while Bonjoro context becomes safely escaped email content.

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

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

const seen = new Map(); // Replace with Redis, Postgres, or another shared store in production.

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

app.post("/integrations/bonjoro/email", async (req, res) => {
  const suppliedSecret = req.get("authorization") || "";
  if (!crypto.timingSafeEqual(
    Buffer.from(suppliedSecret.padEnd(128)),
    Buffer.from(`Bearer ${process.env.BONJORO_AUTOMATION_SECRET}`.padEnd(128))
  )) {
    return res.status(401).json({ error: "unauthorized" });
  }

  const { event, bonjoro_id, recipient = {}, bonjoro = {}, context = {} } = req.body;
  const email = String(recipient.email || "").trim().toLowerCase();

  if (event !== "bonjoro.new_bonjoro") {
    return res.status(400).json({ error: "unexpected event" });
  }
  if (!bonjoro_id || !/^\S+@\S+\.\S+$/.test(email)) {
    return res.status(422).json({ error: "bonjoro_id and recipient.email are required" });
  }

  const idempotencyKey = `bonjoro-created:${bonjoro_id}:follow-up-v1`;
  if (seen.has(idempotencyKey)) {
    return res.status(200).json({ status: "already_processed" });
  }

  const firstName = escapeHtml(recipient.first_name || "there");
  const accountName = escapeHtml(context.account_name || "your account");
  const videoUrl = String(bonjoro.video_url || "");
  const safeVideoLink = /^https:\/\//.test(videoUrl)
    ? `<p><a href="${escapeHtml(videoUrl)}">Watch your video message</a></p>`
    : "";

  const volaneaPayload = {
    from: { email: "updates@example.com", name: "Example Team" },
    to: [{ email, name: `${recipient.first_name || ""} ${recipient.last_name || ""}`.trim() }],
    subject: `Your next steps for ${accountName}`,
    html: `<p>Hi ${firstName},</p><p>Your Bonjoro message has been prepared. Here are the next steps for ${accountName}.</p>${safeVideoLink}`,
    text: `Hi ${recipient.first_name || "there"},\n\nYour Bonjoro message has been prepared. Here are the next steps for ${context.account_name || "your account"}.\n${videoUrl}`,
    tags: ["bonjoro", "follow-up"]
  };

  const response = 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(volaneaPayload)
  });

  const result = await response.json().catch(() => ({}));
  if (!response.ok) {
    console.error("Volanea send failed", response.status, result);
    return res.status(502).json({ error: "email_provider_error" });
  }

  seen.set(idempotencyKey, Date.now());
  return res.status(202).json({ status: "accepted", message: result });
});

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

The explicit field mapping is visible in volaneaPayload: recipient.email becomes to[0].email; the optional first and last names become to[0].name; the controlled sending identity is from; and the Bonjoro context is placed in the subject and content. The bonjoro_id does not need to appear in recipient-facing content, but it is essential for deduplication and logs.

Before deployment, replace updates@example.com with a verified sender identity that your application is authorized to use. Do not use an address copied from a trigger payload as the From address. That can break alignment, confuse recipients, and allow untrusted data to influence your sending identity.

Configure Zapier or Make without leaking credentials

In Zapier, create a Zap with Bonjoro as the trigger app and select New Bonjoro. Add a filter, then add Webhooks by Zapier as the action app. Choose a POST request, set the URL to your middleware endpoint, select JSON or application/json payload handling, and map the approved fields into the contract shown above.

Set an Authorization request header containing Bearer followed by your BONJORO_AUTOMATION_SECRET. This secret authenticates the automation to your middleware. It is not the Volanea API key.

In Make, use a Bonjoro watch module, add a filter, then use the HTTP module to make a POST request. Set Content-Type: application/json, add the same Authorization header, and compose the JSON body from the observed module output. Keep scenario editing permissions limited to people who need them.

Where the Volanea API key belongs

The Volanea API key belongs only in the middleware’s secret store: for example, an encrypted hosting-provider environment variable, a cloud secret manager, or a server-side deployment secret. Name it VOLANEA_API_KEY, load it at runtime, and do not print it in logs.

It must not be stored in:

  • a JavaScript bundle, mobile app, browser local storage, or public environment variable;
  • a Bonjoro note, custom field, or template;
  • a Zapier or Make body mapping visible to routine automation editors;
  • a Git repository, pasted code sample, or ticket comment; or
  • an email itself.

A sending key is powerful. Someone holding it can often send unwanted mail that damages domain reputation, consume paid sending capacity, or access sending-related metadata. Separate the automation secret from the Volanea credential so you can revoke the automation route without rotating your email-provider key, and vice versa.

Build content and deliverability controls around the event

The email generated from a Bonjoro event should make sense on its own. Recipients may receive it before, after, or independently of the Bonjoro notification due to queue timing, inbox filtering, or a manually created Bonjoro. State why they are receiving it and avoid implying that a video was watched or a conversation occurred unless your triggering event proves that fact.

Use a stable, verified sender identity. Configure domain authentication and alignment before using the flow for external recipients. Keep the From name consistent with the customer-success or onboarding experience, and provide a plain-text alternative as well as HTML.

Separate transactional follow-up from marketing

A triggered onboarding checklist or account-service notice may be transactional, but a promotional campaign is not made transactional merely because a Bonjoro was created. If the Volanea email contains offers, newsletters, broad product announcements, or marketing content, apply the consent, unsubscribe, preference, and regional compliance rules that govern your program.

This distinction also changes your engineering choices. Transactional messages should be narrowly scoped to the event, useful even without a promotion, and sent only to the person with a clear relationship to the action. Marketing messages require stronger audience governance and should not be attached to every personal video event as a shortcut.

Validate addresses before enqueueing mail whenever the source data is incomplete or imported. A syntax check in middleware catches obvious mistakes, but it does not prove a mailbox is deliverable. For list hygiene before a larger follow-up program, use an email address verification tool and maintain your own suppression process for hard bounces, complaints, and opt-outs.

When this breaks: failures specific to this hop

This integration has three distinct hops: Bonjoro to Zapier or Make, the automation platform to your endpoint, and your endpoint to Volanea. Troubleshooting starts by identifying which hop failed instead of repeatedly re-running the entire workflow.

Retries can create duplicate sends

Automation platforms may retry a failed or timed-out webhook action. A retry is correct behavior from the platform’s perspective, but it can create two emails if Volanea accepted the first request and your endpoint failed before returning success.

Use a deterministic idempotency key based on the Bonjoro ID and the exact email purpose, as in bonjoro-created:<id>:follow-up-v1. Store processed keys in a durable shared system with a retention period appropriate for the business process. An in-memory Map is only illustrative; it resets on deployment and does not work across multiple server instances.

Also pass the idempotency key to Volanea when supported by your API version. This provides a second line of defense if your process sends the same request twice. Do not deduplicate solely by recipient email: one recipient may legitimately receive separate messages for separate Bonjoros.

Webhook timeouts cause ambiguous outcomes

Your middleware should validate input, enqueue or send, and return promptly. If it spends too long rendering content, querying multiple systems, or waiting on a slow downstream dependency, Zapier or Make may consider the request failed and retry it.

The safest production pattern is to validate the request, persist a job keyed by the Bonjoro ID, return a success response, and send asynchronously from a worker. If immediate send is acceptable, keep the endpoint fast and retain idempotency. Log the automation run ID, Bonjoro ID, idempotency key, Volanea response status, and provider message identifier where available.

An HTTP 2xx response should mean that the request was safely accepted for processing, not merely that the server parsed JSON. Conversely, return a 4xx error for permanently bad mapping data so you can fix the scenario, and use a 5xx error only for transient failures worth retrying.

Fields can be absent on some plans or records

Bonjoro trigger output is not a universal schema guarantee. Data exposed through the integration can vary with account plan, connected integrations, permissions, and how a particular Bonjoro was created. A custom field passed through from a CRM may be present for one contact and absent for another; a test record may include more data than a live record.

Make required fields explicit in middleware and treat optional fields as optional. For example, reject a request without bonjoro_id or recipient.email, but use “there” when first name is unavailable and omit the video link when no validated HTTPS URL exists. Alert on missing fields so a change in plan, permissions, or Bonjoro configuration becomes visible before it turns into a broken campaign.

The wrong trigger can send the wrong email

A New Bonjoro trigger can fire for drafts, internal test records, or messages that do not match the intended customer journey, depending on how the team uses Bonjoro. Add an explicit tag, template-name rule, or source-system condition instead of relying on a human convention such as “we only create Bonjoros for qualified customers.”

Test with a dedicated internal recipient first. Verify the Bonjoro record, the automation history, your middleware logs, the Volanea API response, and the delivered message headers. Only then enable external recipients.

Testing and release checklist

Treat this as an integration release, not a one-time automation. Use a test sender identity and internal recipient while validating the complete route. Confirm that content is correct when every optional field is present and when each optional field is absent.

A useful pre-launch checklist is:

  1. Create a test Bonjoro that matches the production trigger condition.
  2. Inspect the exact Bonjoro fields exposed in Zapier or Make.
  3. Verify the filter stops an intentionally non-matching Bonjoro.
  4. Confirm the middleware rejects a missing email and an unknown event.
  5. Trigger the same Bonjoro payload twice and confirm only one Volanea email is accepted.
  6. Verify From identity, reply handling, HTML, plain text, links, and personalization in a real inbox.
  7. Simulate a Volanea failure and confirm the automation does not create uncontrolled duplicates.
  8. Check logs contain identifiers but not API keys or unnecessary personal data.

After launch, monitor counts rather than relying only on individual success messages. Compare qualifying Bonjoros, middleware requests, accepted Volanea sends, bounces, and complaints. A sudden gap between Bonjoro events and accepted sends points to mapping or authentication trouble; a rise in accepted sends without a corresponding rise in qualifying events can point to retries or an overly broad filter.

Alternatives and when not to use this pattern

Use this integration when the Bonjoro creation is genuinely the event that should cause a specific email. It is a poor fit when the source of truth is elsewhere. If a CRM lifecycle-stage change, payment event, or form submission is the real business event, trigger Volanea from that source directly and use Bonjoro as a parallel engagement tool.

Direct triggering from the source system has advantages: more complete data, clearer ownership, fewer automation hops, and less ambiguity around a Bonjoro being created manually. It also avoids treating a customer-success artifact as the canonical record of a business state.

Similarly, do not use this route to turn a personal-video workflow into a bulk campaign engine. If the audience is large, the content is promotional, or the trigger is a broad list update, build a campaign process with deliberate segmentation and consent controls instead.

Conclusion

To send email from Bonjoro with Volanea reliably, use Bonjoro’s New Bonjoro automation trigger, filter it tightly, and forward a small mapped JSON contract through Zapier or Make to server-side middleware. Keep the Volanea API key exclusively in that middleware, not in Bonjoro, a browser, or a visible automation configuration.

The details that make the difference are not the HTTP POST alone. They are choosing the correct Bonjoro event, handling missing data, returning quickly, using durable idempotency for retries, and ensuring that the resulting email is appropriate for the recipient and event. With those controls in place, the integration remains understandable as it grows.

FAQ

Can I install a native Volanea integration from the Bonjoro marketplace?

No. This implementation uses Bonjoro’s automation-platform integration with Zapier or Make and a middleware endpoint. It is not a native Bonjoro marketplace app or plugin.

What Bonjoro trigger should start the Volanea send?

Use Bonjoro’s New Bonjoro trigger when creation of a Bonjoro is the intended business event. Add a filter for the template, tag, or source context that identifies eligible records.

Should I put my Volanea API key in Zapier or Make?

No. Store it as a server-side middleware secret. Give Zapier or Make a separate, limited integration secret for calling your endpoint instead.

How do I prevent duplicate emails when the automation retries?

Create a durable idempotency record from the Bonjoro ID and message purpose, such as bonjoro-created:<id>:follow-up-v1, before sending. Reuse that key for retried requests and pass it to the provider when supported.

What if the Bonjoro trigger does not include a field I need?

Do not guess or scrape it from another value. Check the trigger output in your account, make the field optional with a safe fallback, retrieve it from the system that owns it, or revise the trigger and workflow so the required data is available.