How to Send Email from Cookiebot with Volanea

Cookiebot is a consent management platform, not an outbound automation platform—but you can still send email from Cookiebot safely by using its consent events as the trigger for a server-side email workflow. The important distinction is that Cookiebot runs in the visitor’s browser, while Volanea credentials and email delivery must remain on your server.

This guide shows the production-safe path: listen for Cookiebot’s real CookiebotOnAccept event, post a narrowly scoped consent payload to your own endpoint, validate and deduplicate it, and call Volanea’s REST API from that endpoint. There is no native Cookiebot app, marketplace installation, or Cookiebot dashboard webhook configuration in this flow.

What this integration does—and what it does not

Cookiebot CMP manages cookie and tracking consent on a website. Its browser script exposes a Cookiebot JavaScript object plus events including CookiebotOnConsentReady, CookiebotOnLoad, CookiebotOnAccept, and CookiebotOnDecline.

The concrete trigger used in this integration is CookiebotOnAccept. It runs when Cookiebot records an accepted consent state. The handler reads Cookiebot’s current category-level consent values:

• Cookiebot.consent.necessary
• Cookiebot.consent.preferences
• Cookiebot.consent.statistics
• Cookiebot.consent.marketing
• Cookiebot.consent.method
• Cookiebot.regulations.gdprApplies
• Cookiebot.regulations.ccpaApplies
• Cookiebot.regulations.lgpdApplies

That is useful for operational messages such as a consent-preference confirmation for a signed-in account holder, or an internal privacy-team notification that a specific authenticated user changed their preferences.

It is not a general “new contact” trigger. Cookiebot does not create CRM records, submit website forms, expose a customer email address in its public browser API, or provide a native workflow builder that can store a Volanea API key and call Volanea directly. Cookiebot’s consent log is separate from your application’s user database.

That separation is a feature, not an inconvenience. A cookie-consent choice does not inherently reveal someone’s identity. Your application should determine the email recipient from a trusted, authenticated server-side session—not from a browser-submitted email field.

The architecture: Cookiebot event, middleware, Volanea API

Use this four-part design:

1. Cookiebot CMP in the browser raises CookiebotOnAccept after the visitor accepts consent.
2. A small browser handler reads the current Cookiebot values and sends them to an endpoint on your own domain.
3. Your server endpoint verifies the authenticated user, validates the payload, creates a stable idempotency key, and decides whether an email is warranted.
4. Volanea’s REST API accepts the transactional message and dispatches it from a verified sending domain.

This route is deliberately server-mediated. It prevents your Volanea secret key from being visible in page source, browser developer tools, JavaScript bundles, tag-manager variables, or network requests from the visitor’s device.

It also gives you a reliable control point for business logic. For example, you may decide to send a confirmation only when marketing consent is newly enabled, only when the visitor is signed in, or only once per consent revision. Those conditions belong on the server, where they cannot be bypassed simply by editing a request in the browser.

Why there is no direct Cookiebot-to-Volanea request

Do not put a Volanea API key in a data-* attribute, a Cookiebot callback, a Google Tag Manager variable, a front-end environment variable, or a client-side fetch call. Anything delivered to a visitor’s browser must be treated as public.

A Volanea API key can authorize email sending. If exposed, it could be used to send abusive mail, damage your sending reputation, consume your sending allowance, or create an incident that requires key rotation and message-log review.

For this reason, the Volanea key lives nowhere on the Cookiebot side. Cookiebot does not have a server-side secret vault or native outbound HTTP action for this use case. Store the key only in your server or serverless platform’s encrypted environment-variable or secret-management system, such as VOLANEA_API_KEY.

Prerequisites before you send

Before adding code, prepare the pieces that make the workflow meaningful and safe.

1. Cookiebot CMP is installed on the site

The Cookiebot CMP script must already be loaded on the pages where you want to react to consent. Cookiebot’s public JavaScript API is created by its uc.js script. Your handler must be registered in a script that executes on the same page and is available when Cookiebot emits its event.

