Sending email from Shoplazza with Volanea is best handled as a webhook-to-API integration: Shoplazza publishes a store event, your server verifies and maps it, and Volanea delivers the message. This approach avoids exposing an email API key in storefront code while giving you control over templates, retries, and duplicate prevention.

Shoplazza does not need a native Volanea marketplace app for this to work. The integration point is Shoplazza’s webhook system, using the orders/create event for a common transactional use case such as an order-received confirmation, a fulfillment follow-up, or an internal new-order alert. Your middleware receives Shoplazza’s POST request and makes the separate authenticated REST request to Volanea.

What this integration does

The workflow has three distinct systems, each with a deliberately narrow responsibility:

  1. Shoplazza creates an order and emits the orders/create webhook event to an HTTPS endpoint you control.
  2. Your middleware validates that request, extracts only the fields needed for an email, applies business rules, and records an idempotency key.
  3. Volanea accepts the final message through its email API and handles delivery from a domain you have authenticated for sending.

That separation is important. A customer’s browser should never call an email-delivery API with a reusable secret. Nor should an order event automatically become an email without validation: an order may be test data, lack an email address, be created twice during a migration, or be retried after a timeout.

For an initial implementation, use orders/create to send one message to an internal operations address. Once the pipeline is proven, adapt the same handler for customer emails. Customer-facing order receipts may overlap with Shoplazza’s own notification settings, so decide which system is the source of truth before enabling both. Sending two receipts is a worse customer experience than sending one slightly less customized receipt.

The Shoplazza trigger: orders/create

In Shoplazza, create a webhook subscription for the order created topic, represented in the webhook API as orders/create. Shoplazza sends an HTTP POST to the callback URL registered for that topic whenever it creates an order.

The callback URL must be publicly reachable over HTTPS. A URL such as https://store.example.com/hooks/shoplazza/orders-created is appropriate. A localhost URL works only through a temporary tunnel during development and must not be used as the permanent production endpoint.

Shoplazza’s order-created webhook payload is an order object. The exact object can evolve with API versions and store capabilities, so code against the fields you need, rather than assuming every possible nested field is present. For the email flow below, the useful top-level fields are the order ID, order number, customer email, currency, total price, line items, and timestamps.

A representative orders/create delivery has this shape:

{
  "id": "820982911946154508",
  "order_number": "1001",
  "email": "buyer@example.com",
  "currency": "USD",
  "total_price": "84.00",
  "created_at": "2026-10-13T10:22:18+00:00",
  "customer": {
    "id": "679865743273078447",
    "email": "buyer@example.com",
    "first_name": "Avery",
    "last_name": "Ng"
  },
  "line_items": [
    {
      "id": "1137115888170966272",
      "title": "Canvas Tote",
      "quantity": 2,
      "price": "42.00",
      "sku": "TOTE-CANVAS"
    }
  ],
  "shipping_address": {
    "first_name": "Avery",
    "last_name": "Ng",
    "address1": "123 Example Street",
    "city": "Austin",
    "province": "Texas",
    "zip": "78701",
    "country": "United States"
  }
}

Treat this as JSON received from an external system, not as trusted application data. In particular, do not concatenate product titles, names, or address fields directly into HTML without escaping them first. Product catalog data can contain quotation marks, markup-like characters, and occasionally unexpected values from imports or apps.

Why order creation is not always the right moment

orders/create means Shoplazza created an order record. It does not, by itself, express every business condition you may care about. A store that accepts manual payment, draft orders, POS orders, or imports may need to inspect payment and fulfillment values before sending a particular message.

For example, an internal “new order to pack” alert can be sent immediately. A “payment received” email should be based on the event or condition that actually represents payment for your store’s checkout flow. Keep the email trigger aligned to the promise in its subject line.

Why a middleware relay is the secure design

It is tempting to point Shoplazza directly at an email API or add a Volanea key to JavaScript in a custom storefront component. Do not do that. Webhook delivery is an inbound server-to-server mechanism, whereas Volanea authentication is a sending credential with the ability to generate email under your domain.

