How to Send Email from Consentmo with Volanea

Consentmo is a consent-management app, not an outbound-email automation platform—but you can still send email from Consentmo safely when a visitor accepts your cookie banner. The correct architecture is Consentmo-triggered storefront JavaScript, a server-side endpoint you control, and Volanea’s REST email API.

What this Consentmo and Volanea integration does

This integration sends a transactional notification after a visitor accepts the Consentmo cookie bar. The most practical use case is an internal operational email, such as notifying a privacy or compliance mailbox that a new consent action occurred.

That distinction matters. Consentmo manages visitor privacy choices and consent records; it is not a customer-email database or a marketing-automation tool. A cookie-consent event normally does not include a visitor email address, so it is not a sound trigger for sending a message to the visitor unless you independently collected that address through a separate, lawful flow.

A safe flow looks like this:

1. A visitor accepts the Consentmo cookie bar on your Shopify storefront.
2. Consentmo runs a JavaScript snippet configured to activate after cookie-bar acceptance.
3. That script posts a small, deliberately defined event to a server endpoint you control.
4. Your server validates and deduplicates the event.
5. Your server calls Volanea’s POST /v1/send endpoint.
6. Volanea queues the transactional email from a verified sending domain.

The resulting email is generally sent to an internal address such as privacy@yourstore.com, compliance@yourstore.com, or a monitored support inbox. It can report a minimal event summary without turning consent data into an unnecessary tracking record.

The important limitation: Consentmo does not send an outbound webhook

Consentmo does not provide a native Volanea integration, marketplace plugin, or documented general-purpose outbound webhook that can directly call an arbitrary email API. Its documented integration model is centered on consent-aware storefront behavior, supported platform integrations, custom scripts, and its Storefront JavaScript API.

That means there is no Consentmo webhook URL field where you should paste https://api.volanea.com/v1/send, and there is no Consentmo-side place to store a Volanea secret key. Do not try to force a direct browser-to-Volanea request.

The concrete trigger available for this pattern is cookie bar acceptance. Consentmo documents JavaScript that can be activated when a customer accepts the cookie bar. Its newer Storefront JavaScript API also lets developers react to consent changes in custom storefront work. The event is a storefront/browser event, not a server-to-server webhook delivery.

This creates an important implementation consequence: Consentmo itself sends no outbound HTTP payload to Volanea. The JSON payload in this integration is one that your acceptance-triggered script creates and sends to your own server. That is better than inventing a webhook schema that Consentmo does not publish.

Choose the right email use case before building

A consent event can be operationally useful, but it should not become an excuse to email people unexpectedly or retain more personal data than necessary.

Good uses for an acceptance-triggered email

A notification can make sense when it supports a real operational process, for example:

• Alert a compliance inbox that a consent event occurred during a launch, migration, or audit window.
• Notify a store team when a customer uses a privacy-center process that your separate backend has already validated.
• Create a lightweight signal for a custom internal workflow, such as opening a compliance review task.
• Confirm that an acceptance-triggered custom integration is firing during controlled testing.

For ongoing production use, aggregate reports and Consentmo’s own consent records will usually be more useful than one email for every acceptance. Emailing an internal inbox for every banner interaction can create noise quickly on a high-traffic store.

Uses to avoid

Do not use this pattern to:

• Send a welcome email merely because someone accepted cookies.
• Treat cookie acceptance as marketing-email opt-in.
• Put a Volanea API key into a Shopify theme, Custom Pixel, GTM container, or browser-visible JavaScript.
• Copy consent cookies, full IP addresses, customer IDs, or raw preference objects into an email unless you have a documented purpose and retention policy.
• Assume Consentmo’s consent choice proves email marketing permission.

Cookie consent and email consent are separate permissions. A visitor can allow marketing cookies and still have no relationship with your email list. Conversely, a subscriber can opt into email while declining analytics or advertising cookies.

The architecture: Consentmo script to middleware to Volanea

