How to Send Email from Hotjar with Volanea

Hotjar can collect the moment of feedback; Volanea can turn that moment into a reliable email. This guide shows how to send email from Hotjar when a visitor creates a new survey response, without pretending there is a native Volanea app or marketplace installation.

The integration is a webhook architecture:

1. A visitor submits a Hotjar Survey.
2. Hotjar emits a survey_response webhook event to your HTTPS endpoint.
3. Your server verifies Hotjar’s signature, deduplicates the event, and builds an email.
4. Your server calls Volanea’s POST /v1/send endpoint with a server-side API key.
5. Volanea accepts the message for delivery from your verified sending domain.

That server-side hop is important. Hotjar is the event source, not an email-runtime environment. Volanea does not ship a native Hotjar listing, so the dependable approach is to use Hotjar’s outbound webhook capability and a small receiver you control.

What actually triggers the email in Hotjar?

The concrete trigger is a new Survey response. When a visitor submits a Hotjar Survey, Hotjar sends an HTTP POST request to the webhook URL configured for that Survey. The event name in the payload is survey_response.

This is not a browser-side event that fires while someone is typing. It occurs when Hotjar creates the response. That distinction matters for email: a completed survey response is a meaningful event for an internal notification, a support follow-up workflow, or a request to review negative feedback. It is not an invitation to send mail after every partial interaction.

Hotjar’s webhook reference describes JSON webhook deliveries with a top-level event, version, and data object. The documented event values include survey_response and test_message; the payload is UTF-8 JSON and Hotjar expects your endpoint to respond within 10 seconds.

For this guide, the desired flow is:

• Hotjar trigger: a new Survey response is created.
• Webhook event filter: process only event === "survey_response".
• Volanea action: send an internal email to the research, support, or product team.
• Optional downstream action: create a ticket or contact task after the email, rather than emailing the respondent automatically.

The last point protects privacy and consent. A Hotjar response may be anonymous, may not contain an email address, and may contain free-text feedback that should not automatically trigger customer outreach.

Choose the right architecture before you configure anything

There are two sensible ways to connect Hotjar to Volanea. Which one to choose depends on whether you can run a small server-side endpoint.

Direct webhook receiver: recommended

Use this route when you have a serverless function, API route, worker, or backend application. Hotjar sends the signed event directly to your endpoint, and your endpoint calls Volanea.

This is the better production design because it gives you control over:

• signature verification before doing any work;
• idempotency and duplicate protection;
• validation of optional and user-entered fields;
• the Volanea API key, which stays outside Hotjar and outside browser code;
• routing rules, such as notifying support only for a low score;
• observability, including logs that connect a Hotjar response to a Volanea message ID.

Zapier as middleware: useful for no-code workflows

Hotjar also supports Zapier triggers, including New Survey Response. You can create a Zap with Hotjar as the trigger and an HTTP action that calls Volanea. This is useful when an operations team needs to own the workflow without deploying code.

However, do not paste a broadly privileged Volanea secret into a client-visible page, a survey setting, or browser JavaScript. If the Zapier plan and connection model meet your security requirements, store the credential in Zapier’s authenticated connection or protected action configuration. For stronger control over signatures, idempotency, and logging, send Hotjar to your own receiver first.

This guide focuses on the direct receiver because it is the cleanest way to send production email. For endpoint and payload details beyond this example, use the Volanea API reference and setup guides.

Configure the Hotjar Survey webhook

Create the Survey first and confirm that it is actively targeting users on the correct site and page conditions. The webhook is attached to the Survey workflow, so an inactive or incorrectly targeted Survey cannot generate the event you expect.

In the Survey’s settings, use the Forward Response area to configure the webhook destination. Enter the public HTTPS URL for your receiver, for example:

https://app.example.com/webhooks/hotjar-survey

Use a URL that is dedicated to this one integration. A dedicated endpoint makes it easier to apply rate limits, isolate logs, rotate the signing secret, and determine whether an incoming request really belongs to Hotjar.

Your receiver must meet Hotjar’s delivery expectations:

• It must be reachable over HTTPS/TLS.
• It must accept JSON POST requests.
• It must return a 2xx response within 10 seconds.
• It should safely ignore unknown event types rather than failing the entire webhook delivery.
• It must tolerate duplicate deliveries.

Hotjar supports a webhook test event. Send the test before publishing any automation. Your receiver should validate the signature, recognize test_message, log it, and return 204 No Content without sending an email. That gives you evidence that the HTTPS route, reverse proxy, raw-body handling, and signing key are configured correctly before a real respondent can trigger a message.

Understand the Hotjar payload before mapping it

A Hotjar webhook uses a stable envelope. The important top-level shape is:

{
  "event": "survey_response",
  "version": 1,
  "data": {
    "hotjar_user_id": "…",
    "country_name": "…",
    "created_str": "…"
  }
}

The data object holds event-specific fields. For survey responses, Hotjar documents respondent context such as hotjar_user_id, country_name, and created_str; not every response should be assumed to include every field your organization might want. A respondent can be anonymous, browser privacy controls can limit available context, and different product access levels can affect the data and automation features available to an account.

Treat the real event as an external input, not as a trusted internal object. Your receiver should parse only fields it needs, validate their types, and retain the original payload only in appropriately protected logs. Do not place raw survey answers into an email subject line, where they can leak through inbox previews, notification banners, forwarding, and ticket titles.

Field mapping for an internal notification

A practical mapping for a survey-response alert is:

The recipient in this example is deliberately not mapped from Hotjar. It is an internal address such as research-alerts@example.com, stored in server-side configuration. If your survey includes an optional email question, do not automatically use that value for follow-up until you have explicit consent, validation, and a defined transactional purpose.

Working webhook receiver and Volanea send call

The following TypeScript example is an Express route. It verifies Hotjar’s com-hotjar-signature header against the raw request body, accepts only survey_response, stores a deduplication key, and sends one internal email with Volanea’s REST API.

The Hotjar signature scheme uses HMAC-SHA3-256. Do not JSON-parse and re-serialize before verifying: a signature covers the exact bytes Hotjar sent, and formatting changes can invalidate it.

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

const app = express();

// Keep a durable version of this in Redis, Postgres, DynamoDB, etc.
// A process-local Set is only suitable for a short-lived demo.
const processed = new Set<string>();

const HOTJAR_WEBHOOK_KEY = process.env.HOTJAR_WEBHOOK_KEY!;
const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY!;
const ALERT_TO = process.env.HOTJAR_ALERT_TO!;
const FROM = process.env.VOLANEA_FROM!; // e.g. Feedback <feedback@example.com>

function escapeHtml(value: string): string {
  return value
    .replace(/&/g, "&amp;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&#039;");
}

function verifyHotjarSignature(rawBody: Buffer, supplied?: string): boolean {
  if (!supplied) return false;

  // Hotjar signs the raw payload using HMAC-SHA3-256.
  const expected = crypto
    .createHmac("sha3-256", HOTJAR_WEBHOOK_KEY)
    .update(rawBody)
    .digest("hex");

  const suppliedBuffer = Buffer.from(supplied, "hex");
  const expectedBuffer = Buffer.from(expected, "hex");

  return suppliedBuffer.length === expectedBuffer.length &&
    crypto.timingSafeEqual(suppliedBuffer, expectedBuffer);
}

app.post(
  "/webhooks/hotjar-survey",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    const rawBody = req.body as Buffer;
    const signature = req.header("com-hotjar-signature") ?? undefined;

    if (!verifyHotjarSignature(rawBody, signature)) {
      return res.status(401).json({ error: "Invalid Hotjar signature" });
    }

    const payload = JSON.parse(rawBody.toString("utf8")) as {
      event?: string;
      version?: number;
      data?: {
        hotjar_user_id?: string;
        country_name?: string;
        created_str?: string;
        // Keep survey-answer parsing specific to your tested Survey schema.
        // Do not assume an answer field exists on every payload.
      };
    };

    // A test delivery proves connectivity. It should never send a real alert.
    if (payload.event === "test_message") {
      return res.sendStatus(204);
    }

    if (payload.event !== "survey_response" || !payload.data) {
      return res.sendStatus(204);
    }

    const occurredAt = payload.data.created_str ?? "not supplied";
    const hotjarUserId = payload.data.hotjar_user_id ?? "not supplied";
    const country = payload.data.country_name ?? "not supplied";

    // Replace this with the response's documented unique identifier from your
    // captured production test payload. Do not use a random UUID: retries need
    // the same key. This fallback makes the exact same payload deterministic.
    const idempotencyKey = crypto
      .createHash("sha256")
      .update(rawBody)
      .digest("hex");

    if (processed.has(idempotencyKey)) {
      return res.sendStatus(204);
    }

    const text = [
      "A new Hotjar Survey response was created.",
      `Occurred: ${occurredAt}`,
      `Country: ${country}`,
      `Hotjar user ID: ${hotjarUserId}`,
      "",
      "Open Hotjar to review the response and associated context."
    ].join("\n");

    const html = `
      <h1>New Hotjar Survey response</h1>
      <p><strong>Occurred:</strong> ${escapeHtml(occurredAt)}</p>
      <p><strong>Country:</strong> ${escapeHtml(country)}</p>
      <p><strong>Hotjar user ID:</strong> ${escapeHtml(hotjarUserId)}</p>
      <p>Open Hotjar to review the response and associated context.</p>
    `;

    const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": `hotjar-survey:${idempotencyKey}`
      },
      body: JSON.stringify({
        from: FROM,
        to: ALERT_TO,
        subject: "New Hotjar Survey response",
        text,
        html,
        tags: ["hotjar", "survey-response", "internal-alert"]
      })
    });

    if (!volaneaResponse.ok) {
      const detail = await volaneaResponse.text();
      console.error("Volanea send failed", volaneaResponse.status, detail);
      // Return a non-2xx code only when your durable queue/retry policy can
      // safely handle Hotjar redelivery without losing or duplicating alerts.
      return res.status(502).json({ error: "Volanea send was not accepted" });
    }

    processed.add(idempotencyKey);
    return res.sendStatus(204);
  }
);

