How to Send Email From Nosto With Volanea

Trying to send email from Nosto can reveal an important architectural distinction: Nosto is built to personalize commerce experiences and supply recommendation content, not to act as a general-purpose outbound email sender. The reliable implementation is therefore a server-side workflow in which your application, automation platform, or middleware combines a Nosto response with recipient data and asks Volanea to send the email.

This matters because it prevents two costly mistakes. First, it avoids exposing an email API key in browser code or a storefront theme. Second, it stops teams from treating recommendation rendering as if it were a marketing-automation trigger, which can lead to messages sent without clear consent, missing recipient context, or duplicate sends.

The short answer: there is no native Nosto-to-Volanea send action

Volanea does not provide a native Nosto marketplace app, embedded Nosto action, or one-click connector. More importantly, Nosto’s public integration model is centered on collecting commerce events, returning personalized content, and integrating with email service providers that own the actual send.

That means there is not a standard Nosto workflow action where you paste a Volanea API key and select “send email.” Nor should a browser-side Nosto integration call an email API directly. A browser can be inspected by a shopper, a bot, browser extensions, and anyone who can view your storefront assets; any API credential placed there must be treated as compromised.

The safe pattern has three separate responsibilities:

1. A send trigger occurs in the system that actually knows why an email is allowed to be sent: for example, an order-created event, an abandoned-checkout workflow, a back-in-stock subscription, or a customer’s explicit request for recommendations.
2. A server-side worker loads the relevant Nosto recommendation or personalization data, applies your message rules, and renders email-safe HTML.
3. Volanea receives the completed email over its REST API and handles SMTP delivery, provider authentication, delivery events, and suppression behavior.

In other words, Nosto enriches the email; it does not independently initiate delivery. This is not merely a limitation to work around. It is a useful separation of concerns: the commerce or lifecycle system controls consent and timing, Nosto controls merchandising logic, and the email provider controls transport.

What actually triggers the send

There is no general public Nosto outbound-webhook trigger on standard Nosto accounts that can be treated as “a customer entered a segment, now POST this arbitrary JSON to Volanea.” Do not build an integration around an assumed Nosto webhook, an invented marketplace installation, or a client-side callback that contains an email credential.

Instead, use a real business event from the system of record as the trigger. The most common choice is an order created event from the commerce platform. Other valid triggers include:

• a customer submitting a first-party “send me recommendations” form;
• a confirmed back-in-stock subscription;
• a scheduled lifecycle job that finds opted-in customers eligible for a replenishment message;
• an abandoned-checkout event from the platform or lifecycle system that owns the checkout data and consent state.

The Nosto-specific step starts after that trigger. Your worker sends a recommendation request to Nosto using the same customer, product, or cart context that Nosto needs to make a useful decision. It then uses the response to build the content of the email.

Why a Nosto browser event is not a sending trigger

Nosto is commonly present on storefront pages through JavaScript and commerce-event collection. A page view, product view, or cart update can be useful input for personalization, but it is not a trustworthy email-send trigger.

A visitor can reload the page, block tracking, modify a browser request, or visit from multiple devices. The event may also lack a verified email address, a consent record, a locale, and an unsubscribe context. Even if a page has an identified customer, a frontend event cannot safely carry a Volanea credential.

Treat frontend behavior as data that can influence a later, server-authorized campaign decision. Do not use it as a command to send an email.

The recommended trigger contract

A practical event entering the middleware can look like this. This is your middleware’s normalized event, not a claim that Nosto emits this payload:

{
  "event_id": "order-1000451",
  "event_type": "order.created",
  "occurred_at": "2026-10-09T14:12:31Z",
  "customer": {
    "id": "customer-781",
    "email": "mira@example.com",
    "first_name": "Mira",
    "marketing_email_consent": true
  },
  "order": {
    "id": "1000451",
    "currency": "USD",
    "items": [
      {"product_id": "sku-228", "quantity": 1}
    ]
  }
}

The commerce platform, CRM, customer-data platform, Zapier, Make, or a queue publisher can produce that event. The worker then uses customer.id, products, cart context, and locale to request Nosto content according to the Nosto API integration your account uses.

The distinction is deliberate: Nosto does not send a universal outbound email payload that contains to, subject, and html. Those are delivery decisions your integration must make from a consented customer record and the Nosto content it has retrieved.

The middleware route: Nosto data in, Volanea delivery out