The browser is the place where Consentmo knows that the visitor accepted the cookie bar. The server is the place where your Volanea secret key belongs. The middleware route connects those two environments without exposing sending credentials.

What runs in the storefront

Configure the following kind of script using Consentmo’s documented capability for JavaScript activated on cookie-bar acceptance. The exact placement and configuration depend on your Consentmo setup, so use its current help-center instructions rather than assuming an unverified dashboard label.

The script should send only the minimum event context your operational email needs. In this example, it sends an event type, a generated event ID, an ISO timestamp, and the current page path. It does not send a consent cookie, the visitor’s identity, or an email address.

What runs on your server

Your server receives the event at a route such as /integrations/consentmo/accepted. It then performs four jobs:

1. Validates that the payload is structurally acceptable.
2. Rejects unexpected event types and malformed values.
3. Uses the event ID as an idempotency value and stores it durably if this becomes a production workflow.
4. Sends a single transactional email through Volanea.

The middleware can be a Shopify app backend, an existing Node service, a serverless function, or an endpoint behind your application. The critical requirement is that it is server-side and has access to protected environment variables.

Working code: map the acceptance event into a Volanea email

The code below shows the complete mapping. The first part is the browser-side code that Consentmo activates after cookie bar acceptance. The second part is an Express route that sends the internal notification through Volanea.

// 1) Storefront script: configure this as JavaScript that runs after
// Consentmo cookie-bar acceptance. This is NOT a Volanea API call.
// It deliberately contains no Volanea credential.

(() => {
  const storageKey = "consentmo-acceptance-notification-id";
  const eventId = sessionStorage.getItem(storageKey) || crypto.randomUUID();
  sessionStorage.setItem(storageKey, eventId);

  const eventPayload = {
    source: "consentmo",
    event: "cookie_bar_accepted",
    eventId,
    occurredAt: new Date().toISOString(),
    pagePath: window.location.pathname
  };

  fetch("/integrations/consentmo/accepted", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    credentials: "same-origin",
    body: JSON.stringify(eventPayload)
  }).catch(() => {
    // Do not expose a secret or retry endlessly in the browser.
    // Your server monitoring should surface repeated failures.
  });
})();

// 2) Server-side middleware: Node 18+ with Express.
// Environment variables belong on this server, never in the storefront.

import express from "express";

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

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

app.post("/integrations/consentmo/accepted", async (req, res) => {
  const { source, event, eventId, occurredAt, pagePath } = req.body ?? {};

  if (
    source !== "consentmo" ||
    event !== "cookie_bar_accepted" ||
    typeof eventId !== "string" ||
    !/^[a-zA-Z0-9-]{16,128}$/.test(eventId) ||
    typeof occurredAt !== "string" ||
    Number.isNaN(Date.parse(occurredAt)) ||
    typeof pagePath !== "string" ||
    !pagePath.startsWith("/")
  ) {
    return res.status(400).json({ error: "Invalid consent event" });
  }

  // Production recommendation: insert eventId into a database table with a
  // UNIQUE constraint before sending. If it already exists, return 200 here.
  // That provides durable deduplication beyond Volanea's idempotency window.

  const safePath = escapeHtml(pagePath);
  const safeTime = escapeHtml(occurredAt);

  const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      // Reuse this exact value only when retrying this same logical event.
      "Idempotency-Key": `consentmo-acceptance:${eventId}`
    },
    body: JSON.stringify({
      from: process.env.VOLANEA_FROM,
      to: process.env.COMPLIANCE_NOTIFICATION_TO,
      subject: "Consentmo cookie-bar acceptance recorded",
      html: `<p>A visitor accepted the cookie bar.</p>
             <ul>
               <li><strong>Time:</strong> ${safeTime}</li>
               <li><strong>Page:</strong> ${safePath}</li>
               <li><strong>Event ID:</strong> ${escapeHtml(eventId)}</li>
             </ul>`,
      text: `A visitor accepted the cookie bar.\nTime: ${occurredAt}\nPage: ${pagePath}\nEvent ID: ${eventId}`
    })
  });

  const result = await volaneaResponse.json().catch(() => null);

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

  return res.status(202).json({ accepted: true, eventId, result });
});

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

