How to Send Email From Survicate With Volanea

Survicate is useful for collecting customer feedback; Volanea is useful for delivering the email that should follow it. This guide explains how to send email from Survicate after a respondent completes a survey, without exposing an email API key in a browser, survey link, or public automation configuration.

There is no native Volanea app, marketplace listing, or one-click Survicate plugin to install. The reliable architecture is a Survicate survey-response webhook pointing to a server-side endpoint you control. That endpoint validates the inbound request, interprets the completed-response payload, applies your business rules, and makes the authenticated Volanea REST request.

That extra hop is deliberate. It is what keeps your Volanea credentials private, lets you deduplicate webhook retries, and prevents every response from automatically becoming an email before you have checked consent, response status, and recipient data.

What this integration does

The trigger for this workflow is a completed survey response in Survicate. Configure Survicate’s webhook integration for the survey or feedback flow you want to monitor, then use the webhook URL of your application as the destination.

At a high level, the path looks like this:

1. A respondent submits and completes a Survicate survey.
2. Survicate posts the completed-response event and response data to your webhook URL.
3. Your relay extracts the respondent email, survey identity, answer data, and response identifier.
4. Your relay decides whether an email is appropriate.
5. Your relay sends one email through Volanea’s REST API.
6. Your database records the Survicate response ID and Volanea message ID for deduplication and support.

This is not a way to send a message inside the survey itself. It is a post-response workflow. Common examples include a thank-you note after a product survey, a support follow-up after negative feedback, an invitation after a positive NPS response, or a confirmation that a feature request was received.

The most important design choice is to treat the survey response as an event, not as automatic permission to market to somebody. A response can justify an operational follow-up in the right context, but it does not erase consent requirements or preferences you already store elsewhere.

Why use a relay rather than putting an API call in Survicate

Survicate can notify an external endpoint about completed responses, but it is not an email-sending runtime. A webhook destination receives a request; it does not provide a safe place to run arbitrary trusted code, query your customer database, or permanently hold your Volanea secret.

A relay can be a small route in an existing application, a serverless function, or an automation scenario with secure connection storage. For production email, a route you operate is usually the clearest option because it gives you control over validation, observability, idempotency, and retry behavior.

Where the Volanea API key belongs

The Volanea API key belongs in a server-side secret store, such as an encrypted deployment secret, a cloud secret manager, or the environment variables of your serverless function. It should not be placed in:

• a Survicate survey’s custom JavaScript or client-side configuration;
• a public webhook URL query string;
• a browser application bundle;
• a response export, spreadsheet, or shared team note;
• an email template or an unencrypted automation field.

The reason is straightforward: a browser-visible key can be copied by any visitor, browser extension, proxy, or person inspecting page assets. A key in a webhook URL is also likely to be retained in logs, analytics systems, browser history, support screenshots, and third-party request records.

On the Survicate side, store only the destination URL for your relay and any inbound authentication material that Survicate’s webhook configuration explicitly supports. Keep the Volanea key on the relay side. The relay adds the authorization header only when it makes the outbound request to Volanea.

What the relay adds beyond security

A relay is also the right place to make decisions that cannot safely be encoded in a URL:

• Send only when the survey response contains a usable email address.
• Send only to contacts with the appropriate follow-up or marketing consent.
• Escalate low scores to support instead of sending a generic thank-you.
• Use one email per response ID, even if the webhook is delivered more than once.
• Escape free-text answers before placing them in HTML.
• Keep an audit trail that associates the survey response with the message sent.

Those are not edge cases. They are the difference between a helpful feedback loop and an automation that produces duplicate, misleading, or unsafe emails.

Set up the Survicate response webhook

In Survicate, create or edit the survey you want to use and configure its webhook integration to send completed survey responses to an HTTPS endpoint you control. The exact availability of webhook settings can depend on your Survicate plan and workspace configuration, so confirm that the survey type and plan expose the webhook integration before you build around it.

Use a dedicated URL, such as:

https://app.example.com/webhooks/survicate

Do not use a development tunnel, a personal endpoint, or a URL that also accepts unrelated application traffic in production. A dedicated route makes it much easier to apply strict request validation and investigate failures.

Collect the recipient address intentionally

A survey response needs an address before it can become an email. Depending on how the survey is distributed, Survicate may associate an identifiable respondent with the response, or the survey may collect email through an email question. Anonymous website-survey responses frequently have no address at all.

Before activating the workflow, decide which of these is your source of truth:

1. Known respondent data: An identified contact’s email is attached to the response through your survey distribution or contact setup.
2. An email question: The respondent enters an address as part of the survey.
3. Your own customer lookup: The webhook contains an internal user identifier, which the relay uses to find the email in your database.

Do not assume that an arbitrary answer is an email. Map the specific question or respondent property you chose, validate the resulting value, and skip the send if it is absent or malformed. If you collect an email in the questionnaire, make clear why you are collecting it and how it will be used.

Test with a controlled response

Submit a test response that includes every field your workflow requires: an address, the score or answer that determines the template, and any name or account data you plan to use. Save the actual webhook request in a secure request log with sensitive values redacted.

This test matters because payload details can differ by survey question type and distribution method. For example, a rating may be represented differently from a free-text answer, and anonymous responses may omit respondent identity entirely. Build against the event your own Survicate setup actually sends, not a guessed field from another survey.

Understand the completed-response payload

Survicate sends response data as JSON to the webhook destination. The event contains response-level metadata plus answers. The exact answer representation varies by question type, so your relay should locate fields by stable question identifiers where available rather than by the visible wording of a question.

A completed-response webhook is conceptually shaped like this: response identity, survey identity, respondent information when available, and an answers collection. A representative response mapping looks like the following. Treat the question IDs as values from your own survey, not as universal Survicate IDs.

{
  "id": "response_01HV...",
  "survey": {
    "id": "survey_123",
    "name": "Quarterly product feedback"
  },
  "respondent": {
    "email": "maya@example.com",
    "first_name": "Maya"
  },
  "answers": [
    {
      "question_id": "q_nps",
      "question": "How likely are you to recommend us?",
      "answer": 9
    },
    {
      "question_id": "q_comment",
      "question": "What could we improve?",
      "answer": "More export options"
    }
  ]
}

The fields that matter for an email workflow are the response ID, a reliably identified recipient, the selected answer values, and enough survey context to choose the correct template. Do not make email logic depend on human-readable question text. Survey editors change wording; question identifiers are the safer contract.

Build a mapping table first

Write down the mapping before writing code. For example:

For an email-question workflow, replace respondent.email with the answer from the known email-question ID. Do not search every answer for a string containing @; that creates false matches and makes a future questionnaire change risky.

Working webhook-to-Volanea example

The following Node.js example shows the full relay pattern: receive JSON, map known question IDs, reject incomplete input, deduplicate by Survicate response ID, and call the Volanea REST email endpoint. Put VOLANEA_API_KEY and your verified sender address in server-side environment variables.

import express from "express";

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

const sentResponseIds = new Set(); // Replace with a database table in production.
const EMAIL_QUESTION_ID = "q_email";
const NPS_QUESTION_ID = "q_nps";
const COMMENT_QUESTION_ID = "q_comment";

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

function answerFor(answers, questionId) {
  const item = answers.find((answer) => answer.question_id === questionId);
  return item?.answer ?? null;
}

app.post("/webhooks/survicate", async (req, res) => {
  const response = req.body;
  const responseId = response.id;
  const answers = Array.isArray(response.answers) ? response.answers : [];

  // Prefer known respondent data; fall back only to the designated email question.
  const recipient = response.respondent?.email || answerFor(answers, EMAIL_QUESTION_ID);
  const firstName = response.respondent?.first_name || "there";
  const score = Number(answerFor(answers, NPS_QUESTION_ID));
  const comment = answerFor(answers, COMMENT_QUESTION_ID) || "";

  if (!responseId) return res.status(400).json({ error: "Missing response ID" });
  if (!recipient || !/^\S+@\S+\.\S+$/.test(recipient)) {
    return res.status(202).json({ skipped: "No valid email address" });
  }
  if (sentResponseIds.has(responseId)) {
    return res.status(200).json({ duplicate: true });
  }

  // Example business rule: do not send the same thank-you to detractors.
  if (Number.isFinite(score) && score <= 6) {
    // Queue a support workflow here instead of emailing automatically.
    return res.status(202).json({ skipped: "Low-score response routed for review" });
  }

  const subject = Number.isFinite(score) && score >= 9
    ? "Thank you for your feedback"
    : "Thanks for sharing your feedback";

  const html = `
    <p>Hi ${escapeHtml(firstName)},</p>
    <p>Thank you for completing our survey.</p>
    ${comment ? `<p>You told us: “${escapeHtml(comment)}”</p>` : ""}
    <p>We appreciate your time.</p>`;

  const volaneaResponse = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      from: process.env.VOLANEA_FROM,
      to: [recipient],
      subject,
      html,
      metadata: {
        survicate_response_id: responseId,
        survicate_survey_id: response.survey?.id || "unknown"
      }
    })
  });

  if (!volaneaResponse.ok) {
    const detail = await volaneaResponse.text();
    console.error("Volanea send failed", volaneaResponse.status, detail);
    return res.status(502).json({ error: "Email provider rejected the send" });
  }

  sentResponseIds.add(responseId);
  return res.status(200).json({ sent: true });
});