A small server-side service is the most controllable option. It can run as a serverless function, queue consumer, container service, or endpoint in an existing application. Make or Zapier can also orchestrate the first and last steps if the source commerce platform has a connector, but use a server-side code step or an HTTPS endpoint for secrets and complex template rendering.

The workflow is:

1. Receive an authenticated order, subscription, or lifecycle event.
2. Deduplicate it using the source event ID.
3. Confirm that the customer has the required email consent.
4. Request the appropriate Nosto recommendation or personalization data server-to-server.
5. Validate that Nosto returned usable items.
6. Render a subject line and HTML using escaped values.
7. Send the final message through Volanea.
8. Store the Volanea message identifier and delivery state alongside the source event.

This allows Nosto’s logic to change recommendations without giving Nosto control over delivery frequency, list membership, authentication, or compliance handling.

Use a queue when sending is important

For non-critical, low-volume notifications, a synchronous endpoint may be enough. For revenue-bearing lifecycle mail, place the trigger event on a durable queue before fetching Nosto data or calling Volanea.

A queue improves failure isolation. If Nosto is temporarily unavailable, you can retry the recommendation lookup without losing the underlying order event. If Volanea returns a temporary delivery API error, you can retry the send with the same idempotency key rather than generating a new email every time the worker restarts.

Field mapping: from commerce context and Nosto output to an email

The exact fields returned by a Nosto recommendation request depend on the Nosto product, recommendation setup, and integration endpoint in use. Do not assume every response contains an email address, consent state, image URL, price, or product URL. In a sound design, recipient and consent fields come from your customer system, while product suggestions come from Nosto.

Use this ownership model:

Never interpolate recommendation fields into HTML without escaping them. Product names and URLs often originate in catalog systems, and a malformed value can break email markup. URLs should also be validated to ensure they point to a permitted host before being used in a link.

A concrete server-side implementation

The following Node.js example receives the normalized order.created event shown above. It illustrates the mapping into a Volanea REST send request. The Nosto lookup is represented as getNostoRecommendations() because its request URL, authentication, and response schema must match the Nosto API product enabled for your account; copying an unverified endpoint or payload into production is not safe.

The Volanea send request itself is deliberately isolated in sendWithVolanea(). Keep the exact endpoint and supported parameters aligned with the current email API reference and setup guides, rather than hard-coding a browser-side request.

import crypto from "node:crypto";

const VOLANEA_API_URL = process.env.VOLANEA_API_URL;
const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY;
const FROM = "Northstar Store <orders@mail.example.com>";

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

function allowedProductUrl(rawUrl) {
  const url = new URL(rawUrl);
  if (url.protocol !== "https:" || url.hostname !== "shop.example.com") {
    throw new Error("Recommendation URL is not an approved storefront URL");
  }
  return url.toString();
}

async function getNostoRecommendations({ customerId, productIds }) {
  // Call the Nosto server-side recommendation/personalization API enabled for
  // this account. Return a normalized list; do not expose Nosto credentials
  // to the browser. The adapter is where you map Nosto's actual response.
  // Example normalized return shape:
  return [
    {
      productId: "sku-991",
      name: "Merino Travel Sweater",
      url: "https://shop.example.com/products/merino-travel-sweater",
      imageUrl: "https://shop.example.com/images/merino-travel-sweater.jpg",
      price: "$129.00"
    }
  ];
}

function renderProducts(items) {
  return items.map((item) => {
    const name = escapeHtml(item.name);
    const price = escapeHtml(item.price);
    const url = escapeHtml(allowedProductUrl(item.url));
    const imageUrl = escapeHtml(allowedProductUrl(item.imageUrl));

    return `<tr><td style="padding:12px 0">
      <a href="${url}"><img src="${imageUrl}" alt="${name}" width="160" style="display:block;border:0" /></a>
      <p style="margin:8px 0 0"><a href="${url}">${name}</a></p>
      <p style="margin:4px 0 0">${price}</p>
    </td></tr>`;
  }).join("\n");
}

async function sendWithVolanea({ to, subject, html, idempotencyKey }) {
  const response = await fetch(VOLANEA_API_URL, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify({
      from: FROM,
      to: [to],
      subject,
      html
    })
  });

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