The field mapping is intentionally direct:

The Volanea request uses POST /v1/send, Bearer authentication, JSON content, a verified sender, recipient, subject, HTML body, text fallback, and an Idempotency-Key. Volanea supports safe retries with that header, so a repeated request using the same key can return the original result rather than creating another email.

For additional request fields, templates, delivery events, and API behavior, use the Volanea email API reference and setup guides.

Where the Volanea API key belongs

The Volanea key belongs in a server-side secret store—not in Consentmo, not in Shopify theme code, and not in a browser-side configuration object.

In the example, the key is read from:

VOLANEA_API_KEY=sk_live_replace_with_your_secret
VOLANEA_FROM=Privacy Desk <privacy@your-verified-domain.example>
COMPLIANCE_NOTIFICATION_TO=privacy-ops@your-company.example

For a local environment, these values can live in a non-committed .env file. In production, store them in your host’s encrypted environment-variable or secret-management system. Limit access to deployment operators and the service that needs to send mail.

Why browser-visible configuration is unsafe

Any JavaScript delivered to a visitor can be inspected, copied, and replayed. A Volanea secret key in a theme file would allow anyone who finds it to send email through your account, consume sending capacity, damage your domain reputation, and potentially access API capabilities associated with that key.

Obfuscation does not solve this. A key placed in a minified script, a GTM variable, a Custom Pixel, an HTML comment, or a storefront metafield is still exposed. The browser should only call your own narrow-purpose endpoint. Your endpoint should decide whether a Volanea send is warranted.

Use a restricted integration boundary

Because the storefront request originates in a visitor browser, it is not equivalent to a signed Consentmo webhook. Treat it as untrusted input.

At minimum, your endpoint should:

• Accept only the one event type it needs.
• Allow only small JSON bodies.
• Validate timestamp and path formats.
• Rate-limit requests by IP and route.
• Use same-origin routing where possible.
• Avoid accepting a recipient, sender, subject, or HTML body from the browser.
• Construct all email fields on the server.
• Record structured logs without storing sensitive consent details unnecessarily.

If the notification has compliance, financial, or security consequences, use a Shopify app backend or another authenticated server-side signal rather than relying solely on a storefront event.

Verify the sending domain before testing

Volanea sends from domains that you have verified. Before running this integration, ensure VOLANEA_FROM uses an address on a verified domain in your Volanea account.

Do not begin with a customer-facing sender address that has not been authenticated. An unverified sender can cause the send request to be rejected, and a rushed sender setup can create deliverability problems later.

A sensible testing order is:

1. Verify a dedicated sending domain or subdomain in Volanea.
2. Send a simple server-side test email to an internal inbox.
3. Confirm the message appears with the expected From address.
4. Add the Consentmo acceptance-triggered script.
5. Accept the cookie bar in a private browsing session.
6. Inspect your server logs and confirm one event reaches Volanea.
7. Repeat the test to make sure your deduplication policy behaves as intended.

A successful API response means Volanea accepted the request for processing. It should not be interpreted as proof that the message has landed in the mailbox. For production notifications, monitor Volanea delivery events and keep an eye on bounces, suppressions, and provider responses.

When this breaks: troubleshoot this specific hop

This integration has three distinct hops: Consentmo’s acceptance-triggered browser script, your middleware endpoint, and Volanea’s email API. Troubleshooting is easier when you identify which one failed.

The script never runs after acceptance

First verify that Consentmo is active on the storefront and that the custom JavaScript is configured for the documented cookie bar acceptance condition. Test in a private window or clear the relevant consent state before each test; otherwise, the banner may not display again.

