BigCommerce can trigger transactional messages at important points in the customer journey, but it does not need a native marketplace app to do it. This guide explains how to send email from BigCommerce with Volanea by connecting a native BigCommerce webhook to a secure middleware endpoint that retrieves order data and calls the Volanea email API.

This is a developer-led integration. BigCommerce emits an event when something happens in a store, your server receives and validates that event, and the server sends the appropriate email through Volanea. That pattern is more flexible than a prebuilt plugin because it lets you control templates, recipients, timing, deduplication, and the business rules that decide whether an email should be sent at all.

What this integration does

The practical flow looks like this:

A shopper places an order in BigCommerce.
BigCommerce creates an order and emits the store/order/created webhook event.
BigCommerce delivers a compact webhook payload to a URL you control.
Your middleware uses the order ID in that payload to retrieve the full order from the BigCommerce Orders API.
Your middleware maps order data into a Volanea email request.
Volanea sends the message using your verified sending domain and records the delivery lifecycle.

The important detail is that BigCommerce webhooks are notifications, not full order exports. The webhook tells your application that an order exists and includes an identifier for it. Your application should use that identifier to fetch the order before composing an email.

That extra request is useful rather than wasteful. It gives you a single place to apply business rules, such as sending an order confirmation only for paid orders, selecting a language from the storefront locale, suppressing a message for internal test orders, or choosing a template based on fulfillment method.

The BigCommerce trigger: `store/order/created`

For a basic order-confirmation email, the concrete BigCommerce trigger is the webhook scope:

store/order/created

BigCommerce sends this event when an order record is created. It is a good trigger for messages that should be initiated immediately after checkout, such as an internal new-order alert or a customer-facing “we received your order” email.

It is not automatically the right trigger for every customer message. An order can be created before your own definition of payment approval, fraud review, fulfillment, or shipment. If your confirmation email should only go out after a particular operational change, use the relevant order-status event and fetch the latest order state before sending.

What the webhook payload contains

A BigCommerce webhook callback contains a lightweight event envelope. For an order-created event, the body follows this shape:

{
  "scope": "store/order/created",
  "store_id": "1025646",
  "data": {
    "type": "order",
    "id": 250
  },
  "hash": "6f1c16d5f3c5d0647d75c56a37b0c2b6",
  "created_at": 1561479335,
  "producer": "stores/{store_hash}"
}

The fields your integration needs immediately are:

scope: confirms which event was emitted.
data.type: identifies the resource type, such as order.
data.id: the BigCommerce order ID to retrieve from the Orders API.
hash: an event identifier that is useful when recording or deduplicating webhook deliveries.
producer: identifies the store context.

Notice what is not in the example: the customer email address, the order total, the shipping method, line items, addresses, payment state, and custom fields. Do not assume those details are available in the webhook itself. Fetch the order from BigCommerce before creating an email request.

Why you need a middleware endpoint

A direct browser-to-email-provider connection is not safe. The Volanea API key authorizes sending email, so it must never be embedded in storefront JavaScript, theme files, page-builder markup, a client-visible environment variable, or a form action URL.

Instead, use a server-side endpoint you operate. It can run in a conventional application, a serverless function, a container service, or an integration worker. Its responsibilities are straightforward:

Receive the BigCommerce webhook over HTTPS.
Confirm the event is one your integration expects.
Validate the webhook according to BigCommerce’s webhook security guidance.
Return a successful response quickly.
Fetch full order details from BigCommerce.
Apply your sending rules and deduplication checks.
Call Volanea with the recipient, subject, and rendered content.
Log the event and the email-provider response without storing unnecessary personal data.

This architecture also separates commerce credentials from email credentials. BigCommerce credentials are used only to retrieve store data. Volanea credentials are used only from trusted server code to send mail.

Where the Volanea API key belongs

The Volanea key belongs in the middleware runtime’s secret store or encrypted environment configuration. Typical names include:

VOLANEA_API_KEY
VOLANEA_FROM_EMAIL
BIGCOMMERCE_STORE_HASH
BIGCOMMERCE_ACCESS_TOKEN

The key does not live in BigCommerce’s customer-facing storefront configuration. BigCommerce’s webhook registration only needs a destination URL; BigCommerce calls that URL, and your server owns the Volanea authentication step.

If you deploy on a platform such as Vercel, Cloudflare Workers, AWS Lambda, Render, Fly.io, or a container host, add the Volanea key through that platform’s server-side secret-management facility. Restrict access to production deployment environments and rotate the key if it is ever logged, copied into a repository, or exposed in a client bundle.

Register the BigCommerce webhook

BigCommerce webhooks are registered through the BigCommerce API. Your BigCommerce API account or app credentials need permission to create webhooks, and the credential used by your middleware needs read access to orders.

The following request creates an active order-created webhook. Replace the placeholder values before running it:

curl --request POST \
  --url "https://api.bigcommerce.com/stores/${BIGCOMMERCE_STORE_HASH}/v3/hooks" \
  --header "X-Auth-Token: ${BIGCOMMERCE_ACCESS_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{
    "scope": "store/order/created",
    "destination": "https://your-app.example.com/webhooks/bigcommerce/order-created",
    "is_active": true
  }'

The destination must be a public HTTPS endpoint. A localhost URL cannot receive production webhook deliveries from BigCommerce. During local development, use a secure tunnel only for testing, then replace it with your deployed endpoint before enabling the production hook.

Keep the webhook narrowly scoped. One endpoint can technically receive multiple event types, but a separate route or clear event dispatcher makes it easier to audit what is supposed to send email. For example, an order-confirmation route should not silently begin processing customer-created or cart-created events because someone changed a broad subscription later.

Give the middleware only the permissions it needs

The integration needs two distinct capabilities:

Webhook management, if your deployment process creates or updates subscriptions through the BigCommerce API.
Order read access, so the middleware can retrieve the full order after receiving the event.

Avoid using a broad administrative credential simply because it works. A credential limited to the required store and order access reduces the impact of an accidental leak. It also makes operational reviews easier: the service handling transaction email should not have permission to alter catalog data, change store settings, or manage unrelated integrations.

Fetch the full BigCommerce order before composing email

After receiving data.id from the webhook, retrieve the order from the BigCommerce Orders API. The order endpoint provides the customer and billing information that the minimal webhook notification does not include.

For example:

curl --request GET \
  --url "https://api.bigcommerce.com/stores/${BIGCOMMERCE_STORE_HASH}/v2/orders/250" \
  --header "X-Auth-Token: ${BIGCOMMERCE_ACCESS_TOKEN}" \
  --header "Accept: application/json"

The response includes fields such as the order ID, status_id, total values, currency, and billing_address. A customer-facing order confirmation commonly uses billing_address.email as the recipient when that value exists.

Do not blindly treat the billing email as universally available. Guest checkout, test orders, imported orders, manually created orders, privacy choices, and unusual checkout configurations can all produce records that do not fit the happy path. Your code should fail closed: if there is no valid recipient address, do not try to send a customer email.

You may also need line items. A separate order-products request lets you render purchased products, quantities, SKUs, and line totals. That is particularly valuable for detailed receipts and confirmations, but it adds another API request and another possible failure point. Start with a concise confirmation using the order number and total, then add line-item rendering once the core delivery path is reliable.

Working example: BigCommerce webhook to Volanea REST API

The example below uses Node.js with Express. It receives the BigCommerce event, fetches the order, maps the order into an email, and sends it through Volanea.

Before deploying it, configure the environment variables shown earlier. The sending address must be an address on a domain verified for use in your Volanea account. For API field definitions, authentication details, and account-specific sending requirements, use the Volanea REST API reference.

import express from "express";

const app = express();
app.use(express.json());

const {
  BIGCOMMERCE_STORE_HASH,
  BIGCOMMERCE_ACCESS_TOKEN,
  VOLANEA_API_KEY,
  VOLANEA_FROM_EMAIL
} = process.env;

async function getBigCommerceOrder(orderId) {
  const response = await fetch(
    `https://api.bigcommerce.com/stores/${BIGCOMMERCE_STORE_HASH}/v2/orders/${orderId}`,
    {
      headers: {
        "X-Auth-Token": BIGCOMMERCE_ACCESS_TOKEN,
        "Accept": "application/json"
      }
    }
  );

  if (!response.ok) {
    throw new Error(`BigCommerce order lookup failed: ${response.status}`);
  }

  return response.json();
}