app.listen(3000);

This example maps verified Hotjar fields into the email body and maps a stable event fingerprint into Volanea’s Idempotency-Key header. In production, replace the in-memory Set with durable storage and replace the hash fallback with Hotjar’s unique response identifier after you capture a genuine test payload for your specific Survey.

Keep the Volanea API key out of Hotjar and out of the browser

The Volanea API key does not belong in Hotjar. Hotjar’s Survey configuration receives your webhook URL and manages its webhook signing key; it is not a safe place to paste an outbound email-provider credential.

Store VOLANEA_API_KEY in the secret store for the environment that runs the webhook receiver:

• an environment variable managed by your deployment platform;
• a serverless-function secret;
• a worker secret;
• a cloud secret manager injected only at runtime.

The receiver reads that secret when it makes the Volanea request. The visitor’s browser never receives it, Hotjar’s public Survey code never receives it, and your logs should never print it.

A leaked sending key can allow an attacker to send mail through your account, damage sender reputation, and create a difficult incident response problem. Use a separate key for development and production, use the least privilege available, rotate it if it appears in a commit or log, and verify the from domain before enabling the webhook.

Hotjar’s own webhook signing key is different: it authenticates the inbound request from Hotjar to your receiver. Retrieve it from Hotjar’s Webhook integration settings, keep it as HOTJAR_WEBHOOK_KEY, and compare the calculated HMAC to the com-hotjar-signature request header before parsing or acting on the payload.

Design the email for a human reviewer, not an automation loop

An internal response alert should make review quick without exposing more respondent data than necessary. A good first version includes the survey name in the subject, the event time, coarse location if Hotjar provided it, a correlation ID, and a link or operational instruction directing the reviewer back to Hotjar.

Avoid including full unescaped free-text responses in HTML. Survey content is user-controlled input. If you include an answer in the email, HTML-escape it, cap its length, and use a text fallback. This prevents a respondent’s input from becoming active markup in an internal mailbox.

Add routing rules deliberately

Once the basic alert works, add business rules at the receiver rather than attempting to turn every response into an email. Examples include:

• send to support only if a tested answer maps to a low satisfaction score;
• send to product research only if a participant explicitly asks to be contacted;
• send a daily digest for routine responses instead of one message per response;
• use a separate recipient address for each survey;
• add tags to Volanea sends for reporting by survey or site.

Do not infer sentiment from a field that your Survey does not reliably provide. Map only the question and answer fields you have captured from a real test response, version your parser when the Survey changes, and fail safely if a field disappears.

When this breaks

This integration crosses two network boundaries: Hotjar to your webhook, then your webhook to Volanea. A 200 from one boundary does not prove success at the next. Plan for failure modes before the first live response arrives.

Hotjar retries can create duplicate emails

Hotjar documents retry behavior for failed deliveries and expects receivers to handle accidental duplicates. A request might reach your application, trigger an email send, and then fail before your application returns a 2xx. From Hotjar’s perspective, that attempt failed and it can retry. Without deduplication, the internal team gets two alerts.

Use both layers of protection:

1. Persist a processed-event key before acknowledging a completed send.
2. Send the same stable identifier as Volanea’s Idempotency-Key for the same logical response.

Do not generate a random idempotency key for each HTTP attempt. That converts every retry into a new logical send. The key must remain stable for the same Hotjar response.

Webhook timeouts can turn a slow email call into a retry

Hotjar requires a response within 10 seconds. Calling an external email API synchronously can work at low volume, but a temporary network delay can consume that window. If the receiver times out, Hotjar may retry even if Volanea eventually accepts the email.

For higher reliability, split ingestion from delivery. Verify the signature, validate and deduplicate the payload, enqueue a compact job, then return 204 quickly. A worker can call Volanea after that. The queue should retain the event fingerprint and reuse it as the Volanea idempotency key.

Some fields will be absent, and access can vary by plan

