How to Send Email From Crazy Egg With Volanea

Crazy Egg can notify an API endpoint when a survey response arrives or a conversion is counted, which makes it possible to send email from Crazy Egg without exposing an email API key in your website. The reliable implementation is Crazy Egg → your server-side endpoint → Volanea, rather than attempting to call an email provider from browser code.

This is a custom HTTP integration, not a native Crazy Egg app or marketplace plugin. Crazy Egg provides notification channels for survey responses and conversions, including an API endpoint option; your middleware receives that notification, validates and records it, then creates the email through Volanea.

What this Crazy Egg email integration does

The most useful version of this integration sends an internal notification when a visitor completes a Crazy Egg Survey. For example, a product team may want an immediate email when somebody gives a low NPS score, asks for help, submits a sales inquiry, or reports that checkout is broken.

The same architecture can also send email after a Crazy Egg Conversion is counted. A conversion can be configured around a click, page visit, form submission, eCommerce event, custom script, or a client-side GA4 event. That makes conversion notifications useful for operational alerts, but a survey response is generally the better trigger when the email needs human context.

The workflow is:

1. A visitor completes a Crazy Egg Survey, or Crazy Egg counts a configured Conversion.
2. Crazy Egg sends a notification to the API endpoint you configured from the relevant survey results page or conversion goal details page.
3. Your endpoint receives the request, writes a durable event record, and derives a stable idempotency key.
4. Your server maps the event into a Volanea send request.
5. Volanea sends the notification from your verified domain and records the send in its email log.

This pattern keeps credentials away from the visitor’s browser, provides a place to filter noisy events, and gives you a durable audit trail when someone asks why an alert did or did not arrive.

The real Crazy Egg trigger: a survey response or counted conversion

Crazy Egg’s notification model is event-driven. For a survey-driven workflow, the concrete event is that a survey response has been received. In the Crazy Egg interface, open the relevant Survey’s results, use Get Notified, and select the API endpoint notification channel.

For a conversion-driven workflow, the concrete event is that a conversion has been counted. Open the specific Conversion Goal’s details page, choose Get Notified, and configure the API endpoint channel there. Crazy Egg supports conversion definitions including someone clicking an element, reaching a page, submitting a form, completing an eCommerce event, firing a script, or firing a client-side GA4 event.

Choose the trigger based on the message you need to send:

• Survey response received: Best for support escalation, feedback routing, lead notification, NPS follow-up, and qualitative research.
• Conversion counted: Best for operational awareness, such as alerting a sales team that a demo-request conversion goal was reached.
• New Error: Crazy Egg’s Errors product can also notify an API endpoint when a new error is detected or a previously resolved error reappears. This is useful for engineering alerts, not customer-facing mail.

For this guide, the trigger is a survey response received. Configure the survey to collect an email address only when you have a clear purpose and an appropriate privacy notice. If your survey does not collect an address, send the alert to an internal team inbox rather than attempting to email the respondent.

Why the integration needs middleware

Crazy Egg can send an API notification, but Volanea requires a secret API key in its Authorization header. A direct browser-side request would disclose that key to every visitor who can inspect your page, developer tools, JavaScript bundle, network requests, or source map.

Do not put a Volanea key in any of these places:

• A Crazy Egg Survey question, hidden field, redirect URL, or client-side custom JavaScript.
• A JavaScript variable delivered to the browser.
• Google Tag Manager variables that execute in a visitor’s browser.
• A public Git repository, frontend build variable, or static configuration file.
• A query-string parameter on the Crazy Egg notification URL.

Instead, put the Volanea key in a server-side secret store or environment variable controlled by your hosting platform. Examples include a Cloudflare Worker secret, Vercel environment variable, AWS Secrets Manager value, container secret, or encrypted configuration setting in your application.

Your middleware endpoint has three responsibilities that Crazy Egg itself cannot safely perform for your mail infrastructure:

1. Authenticate the inbound request. Use a private, high-entropy path token at minimum, and add an edge-level access policy or IP restriction when your infrastructure supports it.
2. Normalize the inbound payload. Crazy Egg’s public help materials document the notification capability but do not publish a stable public JSON schema for API-endpoint notification bodies. Treat the received event as an external contract: capture a test delivery, preserve its raw body, and map only fields you have observed and approved.
3. Send safely. Generate a stable Idempotency-Key from the incoming notification so an upstream retry does not create a second email.

A middleware endpoint also gives you room to rate-limit, suppress alerts outside business hours, redact sensitive answers, post failures to monitoring, and switch the email destination without rebuilding the survey.

Configure the Crazy Egg notification