With the webhook relay pattern, the Volanea API key lives only in the environment-variable or secret-management facility of your serverless function, container, or application host. On the Shoplazza side, save only the callback URL and the Shoplazza webhook verification secret required to authenticate deliveries. The browser receives neither secret.

This gives you several practical protections:

  • A customer viewing page source cannot copy a sending credential.
  • You can rotate the Volanea key without changing Shoplazza checkout code.
  • You can verify the webhook signature before spending email API capacity.
  • You can reject malformed payloads and prevent duplicate sends.
  • You can log a delivery-safe event ID and outcome without storing full customer data indefinitely.

Use separate credentials for development and production. A development Shoplazza store should send only to a sandbox or controlled recipient list, and it should use a different Volanea API key and sender domain from production.

Configure Shoplazza and Volanea before writing code

First, authenticate the domain that will appear in the From address in Volanea. Authentication generally involves DNS records for domain ownership and email authentication; complete the records shown for your Volanea sending domain before testing. A verified sender is not merely a cosmetic requirement: aligned domain authentication is foundational to recipient trust and deliverability.

Next, create a least-privilege Volanea API key for the integration and store it as VOLANEA_API_KEY in your server environment. Store the sender address as VOLANEA_FROM, for example orders@updates.example.com, so that a sender-domain change is configuration rather than a code edit. The email API reference and setup guides should be your source of truth for the active endpoint, authorization scheme, and request fields in your Volanea account.

Then register the Shoplazza webhook callback for orders/create. Use a unique endpoint per environment, such as:

Production:  https://api.example.com/webhooks/shoplazza/orders-created
Staging:     https://staging-api.example.com/webhooks/shoplazza/orders-created
Development: https://dev-tunnel.example.net/webhooks/shoplazza/orders-created

Do not reuse a production webhook destination for test orders. Doing so creates confusing analytics, risks emailing real people from test data, and makes an incident much harder to investigate.

Keep the sender identity stable

A customer should recognize the sending domain and the visible display name. For an order message, Example Store Orders <orders@updates.example.com> is clearer than a personal address or a generic no-reply sender with no brand context. Make the reply path intentional too: an order exception may need a monitored support mailbox, while an automated internal alert can use a non-reply address.

Working webhook-to-Volanea example

The following Node.js example shows the complete mapping. It receives Shoplazza’s order-created JSON, validates required data, creates an idempotency key from the Shoplazza order ID, escapes dynamic HTML, and sends a Volanea REST email request.

Before deploying, confirm the current Volanea endpoint and payload contract in your account documentation. The request shown uses the standard transactional-message pattern of from, to, subject, html, and a bearer API key; keep those values centralized so they can be updated without changing webhook logic.

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

const app = express();
app.use(express.json({ limit: "1mb" }));

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

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

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

  // Map Shoplazza order fields to local variables.
  const orderId = String(order.id || "");
  const orderNumber = String(order.order_number || order.name || orderId);
  const recipient = order.email || order.customer?.email;
  const firstName = order.customer?.first_name || "there";
  const currency = order.currency || "";
  const total = order.total_price || "";
  const items = Array.isArray(order.line_items) ? order.line_items : [];

  if (!orderId) {
    return res.status(400).json({ error: "Missing Shoplazza order id" });
  }

  // A delivery may be retried. A durable store is required across processes.
  const idempotencyKey = `shoplazza-order-created:${orderId}`;
  if (sentOrderIds.has(idempotencyKey)) {
    return res.status(200).json({ received: true, duplicate: true });
  }

  // A missing customer email should not turn into a failed webhook loop.
  if (!recipient) {
    console.warn("Order has no email; no customer message sent", { orderId });
    sentOrderIds.add(idempotencyKey);
    return res.status(200).json({ received: true, skipped: "missing email" });
  }

  const itemRows = items.map((item) => {
    const title = escapeHtml(item.title || "Item");
    const quantity = escapeHtml(item.quantity || 1);
    const price = escapeHtml(item.price || "");
    return `<li>${title} × ${quantity}${price ? ` — ${escapeHtml(currency)} ${price}` : ""}</li>`;
  }).join("");

  const volaneaPayload = {
    from: process.env.VOLANEA_FROM,
    to: [recipient],
    subject: `We received order #${orderNumber}`,
    html: `
      <h1>Thanks, ${escapeHtml(firstName)}</h1>
      <p>We received your order <strong>#${escapeHtml(orderNumber)}</strong>.</p>
      <ul>${itemRows || "<li>Your order items are being prepared.</li>"}</ul>
      <p>Total: <strong>${escapeHtml(currency)} ${escapeHtml(total)}</strong></p>
    `,
    text: `Thanks, ${firstName}. We received order #${orderNumber}. Total: ${currency} ${total}.`
  };

  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)
  });

  if (!response.ok) {
    const detail = await response.text();
    console.error("Volanea send failed", { orderId, status: response.status, detail });
    // Return a failure only when your webhook retry policy and durable idempotency
    // store can safely handle it.
    return res.status(502).json({ error: "Email provider request failed" });
  }

  sentOrderIds.add(idempotencyKey);
  return res.status(200).json({ received: true, orderId });
});

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

