Bigin can be the system that knows when a customer reaches an important moment; Volanea can be the system that delivers the message. This guide shows how to send email from Bigin without pretending there is a native Volanea app or marketplace installation: Bigin triggers a workflow webhook, your server translates the event, and Volanea sends the email.

That separation is deliberate. Bigin is a CRM, while Volanea is email infrastructure. A small middleware endpoint between them gives you a safe place for credentials, validation, templates, logging, and duplicate protection—things that should not be embedded in a CRM workflow configuration.

The integration architecture

There is no native Volanea listing, plugin, or one-click connector for Bigin. The practical direct integration uses Bigin’s workflow automation and webhook capability to notify an application endpoint when a record meets your chosen condition.

The basic flow is:

A Bigin Pipeline record reaches a selected stage, such as “Won” or “Demo booked.”
A Bigin workflow rule runs and sends an HTTP request to your HTTPS endpoint.
Your endpoint authenticates and validates the request, normalizes Bigin fields, and decides whether an email should be sent.
The endpoint makes a server-to-server request to Volanea’s email API.
Volanea queues the message and returns a response your application can log against the Bigin record ID.

This is not merely an extra hop. It prevents an API key from being exposed to a browser or copied into a broad set of automation settings. It also gives you an idempotency boundary: if Bigin retries the webhook, the middleware can recognize that the same CRM event has already produced an email.

For teams that prefer a no-code relay, Make or Zapier can sit in the middle instead. That can be useful for a simple notification, but a dedicated endpoint is generally the better choice for customer-facing transactional messages because you control secrets, observability, error handling, and sending policy.

Choose the Bigin trigger before writing code

A good integration starts with a business event, not with an email action. In Bigin, Pipeline records move through stages, so a stage transition is usually more reliable than a broad “record updated” event.

For this guide, the concrete trigger is: a Pipeline record is updated so that its Stage becomes Won. The workflow rule should be scoped to the relevant pipeline and should use a condition that matches the exact stage value your team uses.

Why a stage change is a useful trigger

A newly created contact is often too early to send a customer email. The contact might have been imported, may be incomplete, or may not have opted into the communication. A Pipeline stage is usually closer to an intentional business milestone.

A “Won” stage can drive messages such as:

A welcome email after a new customer signs.
A handoff email that introduces an account manager.
A confirmation message after a service purchase.
An internal notification to an operations inbox.
A request for the next required document or onboarding step.

The same pattern works for other Bigin events. You might send when a record enters “Appointment confirmed,” when a contact is created by a web form, or when a custom checkbox becomes true. The important rule is to select one event whose meaning is clear and then make the workflow conditions narrow enough that routine edits do not accidentally resend the message.

Set up the workflow action in Bigin

In Bigin, create a workflow rule for the Pipeline module and configure it to run on record edit when the record satisfies the stage condition. Add a webhook action that calls an HTTPS URL controlled by your application, for example:

POST https://crm-events.example.com/bigin/won

Use a dedicated endpoint per event type when possible. A URL named /bigin/won is easier to secure and reason about than one generic endpoint that has to infer dozens of unrelated workflows from loose request data.

The webhook action should include the record identifier, the current stage, the recipient email, recipient name, and any business data the email needs. Do not send every CRM field by default. Data minimization reduces accidental exposure of notes, phone numbers, internal comments, or fields that should never leave Bigin.

Understand the webhook payload Bigin delivers

Webhook request content is configured as part of the Bigin webhook action. In other words, Bigin does not force every workflow into one universal, immutable event envelope: the request parameters or body are the fields you choose to pass from the Pipeline record.

For a JSON webhook body, configure the action to deliver a body with this shape after Bigin has substituted the selected record values:

{
  "event": "pipeline.stage_won",
  "record_id": "5725767000000419001",
  "pipeline_name": "Customer onboarding",
  "stage": "Won",
  "contact_email": "ada@example.com",
  "contact_name": "Ada Lovelace",
  "owner_email": "success@example.com"
}

The field mapping is the substance of the integration. Map record_id from the Pipeline record’s ID field; stage from its Stage field; and the contact fields from the related Contact fields available to the workflow. If the Pipeline record does not always have a related contact or the contact’s email is optional, account for that in your middleware. A blank merge value is not a valid reason to call an email API.

Keep the event contract small and explicit

Treat the body above as a versioned contract between Bigin and your application. Avoid making your email sender depend on a human-readable pipeline name alone, because an administrator can rename it. The record ID and your own endpoint path make better technical identifiers.

The most useful minimum body is often:

{
  "record_id": "5725767000000419001",
  "stage": "Won",
  "contact_email": "ada@example.com",
  "contact_name": "Ada Lovelace"
}