Use browser developer tools to check whether the request to /integrations/consentmo/accepted appears after acceptance. If it does not, the issue is in the Consentmo-side custom-script setup, theme placement, content-security policy, or JavaScript error—not in Volanea.

Do not scrape Consentmo’s banner DOM or bind code to button CSS selectors. Those are implementation details that can change. Use Consentmo’s supported acceptance-triggered script capability or Storefront JavaScript API for custom behavior.

“Consentmo retries caused duplicate sends”

Consentmo does not deliver a documented outbound webhook in this design, so there is no Consentmo webhook retry policy to configure. The request is made by browser JavaScript that your custom implementation runs after acceptance.

Duplicates can still happen. A visitor may accept, reload, return in another session, use multiple tabs, or encounter a client-side retry added by another script. Your server can also time out after Volanea accepted a request, leading an upstream process to retry.

Handle duplicates in two layers:

1. Use the same Idempotency-Key for retries of the same eventId when calling Volanea.
2. Store eventId in a database table with a unique constraint before or alongside processing.

Volanea’s idempotency protection is valuable for safe API retries, but durable application-level deduplication is still the right choice for an ongoing consent-notification workflow. It lets you set a business rule such as “at most one acceptance notification per browser session” or “at most one notification per anonymous event ID.”

The endpoint times out or returns 502

There is no Consentmo webhook timeout in this architecture. A browser request can still be interrupted when the visitor closes the page, changes networks, uses an aggressive privacy extension, or has a slow connection.

Your endpoint should return promptly after validating the request and recording the event. For higher reliability, write an event to a queue or database first, return a success response, then let a worker call Volanea. That prevents a slow downstream email API call from making the browser request appear failed.

If you retry the Volanea request, reuse the identical idempotency key and request body for that one logical notification. Do not generate a new idempotency key on every retry; doing so defeats the protection against duplicate messages.

Expected payload fields are missing

Consentmo does not post a standard webhook body in this flow, so fields such as customer email, customer name, consent-record ID, plan name, or a canonical server timestamp are not available as a documented outbound payload. The acceptance-triggered script only has access to what the browser can safely and legitimately provide.

Design the payload contract around fields you own and can validate: eventId, event, occurredAt, and pagePath are enough for an internal operational notification. If your use case requires customer identity or a privacy-request record, obtain that information through a separate authenticated backend workflow rather than assuming a Consentmo storefront event provides it.

Avoid building plan-dependent logic around undocumented fields. If a field is not in Consentmo’s published Storefront JavaScript API reference or in an integration contract you control, treat it as unavailable.

Volanea rejects the request

Common causes include a missing or invalid Bearer key, a From address that is not on a verified domain, malformed JSON, or an invalid recipient. Log the HTTP status and safe response details on your server, but never log the secret key.

Also check that your sender environment variables are set in the runtime that actually handles the route. A variable present in local development but absent from a serverless deployment is a common source of unexpected authentication errors.

Privacy, consent, and deliverability implications

Sending an internal notification about a consent action is a processing activity of its own. Keep it proportionate to the purpose.

For example, an email containing “A visitor accepted the cookie bar at 10:32 UTC on /collections/summer” is generally less sensitive than a message containing an IP address, full consent-state object, identifiable cookie value, and browsing history. The latter adds retention, access-control, and disclosure concerns without necessarily improving the operational outcome.

Keep the email operational, not promotional

The Volanea message in this guide is transactional because it reports an internal operational event. It should not be repurposed into promotional content or a workflow that treats cookie acceptance as subscriber consent.

If you later need to send marketing campaigns, maintain a separate explicit email-opt-in process, retain proof of that opt-in, honor unsubscribes, and synchronize suppression status. Consentmo can help govern browser tracking consent, but it does not replace email-permission management.

Do not use email as your primary consent ledger