The mapping is explicit: order.email or order.customer.email becomes the Volanea recipient; order.order_number becomes the subject reference; line_items become safe HTML list entries; and the order ID becomes an idempotency identifier. Do not use a volatile field such as the current timestamp to create that key, because it defeats duplicate detection.

The in-memory Set is only instructional. In production, use a durable shared store such as Redis, Postgres, DynamoDB, or your job queue’s deduplication facility. Mark the event complete only after Volanea accepts the request, or store a state machine such as received, sending, accepted, and failed if you need robust recovery.

Verify webhook authenticity before processing

The example focuses on payload-to-email mapping, but production code must validate Shoplazza’s webhook signature before parsing the event as trusted business input. Shoplazza webhook documentation specifies the signature header and the HMAC procedure for its current API version. Use the raw request bytes, calculate the HMAC with the Shoplazza webhook secret, and compare signatures with a timing-safe comparison.

This detail matters because reconstructing JSON before calculating the signature can change whitespace or key ordering. If the documented verification procedure signs the raw body, capture that raw body in your framework before JSON parsing. Also reject requests with an unexpected topic header; an endpoint intended for orders/create should not silently process another event type.

A good processing sequence is:

  1. Receive the HTTPS POST and retain the raw request body.
  2. Verify Shoplazza’s HMAC/signature and expected webhook topic.
  3. Parse JSON and validate the minimum schema required for this message.
  4. Look up the durable idempotency key for the Shoplazza order ID.
  5. Queue or send the Volanea request, then persist its accepted message identifier.
  6. Return a fast 2xx response only after the event is safely recorded for processing.

For higher-volume stores, put a queue between steps four and five. The webhook handler can persist the validated event and return promptly; a worker sends the Volanea message with controlled concurrency and retry behavior. That design protects checkout-event processing when the email provider or a downstream DNS route has a transient problem.

Build a useful email, not just a successful API call

A valid API response does not guarantee a useful transactional message. Order email should answer the question that caused the recipient to open it: was the order received, what was ordered, what happens next, and where can the buyer get help?

Keep personalization conservative. A first name and order number are helpful. Full shipping addresses, payment details, or excessive metadata can make a transactional message feel risky if it is forwarded or appears on a shared device. Include a link to the customer’s authenticated order-status experience where your store supports one, rather than packing every detail into the email.

Transactional versus promotional content

An order-received email is transactional. Adding a small product recommendation is not automatically prohibited, but it changes the message’s purpose and may trigger different consent, regional, and deliverability considerations. Keep the primary operational content prominent, and separate broad promotional campaigns from time-sensitive order communications.

Also avoid using a transactional webhook as a bulk campaign mechanism. If a catalog import or automation creates many order-like records, it can generate a surge of sends. Rate limits, suppression behavior, and recipient consent should be considered before enabling any event at scale. Review transactional email pricing when estimating the cost of event-driven sends and expected seasonal peaks.

When this breaks

A resilient integration plans for failures at the specific Shoplazza-to-middleware-to-Volanea hop, rather than treating all failures as generic “email problems.” The following are the most common cases.

Shoplazza retries and duplicate messages

Webhook systems retry when they do not receive a timely successful response or when a network connection fails at an ambiguous point. The dangerous case is: your middleware sends to Volanea successfully, but the response to Shoplazza does not arrive. Shoplazza can retry, and without idempotency the buyer receives two identical emails.