Add a stable event value even when the URL implies the event. It makes logs easier to query and lets the endpoint reject a payload delivered to the wrong route.

A note on related-record fields

CRM data is rarely uniform. One Bigin Pipeline record may have a linked Contact and another may have only a Company. One contact may have an email address, while another has a phone number only. Before enabling the workflow, test it with representative records—not just the ideal record used during setup.

If Bigin cannot provide a related field in your workflow configuration or subscription, send the Pipeline record ID to middleware and have the middleware retrieve the record through the Bigin API using a server-side OAuth connection. That is more involved, but it is safer than trying to construct a recipient from incomplete webhook fields. It also prevents a workflow limitation from becoming a silent delivery failure.

Build a secure webhook receiver

Your receiver should accept only POST requests over HTTPS. It should parse JSON, enforce a reasonable body-size limit, validate the schema, and return quickly. Do not put heavy rendering, database scans, or long external calls in a path that causes the CRM webhook to wait unnecessarily.

The following Node.js example uses Express. It assumes that the Bigin webhook body is configured to match the JSON contract shown above and that your Volanea account has a verified sender domain and a usable API key.

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

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

const sentEvents = new Set(); // Replace with Redis or a database in production.

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

app.post("/bigin/won", async (req, res) => {
  // Keep this shared value only in server-side environment configuration.
  if (req.get("x-bigin-webhook-secret") !== process.env.BIGIN_WEBHOOK_SECRET) {
    return res.status(401).json({ error: "Unauthorized webhook" });
  }

  const {
    event,
    record_id: recordId,
    stage,
    contact_email: contactEmail,
    contact_name: contactName = "there"
  } = req.body ?? {};

  if (event !== "pipeline.stage_won" || stage !== "Won") {
    return res.status(204).end(); // Not the event this endpoint accepts.
  }

  if (!recordId || !isEmail(contactEmail)) {
    // Log the record ID internally; do not send a malformed recipient to Volanea.
    return res.status(422).json({ error: "Missing record_id or contact_email" });
  }

  // One send per Bigin record and event. Persist this key with a unique constraint.
  const idempotencyKey = crypto
    .createHash("sha256")
    .update(`bigin:${event}:${recordId}`)
    .digest("hex");

  if (sentEvents.has(idempotencyKey)) {
    return res.status(200).json({ status: "already_processed" });
  }

  const emailResponse = 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: "Acme Customer Success <success@updates.example.com>",
      to: [contactEmail],
      subject: "Welcome to Acme, " + contactName,
      html: `<p>Hi ${escapeHtml(contactName)},</p>
             <p>Your onboarding can now begin.</p>
             <p><a href="https://app.example.com/onboarding">Start onboarding</a></p>`,
      text: `Hi ${contactName},\n\nYour onboarding can now begin.\nhttps://app.example.com/onboarding`,
      tags: [
        { name: "source", value: "bigin" },
        { name: "pipeline_record_id", value: String(recordId) }
      ]
    })
  });

  const responseBody = await emailResponse.text();

  if (!emailResponse.ok) {
    console.error("Volanea send failed", {
      status: emailResponse.status,
      recordId,
      responseBody
    });
    return res.status(502).json({ error: "Email provider rejected the send" });
  }

  sentEvents.add(idempotencyKey);
  console.info("Volanea email accepted", { recordId, responseBody });
  return res.status(202).json({ status: "queued" });
});

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

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

This example maps Bigin’s contact_email to Volanea’s to, maps the selected contact name into the subject and message content, and uses the Bigin record_id to create a deduplication key. The sender address must be from a domain you have authenticated for sending in Volanea.

Use your actual Volanea API endpoint and request fields as specified in the email API reference and setup guides. API contracts can evolve, so the reference should be the source of truth for the endpoint, supported message fields, response format, and idempotency-header behavior.

Keep Volanea credentials out of Bigin

The Volanea API key belongs in the environment configuration of the middleware service, such as a secrets manager, encrypted deployment secret, or server-side environment variable. In the example, it is read only as process.env.VOLANEA_API_KEY.

Do not place that key in any of these locations:

A Bigin field, note, or record layout.
A workflow request body or query string.
Client-side JavaScript, a mobile app, or a browser-accessible configuration file.
A public repository, support ticket, screenshot, or shared spreadsheet.
An automation URL where it could appear in HTTP logs.

An email API key authorizes sending. If exposed, it can be used to send unwanted mail under your authenticated domain, which can create cost, abuse, and deliverability consequences long after the immediate incident.

Authenticate the Bigin-to-middleware hop too