export async function handleOrderCreated(event) {
  const { customer, order, event_id: eventId } = event;

  if (!customer?.marketing_email_consent) {
    return { skipped: true, reason: "no_marketing_email_consent" };
  }
  if (!customer?.email || !order?.items?.length || !eventId) {
    return { skipped: true, reason: "missing_required_event_fields" };
  }

  const recommendations = await getNostoRecommendations({
    customerId: customer.id,
    productIds: order.items.map((item) => item.product_id)
  });

  if (!recommendations.length) {
    return { skipped: true, reason: "no_nosto_recommendations" };
  }

  const firstName = escapeHtml(customer.first_name || "there");
  const html = `<!doctype html><html><body>
    <p>Hi ${firstName},</p>
    <p>Thanks for your order. Based on your selection, you may also like:</p>
    <table role="presentation" width="100%">${renderProducts(recommendations)}</table>
    <p><a href="https://shop.example.com/email-preferences">Manage email preferences</a></p>
  </body></html>`;

  return sendWithVolanea({
    to: customer.email,
    subject: "You may also like these picks",
    html,
    idempotencyKey: crypto.createHash("sha256")
      .update(`nosto-recommendation:${eventId}`)
      .digest("hex")
  });
}

The field mapping in that code is explicit: customer.email becomes Volanea’s recipient; customer.first_name becomes a safely escaped greeting; Nosto-normalized name, url, imageUrl, and price become product content; and event_id becomes the idempotency key. No Nosto field is assumed to be a consent record or an email address.

Where the Volanea API key belongs

The Volanea API key belongs only in the secret store or environment configuration of the server-side component that calls Volanea. It does not belong in a Nosto storefront script, a theme setting visible in page source, a client-side tag manager variable, an email template, or a recommendation slot configuration.

If your automation starts in Make or Zapier, store the key in that platform’s encrypted connection or secret mechanism, not in a literal field that is copied between scenarios. If the automation invokes your own endpoint, keep the Volanea key in your endpoint’s secret manager and authenticate the automation with a separate shared secret, signed request, or short-lived credential.

Nosto has no native Volanea connection in which this key should be stored. That is an advantage, not an inconvenience: Nosto should never need the authority to send arbitrary email from your domain.

Use separate keys and least privilege

Create distinct credentials for development, staging, and production. Rotate a key promptly if it appears in a commit, support ticket, build log, browser bundle, or automation export. Restrict access to the people and services that actually administer sending.

Also authenticate the trigger that reaches the middleware. An unauthenticated public endpoint that accepts { "email": "..." } is an email-abuse endpoint waiting to happen. Verify the source signature where available, enforce an allowlist of event types, rate-limit requests, and reject recipients that are not tied to a valid first-party customer record.

Email design and deliverability implications

Personalized recommendation mail can perform well because it ties merchandising to a concrete customer moment. It can also perform poorly when it behaves like an unexpected promotion. The distinction is often determined by timing, frequency controls, clarity of the message, and whether the recipient expected marketing email.

For an order-confirmation-related message, consider whether recommendations are transactional or promotional under your applicable rules and customer expectations. Keep essential receipts and shipping notifications separate from non-essential cross-sell content when needed. Make sure your preference and unsubscribe treatment matches the class of message being sent.

On the sending side, authenticate the domain used in the from address with the DNS records Volanea provides for your account. Use a stable, aligned sending domain, preserve a readable reply path, and monitor bounces, complaints, and engagement. Sending a high volume of recommendation mail from a newly authenticated domain without warming or audience controls can damage inbox placement for more important mail.

Keep content resilient when Nosto has no result

Nosto may intentionally return no recommendation, or an item may become unavailable between selection and send. Decide the fallback before launch:

• Skip the recommendation email entirely when no eligible items are available.
• Use a pre-approved category block selected by your own catalog rules.
• Send the operational message without an upsell block if it is otherwise required.
• Delay the lifecycle message until the next scheduled eligible event rather than retrying the same customer repeatedly.

Do not replace missing recommendations with arbitrary products without merchandising approval. A poor fallback can be worse than no personalized block at all.

When this breaks: failures in the Nosto-to-email hop

This workflow has more than one network call, so it needs explicit failure behavior. The important rule is to distinguish a failed lookup from an unknown send result. Retrying both in the same way is how duplicate email happens.

Duplicate sends after retries

A trigger source may retry when your endpoint returns a timeout or 5xx response. Your worker may also retry after a network interruption while waiting for Volanea’s response. In the second case, Volanea may have accepted the message even though your worker never received the success response.

Use a stable idempotency key based on the business event and message purpose, such as order-1000451:post-purchase-recommendations. Store a durable record before or alongside the send attempt. On a retry, look up the event key first; if it has already completed, return success without creating another message.

Do not use the current timestamp as the idempotency key. Every retry would then look like a new send.

Timeouts and slow recommendation lookups