Create or select the survey first. Crazy Egg Surveys can be presented as popups, shared links, or embedded widgets, and can use conditional logic. Before connecting any notification, submit several test responses that represent the kinds of answers your team expects.

Then configure the API endpoint notification:

1. Open the selected survey’s results in Crazy Egg.
2. Select Get Notified.
3. Choose the API endpoint notification channel.
4. Enter the HTTPS URL for your middleware, such as https://automation.example.com/hooks/crazy-egg/<long-random-secret>.
5. Save the notification and submit a test survey response.
6. Inspect the incoming request in your middleware logs before enabling production routing.

Use a route secret that is long, randomly generated, and unique to this integration. A route secret is not as strong as a signed webhook with a documented signature scheme, but it prevents casual scanning and stops an attacker from guessing a generic endpoint such as /webhooks/crazy-egg.

Do not use a recipient email address as the endpoint secret. Do not reuse your Volanea API key as the route secret. These are separate credentials with separate rotation procedures.

Capture the actual payload before mapping fields

A key implementation detail is worth making explicit: Crazy Egg’s public notification documentation confirms that it can notify an API endpoint for survey responses and conversions, but it does not document a public, versioned payload schema or webhook signature specification. Do not invent field names based on a screenshot, a Zapier sample, or an old event captured by another account.

Start in capture mode. Record the raw request body and a small allowlisted subset of request headers in a protected log for test submissions only. Remove or redact personally identifiable information from ordinary application logs after validating the payload.

Your first test event lets you answer practical mapping questions:

• Which field or nested answer contains the respondent’s email address?
• Does Crazy Egg provide a response identifier, timestamp, survey title, or question labels?
• Is one notification emitted for the complete survey response or for each individual question response?
• Which fields may be missing because a question was skipped by conditional logic?
• Does the delivered event include content that should never be copied into an email, such as a free-text password or payment-related answer?

This discovery step is not optional. It prevents a fragile integration that appears to work with one test response but fails when a visitor skips a question or follows a different survey branch.

Payload handling and field mapping

Because Crazy Egg does not publish a stable API-endpoint payload schema, the safe production mapping should be based on the exact test payload captured from your own configured survey. The server code below deliberately keeps the Crazy Egg-specific extraction in one small normalizeCrazyEggSurvey function.

The code uses an illustrative normalized shape inside your application, not a claim about undocumented Crazy Egg field names:

{
  "eventId": "stable-event-id-or-derived-hash",
  "surveyName": "Checkout feedback",
  "respondentEmail": "visitor@example.com",
  "answers": [
    { "question": "How can we help?", "answer": "Checkout would not accept my card." },
    { "question": "Order number", "answer": "A-1042" }
  ],
  "submittedAt": "2026-10-02T15:42:18.000Z"
}

Map the normalized data to the email like this:

The default example sends the notification to an internal inbox. That is intentional: it does not assume that every survey response contains an email address or that every respondent has consented to receive a transactional message.

Working middleware example: Crazy Egg to Volanea

The following Node.js example accepts a JSON notification from Crazy Egg, checks a private route secret, normalizes your captured payload, and sends an internal alert through Volanea’s REST API. It uses POST https://api.volanea.com/v1/send, Authorization: Bearer, JSON content, and an Idempotency-Key header.

Replace only the clearly marked extraction code after you have captured a real test payload from your Crazy Egg survey. The rest of the handler can remain stable.

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

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

const {
  CRAZY_EGG_HOOK_SECRET,
  VOLANEA_API_KEY,
  ALERT_TO_EMAIL,
  ALERT_FROM_EMAIL,
} = process.env;

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

function hash(value) {
  return crypto.createHash("sha256").update(value).digest("hex");
}

function normalizeCrazyEggSurvey(payload) {
  // IMPORTANT: Replace these extraction paths with fields from a real,
  // captured Crazy Egg test notification. Crazy Egg does not publish a
  // stable public endpoint payload schema, so do not copy guessed paths.
  //
  // Keep a short-lived, access-controlled capture log during setup, then
  // implement explicit extraction and validation here.

  const raw = JSON.stringify(payload);

  return {
    // Prefer Crazy Egg's actual response/event ID when your capture proves it.
    // The raw-body hash is a fallback only; use it to avoid duplicate sends
    // for byte-identical retries.
    eventId: payload.id ?? payload.responseId ?? hash(raw),

    // Replace these with verified paths from your captured payload.
    surveyName: payload.survey?.name ?? payload.surveyName ?? "Crazy Egg survey",
    respondentEmail: payload.email ?? payload.respondent?.email ?? "",
    submittedAt: payload.createdAt ?? payload.submittedAt ?? new Date().toISOString(),

    // Normalize only approved fields. Do not blindly email the complete raw payload.
    answers: Array.isArray(payload.answers)
      ? payload.answers.map((item) => ({
          question: item.question ?? item.label ?? "Survey answer",
          answer: item.answer ?? item.value ?? "",
        }))
      : [],
  };
}