Do not confuse the Cookiebot script-download event with consent events. Cookiebot explains that CookiebotOnLoad is about loading an existing or newly submitted consent state, not simply about the uc.js file finishing download. For this workflow, CookiebotOnAccept is the specific acceptance trigger.

2. An authenticated application identity

The cleanest use case is a logged-in customer portal. The browser sends consent-category values, while the server reads the current account from a signed session or access token and looks up the recipient email in your own database.

If the visitor is anonymous, you can still record an anonymous event server-side, but you should not fabricate an email recipient. An anonymous Cookiebot consent record is not an email address.

3. A verified Volanea sending domain

Set up a sending address on a domain you have verified in Volanea before testing. A useful pattern is a dedicated operational address such as privacy@updates.example.com or no-reply@notifications.example.com.

Keep consent confirmations transactional and factual. Avoid promotional copy, tracking-heavy content, or wording that implies a marketing subscription where none exists. The purpose of the message should be to confirm a preference change or provide a record requested by the account holder.

4. A server endpoint under your control

This example uses POST /api/privacy/cookiebot-consent. It can be a Node server route, serverless function, edge function with secure secrets, or a backend endpoint in your existing application.

The endpoint needs to do more than forward JSON. It should authenticate the caller, validate booleans and strings, rate-limit requests, deduplicate repeated events, persist an audit record if appropriate, and call the email API only after those checks pass.

For endpoint details, authentication, sending options, and the complete REST reference, see the Volanea API documentation.

The real Cookiebot trigger and payload

Cookiebot itself does not POST an email-ready webhook payload to Volanea. Instead, it exposes consent state in browser JavaScript. Your integration creates an application payload from that documented state and posts it to your own backend.

That distinction matters when debugging. The JSON below is your browser-to-server payload, not a hidden Cookiebot webhook schema. The field values are mapped directly from Cookiebot’s public Cookiebot object.

// Load this after Cookiebot CMP is present on the page.
// It contains no Volanea secret and sends only consent metadata to your server.
window.addEventListener('CookiebotOnAccept', async function () {
  const eventId = crypto.randomUUID();

  const payload = {
    eventId,
    eventType: 'CookiebotOnAccept',
    occurredAt: new Date().toISOString(),
    pageUrl: window.location.href,
    consent: {
      necessary: Cookiebot.consent.necessary,
      preferences: Cookiebot.consent.preferences,
      statistics: Cookiebot.consent.statistics,
      marketing: Cookiebot.consent.marketing,
      method: Cookiebot.consent.method,
      hasResponse: Cookiebot.hasResponse,
      consented: Cookiebot.consented,
      declined: Cookiebot.declined
    },
    regulations: {
      gdprApplies: Cookiebot.regulations.gdprApplies,
      ccpaApplies: Cookiebot.regulations.ccpaApplies,
      lgpdApplies: Cookiebot.regulations.lgpdApplies
    }
  };

  await fetch('/api/privacy/cookiebot-consent', {
    method: 'POST',
    credentials: 'same-origin',
    headers: {
      'Content-Type': 'application/json',
      'X-Requested-With': 'XMLHttpRequest'
    },
    body: JSON.stringify(payload)
  });
});

Here is what that browser request looks like in concrete form:

{
  "eventId": "7b3daa82-4618-478e-8a30-f7f7cbf95a32",
  "eventType": "CookiebotOnAccept",
  "occurredAt": "2026-10-02T15:24:08.511Z",
  "pageUrl": "https://app.example.com/privacy/preferences",
  "consent": {
    "necessary": true,
    "preferences": true,
    "statistics": false,
    "marketing": true,
    "method": "explicit",
    "hasResponse": true,
    "consented": true,
    "declined": false
  },
  "regulations": {
    "gdprApplies": true,
    "ccpaApplies": false,
    "lgpdApplies": false
  }
}

Field mapping, explicitly

The mapping is intentionally direct:

Do not treat pageUrl, occurredAt, or the browser-generated eventId as inherently trustworthy evidence. A visitor can alter browser requests. They are useful operational inputs, but your server should add its own received timestamp, account identifier, session context, and database event ID.

Send the email from middleware with Volanea

The following Express-style Node.js route demonstrates the secure hop. It does four important jobs before sending:

1. It requires an authenticated account.
2. It validates the expected Cookiebot-derived payload.
3. It deduplicates the logical consent event.
4. It calls POST /v1/send from the server with the Volanea secret key and an Idempotency-Key header.

import express from 'express';
import crypto from 'node:crypto';

const app = express();
app.use(express.json({ limit: '20kb' }));

// Replace these examples with your real session middleware and database layer.
function requireAuthenticatedUser(req, res, next) {
  // Example only: your auth layer should set req.user from a signed session.
  if (!req.user?.id || !req.user?.email) {
    return res.status(401).json({ error: 'Authentication required' });
  }
  next();
}

function isBoolean(value) {
  return typeof value === 'boolean';
}

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

app.post('/api/privacy/cookiebot-consent', requireAuthenticatedUser, async (req, res) => {
  const { eventId, eventType, occurredAt, pageUrl, consent, regulations } = req.body ?? {};

  if (
    typeof eventId !== 'string' ||
    eventType !== 'CookiebotOnAccept' ||
    typeof occurredAt !== 'string' ||
    typeof pageUrl !== 'string' ||
    !consent ||
    !regulations ||
    !isBoolean(consent.necessary) ||
    !isBoolean(consent.preferences) ||
    !isBoolean(consent.statistics) ||
    !isBoolean(consent.marketing) ||
    !isBoolean(consent.hasResponse) ||
    !isBoolean(consent.consented) ||
    !isBoolean(consent.declined) ||
    !isBoolean(regulations.gdprApplies) ||
    !isBoolean(regulations.ccpaApplies) ||
    !isBoolean(regulations.lgpdApplies)
  ) {
    return res.status(400).json({ error: 'Invalid consent event payload' });
  }

  // Use a server-created stable key for the logical action.
  // A production system should persist this key with a unique database constraint.
  const idempotencyKey = crypto
    .createHash('sha256')
    .update(`cookiebot-consent:${req.user.id}:${eventId}`)
    .digest('hex');

  // Example: insert-if-absent on a table with UNIQUE(idempotency_key).
  // If this returns false, a retry has already been handled.
  const inserted = await db.consentEvents.insertIfAbsent({
    idempotencyKey,
    accountId: req.user.id,
    browserEventId: eventId,
    receivedAt: new Date().toISOString(),
    occurredAt,
    pageUrl,
    consent,
    regulations
  });

  if (!inserted) {
    return res.status(202).json({ status: 'already_processed' });
  }

  // Apply your own policy. This example confirms a change only after
  // Cookiebot reports an accepted consent state for the authenticated account.
  if (!consent.consented || !consent.hasResponse) {
    return res.status(202).json({ status: 'recorded_without_email' });
  }

  const summary = [
    `Necessary: ${consent.necessary ? 'on' : 'off'}`,
    `Preferences: ${consent.preferences ? 'on' : 'off'}`,
    `Statistics: ${consent.statistics ? 'on' : 'off'}`,
    `Marketing: ${consent.marketing ? 'on' : 'off'}`
  ].join('\n');

  const emailPayload = {
    from: {
      email: 'privacy@updates.example.com',
      name: 'Example Privacy'
    },
    to: [
      {
        email: req.user.email,
        name: req.user.name || undefined
      }
    ],
    subject: 'Your cookie preferences were updated',
    text: `We recorded your cookie preferences on ${occurredAt}.\n\n${summary}\n\nYou can review or change them from your privacy settings.`,
    html: `<p>We recorded your cookie preferences on ${escapeHtml(occurredAt)}.</p>
<ul>
  <li>Necessary: ${consent.necessary ? 'on' : 'off'}</li>
  <li>Preferences: ${consent.preferences ? 'on' : 'off'}</li>
  <li>Statistics: ${consent.statistics ? 'on' : 'off'}</li>
  <li>Marketing: ${consent.marketing ? 'on' : 'off'}</li>
</ul>
<p>You can review or change them from your privacy settings.</p>`
  };

  const volaneaResponse = await fetch('https://api.volanea.com/v1/send', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.VOLANEA_API_KEY}`,
      'Content-Type': 'application/json',
      'Idempotency-Key': idempotencyKey
    },
    body: JSON.stringify(emailPayload)
  });

  if (!volaneaResponse.ok) {
    const detail = await volaneaResponse.text();

    // Mark the event for retry or operator review in your own persistence layer.
    await db.consentEvents.markEmailFailed(idempotencyKey, {
      status: volaneaResponse.status,
      detail
    });

    return res.status(502).json({
      error: 'Email provider rejected or could not accept the message'
    });
  }

  const result = await volaneaResponse.json();
  await db.consentEvents.markEmailAccepted(idempotencyKey, result);

  return res.status(202).json({ status: 'email_accepted', result });
});

The key field mapping is now clear:

• Cookiebot’s category booleans become the text and HTML content of a transactional confirmation.
• The recipient is req.user.email, retrieved from your server-side authenticated account—not from Cookiebot and not from client JSON.
• Your verified sending identity becomes Volanea’s from object.
• The server-created idempotency key is used both in your database and in Volanea’s Idempotency-Key request header.

A successful API response means Volanea accepted the message for processing. It should not be interpreted as proof that the recipient has already received or opened the email. Treat acceptance, delivery, bounce, complaint, and suppression outcomes as separate states in your operational reporting.

Keep consent and marketing permission separate

This point is easy to miss: Cookiebot marketing-cookie consent is not automatically the same thing as consent to receive marketing email.

Cookiebot’s categories govern cookies and similar tracking technologies on the website. Email marketing permission may be governed by different wording, collection mechanisms, jurisdictions, customer contracts, and records. Do not add an account to a promotional segment merely because Cookiebot.consent.marketing is true.

A safer policy is:

• Use the Cookiebot event to confirm cookie-preference changes or update website tracking behavior.
• Store email-subscription consent separately, with its own form language, timestamp, source, and withdrawal mechanism.
• Send a transactional preference confirmation only where your product and privacy policy make that communication appropriate.
• Let unsubscribe and suppression status remain authoritative for marketing email decisions.

This distinction protects users and avoids a subtle data-modeling error: one consent signal should not silently become permission for an unrelated processing purpose.

Where the Volanea API key belongs

The API key belongs in a server-only secret store. In a typical deployment, that means an encrypted environment variable named VOLANEA_API_KEY configured in your hosting provider’s project settings, container runtime, or secret manager.

It must not live in Cookiebot configuration because Cookiebot’s relevant integration mechanism here is browser-side JavaScript. It must also not live in a front-end .env variable that is compiled into a client bundle. Framework prefixes such as NEXT_PUBLIC_, VITE_, and similar conventions explicitly expose values to the browser.

Use these safeguards:

• Create a dedicated API key for this application or environment where your Volanea account supports scoped credentials.
• Use separate keys for development, staging, and production.
• Restrict access to deployment settings that expose production secrets.
• Rotate the key immediately if it appears in a repository, browser bundle, support ticket, analytics tool, or log output.
• Never log Authorization headers or full provider request objects.
• Keep the key out of error messages returned to browsers.

A server-side route does not eliminate all security work. The endpoint still needs session validation, CSRF-aware design for cookie-based authentication, request-size limits, abuse controls, and structured logging that avoids recording more personal data than needed.

When this breaks

The failure modes in this integration are different from a classic server-to-server webhook. Cookiebot’s event happens in a browser, the browser makes a request to your app, then your app calls Volanea. Each hop has its own reliability characteristics.

The browser event can happen more than once

Cookiebot consent events can occur when a visitor submits consent, and some Cookiebot consent-loading behavior can happen again when the script determines an existing consent state. Page reloads, a return visit, multiple tabs, browser retries, custom banner interactions, and your own repeated handler registration can all lead to more than one request reaching your endpoint.

Do not send an email merely because a request arrived. Persist and deduplicate a logical action. The example uses a stable hash from the authenticated account ID and browser event ID, then passes that same value to Volanea as Idempotency-Key.

For stronger protection, create a server-side consent-version record. Compare the new category state with the last stored state for that account. If nothing changed, record the observation if useful, but skip the confirmation email.

The browser request can time out after reaching your server

A visitor’s browser may abandon the page, lose connectivity, block a request, or time out while your endpoint is still working. Your server may have already accepted and sent the email even though the browser displays no success state.

That is why the browser should not be the authority on whether the operation succeeded. Return a small 202 Accepted response after the durable event record is created, and perform email delivery in a background job where possible. If you send inline, use a stable idempotency key and persist state before calling Volanea.

Volanea can accept a request while delivery remains pending

The email API’s acceptance response means the message entered Volanea’s sending pipeline. A recipient may later be suppressed, bounce, complain, or experience downstream mailbox delays.

Build operational visibility around provider events and your own event state. For a customer-facing confirmation, avoid promising “delivered” immediately after the API call. Say that preferences were recorded; that statement is controlled by your own database transaction.

Fields can be absent or unexpected

Cookiebot’s publicly documented values are consent booleans, consent method, response flags, and regulation flags. However, browser objects are not a replacement for schema validation. Your code should reject malformed values instead of allowing undefined, strings such as "true", or arbitrary nested data to flow into logs or HTML.

The sample route validates required booleans. Production code should also validate string length, restrict pageUrl to your own allowed origins if you retain it, and parse occurredAt rather than assuming it is a valid timestamp.

Do not assume Cookiebot provides a visitor email, account ID, campaign source, or consent-log identifier in this front-end event. If you need those values, retrieve them from authenticated first-party application context on the server.

Consent-dependent script blocking can block your handler

Cookiebot can control whether scripts execute based on consent categories. A privacy-confirmation handler should normally not be categorized as marketing or statistics code if its job is operationally necessary after a user changes settings.

Review how the script is loaded. If you place it behind a marketing-consent condition, it will not run for users who decline marketing cookies—which may defeat the purpose of recording a preference change. Keep the script minimal, first-party, and aligned with the purpose described in your privacy design.

An invalid sender domain causes API errors

Volanea requires the sending identity to be based on a domain configured for sending. If the from address is unverified or your key lacks access to the relevant project, the API can reject the message.

Test with a production-like verified sender before launch. Keep sender configuration in server-only environment variables if it differs across environments, for example EMAIL_FROM_ADDRESS and EMAIL_FROM_NAME.

A duplicate handler can be introduced by your site stack

Single-page applications, tag managers, consent-script reinjection, and partial page navigation can accidentally attach the same CookiebotOnAccept listener more than once. The result is several browser requests for one user interaction.

Use a guard when your front-end architecture needs one. For example, register the listener in a singleton application bootstrap rather than inside a component that mounts repeatedly. Server-side deduplication remains mandatory because no front-end guard is a security boundary.

A practical testing checklist

Test the integration in a staging environment before sending customer-facing mail. You want to verify both functional behavior and nonfunctional safeguards.

1. Use a test user with a real inbox you control.
2. Clear the site’s CookieConsent cookie or use a fresh browser profile so Cookiebot displays the banner.
3. Open browser developer tools and confirm that exactly one CookiebotOnAccept request reaches your /api/privacy/cookiebot-consent endpoint.
4. Confirm that the posted payload has the expected Cookiebot category booleans.
5. Confirm the endpoint ignores any browser-provided recipient email and derives the recipient from the signed-in account.
6. Verify that the Volanea request occurs only on the server; no API key should appear in browser network traffic.
7. Submit the same payload or retry the request and confirm that the database unique constraint and Idempotency-Key prevent duplicate email.
8. Change a consent category, submit again, and verify that your state-comparison policy sends or skips mail as designed.
9. Test a declined or partial-consent path and make sure it does not accidentally imply email-marketing permission.
10. Force a Volanea failure with a staging key or controlled endpoint setting and confirm the event becomes retryable or visible to operators.

If you need to estimate the operational cost of confirmation messages, retries, and other transactional traffic, review transactional email pricing before rollout.

Choosing an email message that helps rather than annoys

A consent-change message should have a narrow purpose. A short confirmation is generally more useful than a large, branded marketing-style email.

Include:

• A plain statement that preferences were recorded.
• The date and time in a meaningful timezone, if you choose to display it.
• The categories enabled or disabled.
• A link back to the account’s privacy-preferences page.
• A support contact for users who did not make the change.

Avoid including browser fingerprints, raw IP-related data, full consent-log exports, hidden tracking identifiers, or an exhaustive legal memo in the message. Those details often increase risk without making the recipient better informed.

If the user explicitly requests a downloadable record of consent, create that as a separate authenticated account feature. Cookiebot maintains its own consent logging capabilities, while your application can provide a concise account-level history that reflects what your system observed and how it applied the preferences.

Alternatives when email is not the right response

Email is not always the best action after a Cookiebot consent event. Consider what outcome you actually need.

Update first-party account preferences only

For many logged-in products, the correct action is simply to update a settings record and show an in-app confirmation. This avoids unnecessary email while giving the user immediate feedback.

Send an internal alert

If your privacy operations team needs visibility into unusual activity—such as repeated changes, high-volume errors, or a failed synchronization—send a message to an internal operational mailbox. Keep those alerts rate-limited and avoid including unnecessary personal data.

Trigger consent-aware tags, not email

Cookiebot integrates with consent-aware tag behavior and Google Consent Mode. If your goal is to enable or disable analytics, advertising, or embedded services, configure those tags according to the category consent state rather than building an email workflow.

Use a general integration platform only after the secure boundary

If you prefer an automation service for downstream tasks, place it after your own server endpoint. Your server can emit a sanitized, authenticated event to that platform without exposing the Volanea key or making a browser-managed consent event your only source of truth.

The same rule applies whether you use a queue, workflow engine, serverless job, or no-code automation product: the secret-bearing Volanea call should occur in a trusted execution environment.

Conclusion

To send email from Cookiebot with Volanea, do not look for a native Cookiebot marketplace connector or try to connect a browser callback directly to an email API. Cookiebot supplies the consent-state event in the visitor’s browser; your server supplies authentication, validation, deduplication, recipient resolution, and secret management; Volanea supplies the transactional email send.

The durable pattern is straightforward: listen for CookiebotOnAccept, post the documented Cookiebot state to your first-party endpoint, store a server-authoritative consent event, and send a factual confirmation through POST /v1/send with an idempotency key. That approach keeps credentials private, prevents duplicate sends, and respects the fact that cookie consent and email marketing consent are different records.

FAQ

Does Cookiebot have a native Volanea integration?

No. This workflow does not use a native Cookiebot app, marketplace plugin, or Cookiebot dashboard webhook. It uses Cookiebot’s public browser event API and a server-side middleware endpoint.

What Cookiebot event triggers the email workflow?

This guide uses CookiebotOnAccept. The handler reads the current Cookiebot.consent category values and posts them to your own backend.

Can I call Volanea directly from a Cookiebot callback?

No. Do not call Volanea directly from browser JavaScript because that would expose the Volanea API key. Send the Cookiebot-derived payload to your server, then call Volanea from server-side code.

Does marketing-cookie consent mean I can send marketing email?

No. Cookiebot marketing consent governs website tracking and marketing cookies. Email marketing permission should be collected, recorded, and withdrawn separately according to your email-consent process.

How do I stop duplicate confirmation emails?

Persist a server-side idempotency record for the logical consent event and send the same value in Volanea’s Idempotency-Key header. Also compare the new state with the previous stored state and skip email when no meaningful change occurred.