async function sendVolaneaOrderEmail(order) {
  const recipient = order.billing_address?.email;

  if (!recipient) {
    console.log("Skipping order email: no billing email", { orderId: order.id });
    return { skipped: true, reason: "missing_recipient" };
  }

  const orderNumber = order.id;
  const currency = order.currency_code || "USD";
  const total = order.total_inc_tax || order.total_ex_tax || "0.00";

  const subject = `We received your order #${orderNumber}`;
  const html = `
    <h1>Thanks for your order</h1>
    <p>We received order <strong>#${orderNumber}</strong>.</p>
    <p>Order total: <strong>${currency} ${total}</strong></p>
    <p>We will send another email when your order status changes.</p>
  `;

  const response = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      from: VOLANEA_FROM_EMAIL,
      to: [recipient],
      subject,
      html
    })
  });

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Volanea send failed: ${response.status} ${body}`);
  }

  return response.json();
}

app.post("/webhooks/bigcommerce/order-created", async (req, res) => {
  const event = req.body;

  // Return 2xx only after basic event validation. In production, also validate
  // the BigCommerce webhook request using the authentication method configured
  // for your BigCommerce integration before processing the event.
  if (event.scope !== "store/order/created" || event.data?.type !== "order") {
    return res.status(204).end();
  }

  const orderId = event.data.id;

  try {
    // Production requirement: save an idempotency record keyed by event.hash
    // or a stable business key such as `order-confirmation:${orderId}` before
    // sending. This prevents retry deliveries from sending duplicates.
    const order = await getBigCommerceOrder(orderId);
    const result = await sendVolaneaOrderEmail(order);

    console.log("Order email processed", {
      orderId,
      eventHash: event.hash,
      result
    });

    return res.status(200).json({ ok: true });
  } catch (error) {
    console.error("Unable to process BigCommerce order webhook", {
      orderId,
      eventHash: event.hash,
      message: error.message
    });

    return res.status(500).json({ ok: false });
  }
});

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

Field mapping used in the example

The field mapping is deliberately simple:

BigCommerce source	Volanea email field	Purpose
`order.billing_address.email`	`to[0]`	Customer recipient address
`VOLANEA_FROM_EMAIL`	`from`	Verified sender address
`order.id`	`subject` and HTML content	Customer-facing order reference
`order.currency_code`	HTML content	Displays the order currency
`order.total_inc_tax` or `order.total_ex_tax`	HTML content	Displays the total

Keep the mapping explicit. Avoid passing a full order object into a template without selecting the fields you intend to expose. This reduces accidental disclosure of internal notes, payment metadata, full addresses, or other data that does not belong in an email.

Make the message production-ready

A basic order email proves the integration works. A production implementation needs stronger operational rules around content, consent, deliverability, and event handling.

Use a verified sender domain

Configure a domain you control for Volanea before sending customer mail. Domain authentication is fundamental to transactional-email deliverability because recipients and mailbox providers use authentication alignment to evaluate whether a message is legitimate.

Use a sender address that matches the customer’s expectation. A receipt from orders@yourstore.example is clearer than a generic address unrelated to the domain used at checkout. Set a monitored reply-to address if customers may have questions about order changes, returns, or fulfillment.

Keep transactional and marketing logic separate

An order confirmation is transactional: it communicates information necessary to the purchase. A discount campaign or product recommendation is marketing. Do not quietly turn a receipt into a promotional newsletter unless your consent and messaging policies support that use.

This distinction also makes template design better. Transactional mail should prioritize order identification, support details, next steps, and readability on mobile. Promotional content can be handled through a separate consent-aware workflow and audience model.

Render content safely

Product names, customer-entered text, and custom fields can contain punctuation or unexpected markup. Escape dynamic content before putting it in HTML. If you include product data, use a reliable HTML-escaping function and limit the length of user-controlled strings.

Build a plain-text alternative as well when your sending setup supports it. It improves accessibility, gives recipients a readable fallback, and makes it easier to inspect the essential message content during debugging.

When this breaks

Every integration has failure modes. The reliable approach is to identify the boundary where a failure occurred and make the next action safe to repeat.

BigCommerce retries can create duplicate sends

Webhook delivery is not a guarantee that your code ran exactly once. A timeout, network interruption, server error, or response failure can lead to another delivery attempt. If your endpoint sends the email and then fails before returning a success response, BigCommerce may retry while your first email has already been accepted.

Treat webhook processing as at least once delivery. Before calling Volanea, write an idempotency record to durable storage using one of these keys:

BigCommerce event hash, when you are deduplicating the precise webhook event.
A business key such as order-confirmation:{orderId}, when only one confirmation should ever be sent per order.
A more specific key such as shipment:{orderId}:{shipmentId}, when the same order can legitimately produce multiple emails.

Mark the record as processing, send the email, save the email-provider response, then mark it complete. If a retry sees a completed record, return a successful response without sending again.

Webhook timeouts make slow handlers fragile

Do not make the webhook endpoint do more work than necessary before acknowledging receipt. A slow order lookup, template rendering error, database lock, or email API delay can push the handler into a timeout path.

For higher-volume stores, separate acceptance from processing. Receive the webhook, validate it, persist the event, enqueue a job, and return a success response quickly. A worker can then fetch the order and call Volanea. This gives you controlled retries, backoff, observability, and a durable audit trail.

The queue does not remove the need for idempotency. It makes duplicate prevention more important, because both the webhook delivery system and your own job processor can retry work.

Webhook payload fields are intentionally limited

Do not diagnose a missing email address in the webhook as a mysterious plan-level failure. The order-created webhook is a compact notification and is not intended to contain every order field. Your implementation should always treat data.id as the input for a follow-up order lookup.

Even the full order can lack fields your template expects. Guest orders may look different from registered-customer orders. Imported orders may have incomplete data. Some storefront and checkout choices can change which attributes are collected. Make optional data optional in code, and use fallbacks such as “your order” instead of failing because a customer name is unavailable.

API credentials can expire, be revoked, or lose scope

A 401 or 403 from BigCommerce is different from a 4xx response from Volanea. Log the service, endpoint, status code, and event identifier so you can quickly tell whether the failing hop is BigCommerce authentication, order retrieval, email submission, or your own application.

Never log the full authorization header, Volanea API key, full raw order object, or an unredacted recipient address. Logs should be useful without becoming an uncontrolled copy of customer data.

A successful email submission is not the same as inbox placement

A successful response from the Volanea API means the provider accepted the send request. It does not mean a recipient has read the email or that every mailbox provider placed it in the primary inbox.

Monitor delivery events, bounces, complaints, and suppressions. If a customer says they never received an order confirmation, check the message lifecycle before simply resending it. A resend may be correct for a transient failure, but it is not a solution for an invalid address, a hard bounce, a suppression, or a sender-authentication problem.

Extending the integration beyond order confirmations

Once the order-created path is stable, the same architecture can support other operational emails. The key is to choose an event that represents the business moment you actually want to communicate.

Examples include:

Order-status notifications when an internal workflow changes an order state.
Shipment emails after shipment data is available.
Back-in-stock or support notifications initiated by a separate system.
Internal alerts when high-value orders are created.
Failed-payment or manual-review notices when your business process identifies them.

Do not reuse one generic template for every event. A customer needs different information after checkout than after shipment. Likewise, an internal warehouse alert may include line items and fulfillment notes that should never go to the customer.

Store template version information alongside each send. If a support team later investigates a confusing message, you can identify the exact template, event type, order ID, and send timestamp without guessing what content was live at the time.

Direct webhooks versus Zapier or Make

Native BigCommerce webhooks plus middleware are the strongest option when you need full control over authentication, idempotency, data enrichment, and email content. They are also the better choice when the store has meaningful volume or when order emails are operationally important.

Zapier or Make can be useful for early prototypes, low-volume internal alerts, or teams without application infrastructure. However, a no-code scenario still needs careful secret handling and duplicate control. The Volanea key should be stored in the platform’s protected connection or secret mechanism, not copied into a customer-visible field or an unprotected webhook URL.

A middleware endpoint remains useful even when an automation platform is involved. You can use the automation tool to trigger your endpoint, while keeping business logic, template rendering, and Volanea authentication in code you control.

Operational checklist before going live

Use this checklist before enabling customer-facing mail:

Verify the sending domain and sender address in Volanea.
Create the BigCommerce webhook with the narrow store/order/created scope.
Use a public HTTPS destination in production.
Validate incoming webhook requests before acting on them.
Fetch the full order using data.id; do not expect recipient data in the webhook payload.
Store an idempotency key before sending any customer message.
Test guest checkout, registered checkout, discount orders, failed test sends, and orders without optional customer fields.
Confirm the email renders on mobile and has a useful plain-text alternative where applicable.
Test a controlled retry so you know duplicate protection works.
Monitor Volanea delivery results and BigCommerce webhook failures after launch.

A small amount of discipline here prevents the two most damaging classes of transactional-email errors: customers receiving no confirmation at all, and customers receiving the same confirmation multiple times.

Conclusion

The dependable way to send email from BigCommerce with Volanea is a webhook-to-middleware-to-email-API workflow. BigCommerce emits store/order/created, your server receives the compact event, retrieves the complete order through the Orders API, and submits a carefully mapped message through Volanea.

That design keeps the API key off the storefront, lets you use real order data rather than assumptions, and gives you the control needed to handle retries without duplicate customer mail. Start with one event and one simple template, add durable idempotency before launch, and expand only after the first transactional flow is observable and reliable.

FAQ

Does Volanea have a native BigCommerce marketplace app?

No. This integration does not require a native BigCommerce app or marketplace plugin. It uses BigCommerce webhooks, a server-side endpoint, and the Volanea REST API.

What BigCommerce event should trigger an order confirmation email?

Use store/order/created when the email should begin as soon as BigCommerce creates the order. If your policy requires payment approval, fulfillment, or shipment first, choose an event tied to that later business state and retrieve the current order before sending.

Can I put the Volanea API key in my BigCommerce theme or storefront script?

No. Store the key only in server-side middleware secrets. Anything available to the browser can be copied and abused to send unauthorized email.

Why is the customer email missing from my webhook request?

The webhook body is a compact event notification. Use data.id to retrieve the full order through the BigCommerce Orders API, then read the recipient from the order data if it is present and valid.

How do I prevent duplicate order emails?

Make processing idempotent. Save a durable record keyed by the BigCommerce event hash or by a business key such as order-confirmation:{orderId} before calling Volanea, and skip sends for events already completed.

How to Send Email from BigCommerce with Volanea