app.post("/hooks/crazy-egg/:secret", async (req, res) => {
  if (!crypto.timingSafeEqual(
    Buffer.from(req.params.secret || ""),
    Buffer.from(CRAZY_EGG_HOOK_SECRET || "")
  )) {
    return res.status(404).end();
  }

  const event = normalizeCrazyEggSurvey(req.body);

  const answerRows = event.answers.length
    ? event.answers.map(({ question, answer }) => `
        <tr>
          <th align="left" valign="top">${escapeHtml(question)}</th>
          <td>${escapeHtml(answer)}</td>
        </tr>`).join("")
    : "<tr><td>No mapped answers were found. Review the payload mapping.</td></tr>";

  const html = `
    <h2>New Crazy Egg survey response</h2>
    <p><strong>Survey:</strong> ${escapeHtml(event.surveyName)}</p>
    <p><strong>Submitted:</strong> ${escapeHtml(event.submittedAt)}</p>
    <p><strong>Respondent email:</strong> ${escapeHtml(event.respondentEmail || "Not collected")}</p>
    <table border="1" cellpadding="8" cellspacing="0">${answerRows}</table>
  `;

  const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": `crazy-egg-survey:${event.eventId}`,
    },
    body: JSON.stringify({
      from: ALERT_FROM_EMAIL,
      to: [ALERT_TO_EMAIL],
      subject: `[Crazy Egg] ${event.surveyName}`,
      html,
    }),
  });

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

  if (!volaneaResponse.ok) {
    console.error("Volanea send failed", volaneaResponse.status, result);
    // Return a non-2xx status only if you want Crazy Egg to retry the notification.
    // Keep the same event-derived idempotency key when it retries.
    return res.status(502).json({ error: "email_send_failed" });
  }

  return res.status(200).json({ ok: true, message: result });
});

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

The to field is an array because Volanea can send one message to one recipient or a limited group of recipients. Keep operational alerts narrowly targeted. If several teams need the message, use a shared mailbox, distribution list, or explicit routing rules in your application rather than exposing all recipient addresses to each other unnecessarily.

Before deploying, verify the domain used in ALERT_FROM_EMAIL in Volanea. A sending address on an unverified domain cannot send production mail. Volanea’s API reference and setup material are available in the email API documentation.

Secure authentication and secrets

There are two separate security boundaries in this workflow: inbound notification security and outbound email authentication.

Protect the Crazy Egg-facing endpoint

Crazy Egg’s public materials describe API endpoint notifications but do not publish a documented webhook signature header or signing-key verification workflow. That means you should not pretend an undocumented signature exists.

Use layered controls instead:

• Give the endpoint an unguessable route secret, generated with a cryptographically secure random generator.
• Serve the endpoint only over HTTPS.
• Put the endpoint behind a web application firewall, API gateway, or access-control policy where possible.
• Apply a small request-size limit and reject unexpected content types.
• Avoid logging all headers or request bodies in production, especially when survey answers contain personal data.
• Return a quick response after recording or queueing work; do not wait for slow downstream systems if your platform has a queue.

A route secret is still a bearer credential. Rotate it when access changes, when an employee with access leaves, or when you suspect it has been exposed. During rotation, accept both old and new routes briefly only if you have a documented cutover plan.

Store the Volanea API key only on the server

The Volanea secret key belongs in VOLANEA_API_KEY on the middleware runtime, not on the Crazy Egg page or in survey JavaScript. The process that calls Volanea should be the only process that can read the key.

Use a scoped production key for production traffic and a test key for development if your Volanea account provides separate environments. Rotate the key if it is accidentally committed, appears in build logs, or is shared outside the team that operates the integration.

Your secret configuration should look conceptually like this:

CRAZY_EGG_HOOK_SECRET="a-long-random-route-secret"
VOLANEA_API_KEY="sk_live_replace_with_a_real_secret"
ALERT_FROM_EMAIL="alerts@notify.example.com"
ALERT_TO_EMAIL="product-ops@example.com"

Never paste actual secret values into ticketing systems, chat threads, public documentation, browser-console snippets, or screenshots. If you need to demonstrate setup to a teammate, show variable names and redact values.