Consentmo’s consent records and privacy tools are more appropriate for consent-management evidence than a mailbox full of notifications. Email can supplement monitoring, but it is not a durable or queryable compliance database.

If you need an audit trail, write a minimal event record to a protected database with a defined retention period. Link it to a verified internal process, restrict access, and document why the record exists. Then send email only for exceptions, threshold alerts, or testing if that produces a more useful operational signal.

Alternatives when email is not the best destination

An email notification is simple, but it is not always the best response to a consent event.

Use Consentmo reporting for consent monitoring

If the goal is to understand acceptance and rejection patterns, Consentmo’s consent records and reporting are likely more useful than sending a message for every click. They keep the activity within the consent-management context and reduce inbox noise.

Send events to an internal database first

For an engineering or compliance workflow, persist a minimal event to your own database, then create aggregates: daily counts, sudden acceptance-rate changes, geographic anomalies where appropriate, or alerts when the banner stops producing events.

This approach gives you reliable deduplication, retention controls, and an audit-friendly query surface. Volanea can then send only the higher-value summary or alert.

Trigger email from a separate authenticated event

If you want to notify a customer about a privacy request, order withdrawal, or account action, use the authoritative server-side event for that workflow. Consentmo’s privacy features may help collect or manage the request, but the email should be sent from your backend once the request is authenticated and validated.

That architecture has stronger identity guarantees than storefront JavaScript and avoids treating an anonymous cookie-banner decision as an account-level event.

Production checklist

Before enabling the workflow for real traffic, review this checklist:

• Consentmo is installed and the cookie bar is functioning on the storefront.
• The custom JavaScript is configured to run after cookie-bar acceptance using Consentmo’s supported mechanism.
• The browser script sends no Volanea key and no unnecessary personal data.
• The middleware route accepts only a narrow, validated event schema.
• The route is rate-limited and monitored.
• eventId is stored with a database uniqueness constraint for durable deduplication.
• Volanea requests include Authorization: Bearer, Content-Type: application/json, and an Idempotency-Key.
• Your Volanea From address uses a verified sending domain.
• The recipient is an internal operational mailbox, not an arbitrary browser-provided address.
• You have tested acceptance, rejection, reloads, multiple tabs, API errors, and sender-domain failures.
• You have documented what event data is retained and why.

Conclusion

The dependable way to send email from Consentmo with Volanea is not a direct native integration, because Consentmo does not expose a general outbound webhook or native Volanea app for that purpose. Instead, use Consentmo’s real storefront trigger—cookie bar acceptance—to run a minimal browser script, post a controlled event to your backend, and let that backend call Volanea’s POST /v1/send API.

This separation protects your Volanea secret key, gives you a reliable place to validate and deduplicate events, and keeps consent data handling deliberate. Use it for internal operational notices or carefully designed workflows, not as a substitute for explicit email marketing permission.

FAQ

Can Consentmo send directly to Volanea’s API?

No. Consentmo does not provide a native Volanea integration or a documented general-purpose outbound webhook for direct calls to Volanea. Use Consentmo’s acceptance-triggered storefront JavaScript and your own secure middleware route.

What exactly triggers the email?

The trigger in this implementation is cookie bar acceptance. Consentmo supports activating JavaScript after a visitor accepts the cookie bar; that script sends a controlled event to your backend, which sends the email through Volanea.

Where do I put the Volanea API key?

Put it in a server-side environment variable or secret manager used by your middleware. Never place it in Consentmo custom JavaScript, a Shopify theme, GTM, a Custom Pixel, or any client-visible configuration.

Does accepting cookies mean I can email the visitor?

No. Cookie consent is not the same as email marketing consent. A Consentmo acceptance event usually does not provide a visitor email address and should not be treated as permission to send promotional email.

How do I prevent duplicate notifications?

Use a stable event ID, store it in a database with a unique constraint, and pass a derived value as Volanea’s Idempotency-Key. Reuse the same key only when retrying the same logical send.