Nosto lookup latency, catalog issues, or an unavailable upstream service can make a synchronous request exceed the trigger source’s timeout. A source may then retry even though the first request is still running.

Acknowledge a validated incoming event quickly after placing it on a queue. Let a worker perform the Nosto lookup and Volanea call outside the request-response window. Apply bounded retries with exponential backoff for transient errors, and send repeated failures to a dead-letter queue or alert channel for review.

Missing fields and account-dependent data

Not every Nosto configuration, response type, or plan includes the same data. A recommendation response can omit images, price values, localized titles, URLs, or results entirely. Customer identity may be unknown in a storefront interaction, and marketing consent may live only in a separate commerce or CRM platform.

Validate every required field at the integration boundary. Require a deliverable recipient, a verified consent decision where applicable, and complete product fields before rendering. Treat missing optional data as a template fallback condition, not as permission to substitute unverified values.

Product data that is valid on the web but invalid in email

A product link may be relative, an image may be blocked by a CDN policy, or a product title may contain characters that need HTML escaping. Email clients also have far stricter CSS support than a storefront.

Normalize URLs to absolute HTTPS URLs, use simple table-based email markup, provide useful alt text, and test with images disabled. Keep the product block short enough that a missing image does not make the message unreadable.

Testing the integration before production

Start with a test recipient on a non-production or restricted sending environment. Capture the normalized trigger event, the Nosto-normalized recommendation response, the rendered HTML, the Volanea API response, and the idempotency key. Redact email addresses, API keys, and customer attributes from ordinary logs.

Test at least these paths:

1. An opted-in customer with valid Nosto recommendations receives one correctly rendered email.
2. A customer without the required consent is skipped and no Volanea request occurs.
3. A Nosto response with no items follows the approved fallback path.
4. The same source event delivered twice results in one message.
5. A simulated Volanea timeout can be retried without duplicate delivery.
6. A malformed product URL or missing image is rejected or safely omitted.
7. The unsubscribe or preference link resolves correctly for the recipient.

After launch, monitor the count at every stage: source events received, events skipped for consent, Nosto results received, messages submitted to Volanea, bounces, complaints, and unsubscribes. A sudden mismatch between those counts is much easier to diagnose than an aggregate “email sent” metric.

Alternatives to a custom service

A custom middleware service is best when you need idempotency, catalog validation, sophisticated templates, high volume, or reliable observability. It is not the only choice.

A low-code route can use a commerce-platform trigger in Make or Zapier, an HTTPS request to a protected middleware endpoint, and a Volanea send action or REST request. Keep Nosto retrieval and template assembly inside a server-controlled step when it requires credentials or substantial logic. Low-code automation is convenient, but it still needs the same consent checks, deduplication, retries, and secret handling.

If your existing email platform already has a supported Nosto integration for recommendation blocks, it may be better to leave campaign orchestration there and use Volanea for transactional or application email. Choose the architecture based on ownership of consent, lifecycle logic, and reporting—not simply on whether one product can call another API.

Conclusion

The dependable way to send email from Nosto with Volanea is not a direct Nosto plugin. Use a trusted business event to authorize the message, retrieve Nosto personalization server-side, render validated email content, and submit the final email through Volanea with an idempotency key.

That approach keeps the Volanea credential out of public code, preserves consent boundaries, and gives your team a clear place to handle retries, fallbacks, logging, and delivery monitoring. Nosto remains valuable where it is strongest—choosing relevant commerce content—while Volanea handles the delivery infrastructure.

FAQ

Can Nosto directly send an email through Volanea?

No native Nosto-to-Volanea app or standard direct send action is available. Use a server-side middleware workflow that retrieves Nosto content and calls Volanea’s email API.

What Nosto event should trigger the email?

Use a trusted event from the system that owns customer consent and message timing, such as an order-created event, a confirmed subscription, or an authorized lifecycle workflow. A storefront page view or browser event is not a safe send trigger.

Can I put the Volanea API key in Nosto JavaScript or a storefront theme?

No. Any client-visible configuration can expose the key. Store it only in a server-side secret manager, protected automation connection, or backend environment variable.

How do I avoid duplicate emails when a trigger retries?

Create a stable idempotency key from the source event ID and message purpose, store the result durably, and reuse that key on every retry. Do not generate a new timestamp-based key for each attempt.

What should happen if Nosto returns no recommendations?

Choose an approved fallback: skip the promotional email, use a vetted category block, or send the operational message without personalized recommendations. Do not assume that every request will produce complete product data.