Do not build a production parser that assumes every response includes the same respondent context or answer fields. A respondent may be anonymous; a Survey may not ask for an email address; localization and question changes alter answer content; privacy settings may reduce context; and Hotjar/Contentsquare plan availability can affect which webhook and export capabilities are available.

Handle absent fields explicitly with validation and neutral fallbacks such as not supplied. More importantly, never use a missing field as the basis for a risky default, such as routing an email to an unverified address or categorizing a response as negative.

Signature failures usually mean raw-body handling is wrong

If every request fails signature verification, check whether middleware parsed the JSON before the verification function ran. Signatures must be calculated from the unmodified bytes. Also confirm that the webhook key came from the correct Hotjar site and that you are reading the exact com-hotjar-signature header.

Log only safe diagnostics: request timestamp, event type after verification, signature-present boolean, response status, and a hashed event ID. Do not log webhook keys, Volanea keys, or full respondent answers by default.

Volanea acceptance is not inbox placement

A successful POST /v1/send means Volanea accepted the send request; it does not mean the recipient has read the email or that the mailbox provider will place it in the inbox. Use a verified sender domain, keep internal-notification content transactional and relevant, and monitor Volanea message events for downstream delivery outcomes.

If an address comes from a Survey question and you later decide to email it, validate consent and syntax first. The email address verification tool can help screen an address, but validation does not replace permission to contact someone.

Test the full path safely

Testing is not complete when Hotjar says a webhook was delivered. Test each stage separately, then test the complete chain.

1. Endpoint test: Confirm the public HTTPS route returns a 2xx response for a valid Hotjar test event.
2. Signature test: Confirm altered payload bytes or a missing signature return 401 and do not enqueue a job.
3. Event filter test: Confirm test_message returns 204 without sending email.
4. Survey test: Submit a response to the actual Survey from a test browser session.
5. Mapping test: Verify that created_str, country_name, and hotjar_user_id appear as expected when supplied and gracefully degrade when absent.
6. Duplicate test: Deliver the exact same payload twice and verify that only one Volanea message is created.
7. Failure test: Force the Volanea call to fail temporarily and verify your queue or retry design neither loses the event nor creates repeated alerts.

Use a dedicated internal inbox during testing. Do not use a customer address, and do not load a real respondent’s raw answers into third-party webhook-inspection services unless your privacy and data-processing policies allow it.

Direct webhook versus Zapier: which is right for your team?

Use the direct route when email is operationally important. It lets developers apply signature verification, control raw request bodies, create a durable idempotency record, and keep the Volanea credential entirely within infrastructure you operate.

Use Zapier when the workflow is straightforward, an operations team owns it, and the limits of a no-code workflow are acceptable. Hotjar’s Zapier integration supports Surveys as triggers and exposes New Survey Response as an event. In Zapier, add an HTTP request action that calls Volanea’s endpoint, send a JSON body, and use secure credential storage rather than embedding a key in a field that appears in task history or shared configuration.

The trade-off is not about whether either option can send an email. Both can. The difference is where you enforce trust, deduplication, transformations, and incident handling. For a low-volume internal alert, Zapier may be enough. For a response that drives a customer commitment, escalation, or regulated workflow, use a signed server-side receiver and a queue.

Conclusion

To send email from Hotjar with Volanea, use Hotjar’s survey_response webhook as the trigger and keep the email send on a server you control. Verify the com-hotjar-signature header against the raw request, validate the event data, deduplicate using a stable response identifier, and make a bearer-authenticated POST request to Volanea’s /v1/send endpoint.

This design avoids a fictional native integration, keeps your Volanea API key off the client, handles Hotjar retries safely, and gives your team a clear trail from survey response to email notification. Start with a restrained internal alert, capture a real test payload for your Survey’s exact answer structure, and then add routing rules only when you can test and observe them.

FAQ

Does Volanea have a native Hotjar integration?

No. Volanea does not provide a native Hotjar marketplace app or plugin. Use Hotjar’s webhook capability with a server-side receiver, or use Hotjar’s Zapier trigger as middleware.

What Hotjar event sends the email?

Use the survey_response webhook event. It is sent when a new Hotjar Survey response is created.

Where should the Volanea API key be stored?

Store it only in server-side secrets for your webhook receiver, queue worker, or approved automation platform connection. Never put it in Hotjar Survey settings, browser JavaScript, a public environment variable, or a client-visible configuration file.

How do I prevent duplicate Hotjar email alerts?

Persist a stable identifier for each response and reuse it as Volanea’s Idempotency-Key. Hotjar can retry failed or timed-out webhook deliveries, so deduplication must be built into the receiver.

Why did Hotjar deliver a webhook but no email arrive?

Check the receiver logs first: signature validation, event filtering, queue state, and Volanea API response. Then check that the Volanea sender domain is verified and review Volanea delivery events; API acceptance and final mailbox delivery are separate stages.