Make duplicate notifications safe

Webhooks and notification endpoints should be treated as at-least-once delivery systems. If Crazy Egg cannot tell whether your endpoint accepted a notification—for example, because a network connection closes after processing—the notification can be retried. A retry is correct behavior from the sender’s perspective, but it can create duplicate mail unless your receiver is designed for it.

Volanea supports safe retries on the send endpoint through the Idempotency-Key header. In the example, the value is derived from a stable Crazy Egg response or event identifier when one is available:

Idempotency-Key: crazy-egg-survey:<stable-event-id>

Use the exact same key when retrying the same logical email. Do not generate a fresh random UUID each time the endpoint receives an event; that turns retries into new sends.

If Crazy Egg does not provide a stable event ID in the payload you receive, calculate a deterministic hash from a canonicalized subset of the event. Include meaningful identifiers and timestamps only if they are reliably present. A raw-body hash works for byte-identical deliveries, but it may not catch semantically identical retries if field order or transport metadata changes.

For high-value alerts, add your own persistence layer as well. Store a row keyed by the external event ID or canonical event fingerprint before calling Volanea. Mark it as processing, sent, or failed, and use a unique database constraint to prevent two concurrent requests from sending the same alert.

When this breaks

Every automation eventually encounters an incomplete payload, a timeout, a configuration change, or a downstream outage. Build the failure behavior before relying on the integration for urgent support or revenue notifications.

Crazy Egg retries create duplicate sends

If your server processes the notification but responds too slowly, errors after sending, or loses the response connection, Crazy Egg may send the notification again. Without idempotency, each delivery can generate a separate email.

What to do: Derive one Idempotency-Key per survey response or conversion event. Reuse it on all retries. Add database-level deduplication if alert correctness is especially important. Do not use the current timestamp as the only key component.

The webhook request times out

Sending an email synchronously in the request path can be slow during DNS issues, a rate-limit response, or a transient network problem. If the endpoint times out before it returns success, the sender may retry even if the email provider later accepts the request.

What to do: Parse and validate the event, write it to a queue or database, return a success response promptly, and send email from a worker. If you retain synchronous sending for a low-volume setup, use a short outbound timeout, idempotency, and clear monitoring.

Payload fields are missing or change across survey branches

Survey logic can produce different answers depending on what a respondent sees. An email question may be optional, skipped, renamed, or absent from a particular path. A conversion notification also may not contain the marketing or customer data you expected.

What to do: Validate every mapped field. Use a safe fallback such as Not collected for display-only fields, but reject an event that requires a missing field to choose its recipient. Keep extraction code centralized, versioned, and covered by fixture tests based on anonymized real payloads.

A plan or product capability changes

Crazy Egg’s available features can vary by product area and plan. For example, Errors tracking has been described as available on Growth and Enterprise plans, while Surveys are promoted as included across plans. Do not assume one notification type implies access to every other notification type.

What to do: Confirm the notification channel in the exact Crazy Egg screen for the product you use, test it with a real account, and keep a Zapier fallback for teams that prefer managed automation. Zapier’s documented Crazy Egg trigger for surveys is Individual Question Response, and current Zapier listings also show triggers such as Survey Completed and New Error.

Volanea rejects the send

A Volanea send can fail because the key is invalid, the sending domain is unverified, the request body is invalid, the account is over a limit, or a recipient is suppressed. A successful API acceptance is also distinct from final inbox placement.

What to do: Log the Volanea status code and response body securely, alert on sustained failures, verify the sender domain, and avoid endlessly retrying permanent 4xx errors. For addresses collected in surveys, validate syntax and consider using the email address verification tool before adding an address to a follow-up workflow.

Direct endpoint versus Zapier middleware

A direct Crazy Egg API endpoint notification is the best fit when you need full control over security, normalization, idempotency, routing, and audit records. It is also the clearest option when you want Volanea’s key to remain entirely inside infrastructure you operate.

Zapier is a useful middleware alternative when your team does not want to deploy and maintain an endpoint. Crazy Egg’s supported Zapier integration documents Individual Question Response as a survey trigger, and Zapier lists workflow templates that can send webhook POST requests after Crazy Egg survey responses.

A Zapier route looks like this:

1. Trigger: Crazy Egg — Individual Question Response or Survey Completed, depending on the workflow you need.
2. Filter: Continue only when the answer matches the escalation criteria, such as an NPS score below seven or a support-request answer.
3. Action: Webhooks by Zapier — custom request to a middleware endpoint you control.
4. Middleware: Add the Volanea authorization header server-side and call POST /v1/send.