app.listen(3000);

The key field mapping is explicit: Survicate’s completed-response ID becomes the deduplication key, the known respondent or email-answer field becomes the Volanea recipient, and selected answers determine content. Before deploying, compare the accessor paths in this example with a captured webhook from your workspace and the current email API reference and setup guides. Use a durable database instead of the in-memory Set; an in-memory set disappears whenever a process restarts.

Design the email around response intent

Survey-triggered messages perform best when they acknowledge the action the respondent just completed. A generic campaign blast with a survey answer inserted into it can feel automated in the wrong way, especially after someone has offered criticism.

A useful segmentation model is:

• Promoters or highly positive respondents: thank them, invite a review only where appropriate, or ask permission to share feedback.
• Passive respondents: thank them and offer a focused next step, such as product education or an optional follow-up.
• Detractors or low scores: create a support task or human review queue before sending an automated message.
• Feature-request respondents: confirm receipt, avoid promising delivery, and connect the request to the correct product-feedback process.
• No identifiable recipient: store the feedback, but do not attempt an email send.

The last category is essential. A survey can be valuable even when it is anonymous. Trying to match anonymous feedback to a guessed email address is a privacy and data-quality mistake.

Keep personalization safe

Free-text feedback is untrusted input. If you include it in HTML, escape it first, as the example does. If you include it in a subject line, remove control characters and impose a length limit. In many cases, a summary or a simple acknowledgement is safer than echoing sensitive feedback back to the respondent.

Also distinguish between a personal name and an arbitrary identifier. If the name is missing, use a neutral greeting rather than exposing an internal user ID or producing “Hi undefined.” These small safeguards improve both deliverability and customer experience.

When this breaks

Every webhook-to-email integration needs a failure plan. The weak point is not only Volanea or Survicate individually; it is the hop between a completed response, your endpoint, and the send request.

Retries can create duplicate emails

Webhook providers commonly retry when a destination does not return a successful response promptly. A timeout can occur after your relay has already submitted the email request but before it has returned 200 OK to Survicate. If you do not deduplicate, a retry can generate a second message.

Use the Survicate response ID as an idempotency key in a database with a unique constraint. Create the record before or atomically with your send workflow. Store states such as received, sending, sent, and failed, plus the Volanea message identifier when available. A unique response ID means that a second delivery becomes a harmless acknowledgment rather than a second email.

Webhook timeouts need a short synchronous path

Do not make the webhook request wait for slow enrichment, CRM queries, several third-party calls, or a human review workflow. Validate and persist the event quickly, return success, then process the email in a queue when possible.

For small volumes, a synchronous send can work, but it should still have a strict timeout and clear failure handling. If your service returns an error after Survicate has sent the event, expect another delivery attempt. That is normal event delivery behavior, not proof that the respondent submitted the survey twice.

Some responses will not include the fields you expect

A field can be absent because a survey is anonymous, a respondent skipped an optional question, a different collector produced a different identity context, or the survey was edited. Webhook availability and response attributes can also vary by Survicate plan, feature entitlement, survey type, and integration configuration.

Handle missing values deliberately:

• Missing response ID: reject and alert; you cannot safely deduplicate it.
• Missing recipient: acknowledge the webhook but skip the send.
• Missing score: use a safe default branch or skip score-based automation.
• Missing comment: do not render an empty quote block.
• Unknown question ID: alert the survey owner because the questionnaire may have changed.

Never convert missing data into a guessed value. “No email sent because identity was unavailable” is a correct outcome, not an integration failure.

A successful API response is not proof of inbox placement

A successful send request means the email provider accepted the message for processing. It does not guarantee that the recipient saw it in the inbox. Sender-domain authentication, content quality, recipient reputation, suppression handling, and mailbox-provider filtering still matter.