Use the immutable Shoplazza order ID plus the event purpose as the deduplication key, such as shoplazza-order-created:820982911946154508. Store it durably before or during processing. If Volanea supports idempotency headers for your endpoint, send the same key there as a second layer of protection; still keep your own record because delivery retry behavior belongs to your application logic.

Webhook timeouts

Do not make a webhook response wait on slow template rendering, inventory lookups, multiple APIs, or extensive reporting writes. Shoplazza expects a timely HTTP result. If your handler times out, it may retry even though part of your process has completed.

The robust answer is an inbox table or queue. Verify and persist the event quickly, return success, then perform the Volanea request asynchronously. This also lets you retry provider failures with exponential backoff without asking Shoplazza to redeliver the original order event indefinitely.

Missing or differently populated fields

Not every Shoplazza order has every field your email expects. Customer email can be absent for some order sources; customer can be absent or incomplete; shipping information may not exist for digital goods; and line_items should be treated as an array that can be empty or have unexpected optional properties. API version, store configuration, and enabled capabilities can affect the data available to a webhook.

Define a fallback for every nonessential field. The example uses order.email || order.customer?.email, uses “there” when a first name is unavailable, and skips the customer email entirely when no recipient exists. Alert your team on unexpected missing fields, but do not expose raw webhook payloads in error trackers without a retention and access policy because they can include personal data.

Volanea accepts the request but delivery is delayed

A successful Volanea API acceptance means the message entered the sending pipeline; it is not proof that it reached an inbox. Delivery can be affected by recipient-server response, mailbox suppression, sender authentication, content, and recipient address quality. Capture Volanea’s returned message ID in your database so support can correlate a Shoplazza order with provider events and investigate a customer report.

If you send customer-facing order mail, validate obvious email-address issues at checkout where possible and maintain a clear policy for hard bounces and suppressions. Do not repeatedly retry a known-invalid recipient just because the originating order webhook was delivered successfully.

Testing and release checklist

Test with a dedicated development store and an inbox you control. Start by logging a redacted event summary: order ID, event topic, recipient domain, item count, and Volanea response status. Once the basic path works, test the failure paths intentionally.

Your pre-production checklist should include:

  • Confirm the registered Shoplazza topic is orders/create and the callback uses HTTPS.
  • Verify Shoplazza webhook signatures with the current documented header and HMAC algorithm.
  • Confirm the Volanea sender domain is authenticated and the visible From address is approved.
  • Keep VOLANEA_API_KEY in server-side secrets, never in theme assets, browser JavaScript, or a public repository.
  • Create a durable unique constraint for the Shoplazza order ID plus message purpose.
  • Test an order without a customer email, without shipping data, and with special characters in product titles.
  • Simulate a Volanea 429, a 5xx response, and a webhook response timeout.
  • Check both HTML and plain-text versions in a real mailbox.

Finally, make a deliberate choice about ownership of each notification. Shoplazza may already send native store notifications for some commerce events. Disable or adjust overlapping notifications only after your Volanea version has been tested end to end, including support replies, sender display, and localization.

FAQ

Can I send email from Shoplazza with Volanea without a native app?

Yes. Use Shoplazza’s orders/create webhook to call a server-side endpoint, then have that endpoint call Volanea’s REST email API. This is more secure than embedding an email credential in storefront code.

Where should I store the Volanea API key?

Store it in your middleware host’s secret manager or encrypted environment variables. Shoplazza should store the webhook callback URL and its own webhook-verification secret, not the Volanea sending key.

What field should I use to stop duplicate emails?

Use the immutable Shoplazza order ID combined with the message purpose, such as shoplazza-order-created:<order-id>. Persist it in a durable database or cache with appropriate retention.

What if an order has no email address?

Do not attempt a customer send. Return a handled result after recording the skip, or route the event to an internal exception workflow. Do not substitute an address from an unrelated field.

Should the webhook handler send the email synchronously?

For low volume it can, provided it responds quickly and handles idempotency. For production reliability, verify and persist the webhook first, return a successful response, and send through a background queue or worker.