The Volanea key protects the second hop. You should also protect the first hop—from Bigin to your endpoint. If the Bigin webhook configuration supports a custom header, add a high-entropy secret such as X-Bigin-Webhook-Secret and compare it on the server using a server-side secret. Rotate it when team access changes or if the workflow configuration may have been exposed.

If a custom header is unavailable in your configuration, use an unguessable path component as a limited shared secret, such as /bigin/won/<random-value>, and add network controls where feasible. A secret URL is weaker than a signed request, so do not treat it as the only protection for sensitive data. Log unexpected requests, rate-limit the route, and validate every field before sending.

Make the email useful, compliant, and deliverable

The technical send is only one part of the workflow. A Pipeline stage means a business state; it does not automatically establish that every type of email is appropriate. Distinguish operational, transactional communication from marketing campaigns.

A welcome message that confirms an onboarding action or gives a customer a necessary next step is commonly transactional. A general promotion, newsletter, or re-engagement campaign should follow your consent, suppression, and unsubscribe processes. Do not use a “Won” stage as a shortcut for emailing every person attached to a sales record.

Use a verified From domain

Send from a domain your organization controls and has authenticated with Volanea. Domain authentication helps mailbox providers assess whether the message is legitimate and aligns the visible From address with the infrastructure that sends it.

Choose a From identity recipients recognize, such as Acme Customer Success <success@updates.example.com>. Avoid sending a customer-success email from a personal salesperson’s address if replies will not be monitored. Set a reply path or Reply-To only when your process can handle incoming messages.

Keep CRM data out of HTML unless necessary

The example escapes contactName before putting it into HTML. This matters because names and custom fields are data, not trusted markup. A malicious or malformed value should never be able to inject HTML into an email template.

For more complex messages, store a template in your application or use Volanea’s supported templating capabilities if available in your account. Pass only the minimal variables: first name, product name, onboarding URL, and a record reference for internal tracing. Do not put sensitive CRM notes, contract details, or identity data in email merely because the webhook made them available.

When this breaks: Bigin webhook failure modes

Every integration should be designed around the ways it fails, especially at the boundary between a CRM workflow and an external HTTP service. The most common issue is not that Bigin or Volanea “stops working”; it is that an event is retried, a field is blank, or the receiver takes too long to answer.

Retries can create duplicate sends

A webhook sender may retry when it does not receive a successful response, when a network connection ends unexpectedly, or when your server returns a 5xx response. The difficult case is a timeout after your middleware has already submitted the message to Volanea but before Bigin receives your success response. Bigin may retry, and the same customer could receive two welcome messages.

The defense is idempotency. Create a stable key from the Bigin record ID plus the event type, persist it before or alongside the send result, and enforce a unique database constraint. Do not rely on an in-memory Set as shown in the short example; it disappears on a deployment and does not work across multiple server instances.

A production table might include event_key, bigin_record_id, event_type, volanea_message_id, status, created_at, and last_error. On a repeated event key, return a 2xx response without submitting a second send. If your Volanea API plan supports idempotency keys, pass the same key there as a second layer of protection.

Webhook timeouts are an architecture signal

Do not make the Bigin workflow wait for a slow email operation, a template-rendering call, and a database transaction. Acknowledge a valid webhook quickly after placing it into a durable queue, then let a background worker call Volanea.

The robust pattern is:

Validate the webhook and calculate the idempotency key.
Insert a queued event with a unique key.
Return a success response to Bigin.
Have a worker send the email and update the event status.
Retry worker failures with bounded backoff and alert on exhausted retries.

This design means a temporary Volanea API failure does not need to become a Bigin webhook failure. It also gives operations staff a clear record of whether the CRM event was received, queued, sent, rejected, or suppressed.

Some fields may be missing or unavailable

Workflow field availability can differ based on the module, related-record configuration, user permissions, and Bigin plan. A field you can view in a record is not automatically guaranteed to be available as a webhook merge value. Custom fields may also be blank on older records.

Build explicit validation for contact_email, record_id, and stage. If the email address is missing, do not substitute an owner’s email or guess a recipient. Save an internal exception with the record ID, then either correct the CRM record or use a server-side Bigin API lookup where your authorization model allows it.

Test a record with no linked Contact, no email address, a renamed stage, and an unexpected custom-field value. These are normal production states, not edge cases to postpone.

Changed stages and repeated business events need policy

A record can move from Won back to Negotiation and then to Won again. Should that send another welcome message? Usually not. But an annual renewal pipeline may legitimately need one confirmation per renewal cycle.

Write this rule into the idempotency key. For a one-time onboarding email, key it on record_id + event. For a renewal, key it on record_id + renewal_period or a stable transaction identifier. This is a product decision, not something the webhook can infer for you.