Use a verified sending domain, keep the From address consistent with the brand represented in the survey, and avoid turning every feedback event into a high-volume promotional email stream. If this workflow grows, review transactional email pricing and sending limits alongside your expected response volume and retention needs.

Add authentication and request validation

Your relay should not accept arbitrary JSON from the public internet and send emails based on it. If Survicate provides a webhook signing or secret mechanism in your workspace, configure it and verify the supplied signature according to Survicate’s current documentation before parsing and processing the event.

If your available Survicate webhook configuration does not provide signed requests, use a separate unguessable endpoint path, restrict traffic at your edge where feasible, apply rate limits, and keep the endpoint’s behavior narrow. Do not substitute a Volanea API key as an inbound shared secret. That key is for Volanea authorization and must remain server-side.

Log enough data to diagnose failures without recording full response bodies indefinitely. A practical log record includes the response ID, survey ID, event receipt time, decision (sent, skipped, or failed), HTTP status, and returned email message ID. Redact email addresses and free-text answers where they are not necessary for support.

Alternatives when a direct relay is not practical

A no-code platform can provide the middleware layer if your team does not maintain an application backend. Survicate offers integrations with automation platforms such as Zapier, where a new survey response can start a workflow. The automation then needs a secure HTTP action or a supported email-provider action to call your sending service.

This is appropriate for a proof of concept or a low-volume operational workflow, but it does not remove the core requirements. Store the Volanea credential in the automation platform’s encrypted connection or secret field, use the Survicate response ID for deduplication if the platform supports storage, and avoid exposing credentials in client-side steps.

A custom relay is generally preferable when you need any of the following:

1. Strict idempotency across retries.
2. Consent checks against your customer database.
3. Conditional routing for detractor responses.
4. Auditable response-to-message records.
5. Reliable HTML escaping and template control.
6. Predictable behavior during webhook or provider outages.

For teams already using a queue, the best architecture is often webhook endpoint to durable event store to worker to Volanea. That arrangement lets the HTTP endpoint respond rapidly while the worker handles controlled retries and exponential backoff.

Launch checklist

Before enabling this for a live survey, work through the following checklist:

• Confirm that your Survicate plan and survey configuration support the response webhook you intend to use.
• Capture a real test payload from the exact survey and collector you will deploy.
• Map recipient, score, comment, and response ID using stable field or question identifiers.
• Verify the sending domain and From address in Volanea.
• Put the Volanea key in server-side secrets only.
• Verify webhook signatures or apply the strongest available inbound controls.
• Add a unique database constraint for the Survicate response ID.
• Define what happens to low-score, anonymous, incomplete, and unsubscribed responses.
• Escape all user-supplied content that appears in HTML.
• Test a successful response, duplicate delivery, missing email, missing score, and a simulated Volanea API failure.
• Monitor skipped and failed events separately from successful sends.

The most useful test is a timeout scenario: force the send worker or provider call to delay, then verify that a repeated webhook does not produce a repeated email. If that test passes, you have addressed one of the most consequential reliability risks in this integration.

Conclusion

To send email from Survicate with Volanea, use the completed survey response as the trigger, not a nonexistent native plugin. Send Survicate’s webhook to a server-side relay, map stable response fields to a carefully scoped email, and keep the Volanea API key entirely outside of Survicate’s client-visible environment.

A small amount of engineering produces a much stronger workflow: it respects consent, survives retries, avoids duplicate sends, and gives support and product teams a traceable connection between feedback and follow-up. Start with one survey and one narrowly defined message, then expand only after you can see the response IDs, decisions, failures, and delivered-email outcomes clearly.

FAQ

Can Survicate send email through Volanea directly?

Not as a native Volanea marketplace app or plugin. Use Survicate’s completed-response webhook to call a relay you control, and have that relay make the authenticated Volanea API request.

What triggers the email?

The trigger is a completed Survicate survey response delivered to your webhook endpoint. Your relay should then decide whether that specific response meets the conditions for an email.

Where should I put the Volanea API key?

Put it in a server-side secret store or encrypted serverless environment variable. Do not put it in survey JavaScript, a public webhook URL, a browser bundle, or a client-visible configuration field.

How do I stop duplicate follow-up emails?

Persist the Survicate response ID in a database with a unique constraint before sending. If Survicate retries the webhook after a timeout, recognize the existing response ID and return success without sending another message.

What if the response has no email address?

Acknowledge and store the feedback, but skip the email. Only use an address from a known respondent field, a designated email question, or a trusted lookup in your own system.