Avoid configuring Zapier to call Volanea directly if that would require pasting a long-lived Volanea secret into a broadly accessible automation workspace. A protected middleware endpoint gives you better secret rotation, inbound validation, durable deduplication, and a single place to enforce outbound email policy.

Practical email patterns for Crazy Egg events

The integration is most valuable when an email creates a timely action, not when it copies every analytics event into someone’s inbox.

Support-request escalation

Ask a survey question such as “Would you like help from our team?” and conditionally collect an email address only when the visitor answers yes. Route the response to support with the page URL, free-text problem description, and timestamp.

Keep the message internal unless the visitor explicitly requested a reply. If you want to send an automatic acknowledgement to the respondent, make that an explicit opt-in workflow and use a distinct template with a clear expectation for response time.

Low-NPS triage

Use a survey response to alert a customer-experience or product team when a score falls below your selected threshold. Include the score, the verbatim reason, and a link to the appropriate internal workflow—not sensitive session data that the recipient does not need.

Do not automatically send a marketing sequence because somebody gave a low score. The useful second-order action is to resolve the problem, classify recurring themes, and feed the issue back into the page, product, or experiment that generated the feedback.

Lead-routing alert

An embedded Crazy Egg Survey can serve as a lightweight lead form. Send an internal sales notification after a qualifying response, but validate that your form has appropriate consent language before using submitted contact details for broader sales outreach.

Use a static team alias as the immediate recipient and route from there. This avoids duplicating destination logic across every survey and makes staffing changes much easier.

Conversion anomaly notifications

For a conversion trigger, use email sparingly. A single conversion is often normal and better recorded in analytics or a CRM. Email is more appropriate for a significant event, an unusual drop in conversion activity detected by another system, or a manually defined operational milestone.

Test the complete path before publishing

A successful configuration screen is not proof that the system works. Test the real visitor-to-inbox journey with controlled data.

Use this checklist:

1. Verify the Volanea sending domain and choose a from address on that domain.
2. Deploy the middleware with a test Volanea key or a clearly labeled non-production recipient.
3. Configure the Crazy Egg API endpoint notification with a unique route secret.
4. Submit a survey response that contains every expected field.
5. Inspect the protected capture record and update normalizeCrazyEggSurvey using observed fields only.
6. Submit a response that skips optional questions and confirm the handler does not throw or send malformed mail.
7. Replay the same captured notification twice and confirm only one email is created because the idempotency key is reused.
8. Temporarily force Volanea to fail, confirm the event is recorded, and confirm your retry policy behaves as intended.
9. Check the Volanea email log for the accepted message and confirm the inbox rendering is readable on desktop and mobile.
10. Remove temporary verbose payload logging and rotate any route secret or API key exposed during testing.

The result should be boring: one meaningful Crazy Egg event produces one correctly formatted email, and a retry produces no duplicate email.

Conclusion

To send email from Crazy Egg with Volanea, use Crazy Egg’s API endpoint notification capability as the trigger and place a small server-side middleware service between Crazy Egg and Volanea. For survey workflows, the relevant trigger is a survey response received; for goal workflows, it is a conversion counted.

The middleware is the essential piece. It protects the Volanea API key, maps the notification you actually receive, handles missing survey fields, applies routing rules, and makes retries safe with an event-derived Idempotency-Key. Build that layer deliberately, test with real Crazy Egg deliveries, and you can turn feedback or conversion activity into reliable operational email without pretending that a native plugin exists.

FAQ

Does Crazy Egg have a native Volanea integration?

No. This is a custom integration using Crazy Egg’s API endpoint notification option and Volanea’s REST email API. There is no Crazy Egg marketplace installation flow for Volanea.

What Crazy Egg event can trigger the email?

Use a survey response received notification from a Survey results page, or a conversion counted notification from a Conversion Goal details page. Crazy Egg also supports API endpoint notifications for new Errors in the Errors dashboard.

Can I send an email directly from Crazy Egg to Volanea?

Do not send directly from browser-side survey code because that would expose the Volanea secret key. Send Crazy Egg’s notification to a server-side middleware endpoint, then have that endpoint call Volanea.

How do I stop duplicate emails when Crazy Egg retries?

Send a stable Idempotency-Key with the Volanea request. Derive it from a verified Crazy Egg event or response ID when available, and reuse the same key whenever the same notification is retried.

What if the Crazy Egg payload does not include a respondent email address?

Send the notification to an internal mailbox and include only the approved survey data you received. Do not attempt to infer an address from analytics data, and do not make a survey answer mandatory unless it is necessary for the visitor’s requested outcome.