Use Make or Zapier when direct webhooks are not viable

If your Bigin edition, permissions, or workflow configuration does not expose the webhook action you need, use a middleware route through Make or Zapier rather than putting credentials in an unsafe place. Both services support Bigin-related automation patterns and HTTP requests, but their available triggers and fields should be checked in the connected account before you design around them.

The flow remains conceptually the same:

Bigin Pipeline record reaches Won
  → Make/Zapier receives the Bigin event
  → webhook or code step calls your middleware
  → middleware calls Volanea

You can also have Make or Zapier call the email API directly only if the platform can store the Volanea key as a protected connection or secret and the scenario is restricted to trusted administrators. Even then, direct automation calls are harder to test, version, and deduplicate than application middleware.

A practical hybrid is to use Make or Zapier for the Bigin trigger and lookup, but post only the normalized, minimal payload to your endpoint. Your service remains the sole holder of the Volanea key and the sole place that decides whether an event has already been sent.

Test the complete path before enabling it

Build a test checklist around outcomes, not just HTTP status codes. Create a non-production Pipeline record linked to a test mailbox and move it into the target stage. Confirm the Bigin workflow ran, the receiver logged the event, Volanea accepted it, and the message arrived with the expected From identity and content.

Use this pre-launch checklist:

Confirm the workflow condition matches the exact target Pipeline and Stage.
Verify the webhook body contains a real record ID and a valid recipient email.
Check that the endpoint rejects unauthorized requests and malformed bodies.
Move the same record through the event twice to confirm only one email is sent when that is your policy.
Test a blank contact email and confirm the event is safely held rather than sent elsewhere.
Verify the sender domain is authenticated and replies reach a monitored mailbox.
Check the message in Gmail, Outlook, and a mobile client for rendering and link behavior.
Record the Volanea message identifier, where available, alongside the Bigin record ID.

After launch, monitor both technical and business signals. Technical signals include webhook failures, 4xx and 5xx email API responses, queue age, and duplicate-event counts. Business signals include reply rates, onboarding completion, support contacts caused by confusing messages, and complaints or unsubscribes where applicable.

Operational recommendations for growing teams

Start with one event and one message. A narrowly scoped “Won → welcome email” workflow is easier to measure than a large collection of CRM triggers. Once it is stable, reuse the receiver pattern for appointment confirmations, document reminders, renewal notices, and internal alerts.

Separate configuration from code. Store the sending domain, From address, templates, and stage-to-template mapping in controlled configuration. Store secrets only in a secret manager. This keeps a copy change from requiring a deployment while ensuring an administrator cannot accidentally alter an API credential.

As message volume increases, review the cost and operational model for transactional email sending plans. The important comparison is not just a per-email number: consider retention, support needs, suppression handling, sending limits, and whether your workflow requires separate streams for transactional and marketing mail.

Finally, create a simple support playbook. When someone says “the Bigin email did not send,” the operator should be able to search by Bigin record ID, see the received event, find the idempotency key, inspect the Volanea response, and identify whether the issue was missing CRM data, an intentional suppression, an API rejection, or mailbox delivery after acceptance.

Conclusion

To send email from Bigin with Volanea, use Bigin as the source of the business event and Volanea as the sending service. A workflow webhook triggered when a Pipeline record reaches the Won stage can carry the relevant record data to middleware, where you validate it, protect the API key, prevent duplicates, and make a controlled REST API call.

That design is more durable than a fictional native connector because it gives you ownership of the important boundaries: credentials, data quality, retry behavior, templates, and auditability. Begin with a single stage-triggered transactional email, prove the event contract in testing, and expand only after the duplicate and failure paths are working as intended.

FAQ

Does Volanea have a native Bigin integration?

No native Bigin app or marketplace plugin is required for this approach. Connect Bigin workflow automation to your own middleware endpoint, then have that endpoint call Volanea’s REST API.

What Bigin event should trigger an email?

A Pipeline record moving to a specific Stage—such as Won—is a strong starting trigger because it represents a defined business event. Use exact workflow conditions so ordinary record edits do not trigger the same message.

Where should the Volanea API key be stored?

Store it only in server-side middleware environment variables or a secrets manager. Never place it in Bigin fields, webhook URLs, browser code, or a workflow payload.

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

Create and persist an idempotency key based on the Bigin record ID and event type. Return a successful response for repeats without submitting another message to Volanea.

What if the Bigin webhook does not include the contact email?

Reject or hold the event rather than guessing a recipient. Check whether the related Contact field is available to the workflow; if it is not, retrieve the record through a server-side Bigin API integration or revise the CRM process so the email is required before the stage transition.

How to Send Email from Bigin with Volanea