How to Send Email From SurveyMonkey with Volanea

If you need to send email from SurveyMonkey, the reliable approach is to use SurveyMonkey’s response-completed webhook as a notification, retrieve the completed response through the SurveyMonkey API, and send the resulting message through Volanea. That architecture keeps email credentials private and avoids treating a survey webhook as if it already contains every answer.

SurveyMonkey does not provide a native Volanea app or marketplace plugin. The integration is therefore a webhook-and-middleware pattern: SurveyMonkey tells your server that a response has been completed; your server fetches the complete response, maps approved fields into an email, and makes a Volanea REST API request. It is slightly more work than a one-click connector, but it gives you control over consent, duplicate prevention, templates, error handling, and the data that enters an outbound email.

What the SurveyMonkey trigger actually is

The event that starts this workflow is SurveyMonkey’s response_completed webhook event. It fires when a respondent completes a response to a survey that your webhook subscription covers. This distinction matters: a response being created or modified is not necessarily a response that a person has finished submitting.

SurveyMonkey webhooks are notifications. A notification identifies the event and the response-related resources; it is not a complete copy of every question and answer in the survey. Your endpoint should use the identifiers in the webhook to retrieve the response details before deciding whether an email should be sent.

A representative response_completed notification has this shape:

{
  "event": "response_completed",
  "object_type": "response",
  "object_id": "1234567890",
  "resources": {
    "survey_id": "9876543210",
    "collector_id": "2468013579"
  }
}

In this payload:

• event tells your application why SurveyMonkey contacted it. Only process response_completed for this use case.
• object_type is response, confirming that object_id is a response identifier.
• object_id is the completed response ID that your server will request from the SurveyMonkey API.
• resources.survey_id identifies the survey containing the response.
• resources.collector_id identifies the collector that accepted the response. This is useful when different collectors represent different audiences or campaigns.

Webhook availability and API access can depend on your SurveyMonkey account, plan, and permissions. Before building production automation, confirm that the account owner can create API webhooks and that the OAuth token or app has access to the intended survey. If native webhooks are not available to your account, use the Zapier or Make route described later rather than attempting to run browser-side code against SurveyMonkey.

Why the webhook must go to middleware

It is tempting to point SurveyMonkey at an email API endpoint directly. Do not do that. The SurveyMonkey webhook has no reason to contain your Volanea credential, and the email API call needs logic that SurveyMonkey’s notification does not perform: fetching answer data, validating consent, choosing a template, escaping submitted text, and suppressing duplicates.

Your middleware can be a serverless function, container endpoint, worker, or application route. It needs a public HTTPS URL that SurveyMonkey can reach. Its responsibilities are deliberately narrow:

1. Receive the webhook notification and validate that it is an expected event.
2. Persist an idempotency record keyed to the SurveyMonkey response ID.
3. Call SurveyMonkey’s response-details endpoint using a server-side SurveyMonkey access token.
4. Extract only the survey fields that are approved for email use.
5. Send one Volanea REST API request.
6. Record the result and return a successful response quickly enough for webhook delivery.

The credentials belong on this server, not in a survey, client-side JavaScript bundle, public Git repository, or URL query string. In practical terms, store VOLANEA_API_KEY in the environment-variable or secret-store facility used by your hosting provider. Store the SurveyMonkey OAuth access token there as well.

This is also why a “hidden” field in a survey is not a safe place for an email API key. A respondent can inspect browser traffic, modify a submitted value, or otherwise access configuration sent to the client. An email-sending credential grants the ability to send mail as your domain; exposure can lead to abuse, damaged deliverability, and expensive incident response.

Create a SurveyMonkey webhook subscription

SurveyMonkey’s API provides a webhooks resource for registering subscriptions. The subscription is configured against an event type and an object scope, with a subscription_url pointing to your HTTPS endpoint. For a completion-email workflow, the relevant event type is response_completed and the object scope is the survey you want to monitor.

The exact authorization and subscription setup should be performed by a server-side administration script or internal configuration tool, not from a respondent-facing page. SurveyMonkey API requests use an OAuth bearer token, and the user granting that token must have permission to access the target survey.

At a high level, the webhook subscription data includes:

{
  "name": "Completed response email relay",
  "event_type": "response_completed",
  "object_type": "survey",
  "object_ids": ["9876543210"],
  "subscription_url": "https://example.yourdomain.com/webhooks/surveymonkey"
}

Treat the survey ID in object_ids as configuration, not a value supplied by the webhook request. Restricting the subscription to specific survey IDs reduces the risk that an unrelated survey response starts an email flow.

Use a dedicated endpoint, such as /webhooks/surveymonkey, rather than sharing a generic catch-all route with unrelated integrations. This makes logs, access controls, alerting, and incident investigation much clearer. It also makes it easier to rotate endpoints if you need to replace infrastructure.

Design for a fast acknowledgement

Webhook providers generally expect an HTTP success response promptly. Fetching a response and sending an email may sometimes take longer than a webhook delivery window, especially if either downstream API is slow. A robust design writes the event to a queue or database, returns a 2xx response, and processes the job asynchronously.

For lower-volume use cases, a single request handler can perform the work synchronously, provided it has conservative timeouts and idempotency protection. The important principle is that a timeout is not proof that SurveyMonkey did not deliver the event; it can cause a redelivery even when your server began processing it.

Fetch the complete response before composing email

The webhook identifies a response but does not carry the full survey answer tree. Fetch the detailed response through SurveyMonkey’s API using the survey ID and response ID:

GET /v3/surveys/{survey_id}/responses/{response_id}/details

A response-details document contains response metadata and a nested pages array. Within each page are questions, and each question has an answers array. The nesting is important because a question’s ID is stable for mapping, whereas a question’s position can change when someone edits the survey.

A simplified response can look like this:

{
  "id": "1234567890",
  "collector_id": "2468013579",
  "survey_id": "9876543210",
  "date_modified": "2026-09-24T10:14:00+00:00",
  "pages": [
    {
      "id": "111",
      "questions": [
        {
          "id": "222",
          "answers": [{"text": "alex@example.com"}]
        },
        {
          "id": "333",
          "answers": [{"text": "Alex"}]
        },
        {
          "id": "444",
          "answers": [{"text": "I would like follow-up"}]
        }
      ]
    }
  ]
}

Do not map based on the visible question label alone. Labels may be edited, localized, or duplicated. Instead, record the question IDs for your email address, name, consent, and any segmentation field. Keep those IDs in server-side configuration, ideally per survey version.

Also avoid assuming every answer has text. Choice questions may expose identifiers such as choice_id; matrix questions and other formats can have more complex answer structures. Your mapping function should safely handle missing answers and should allow only expected answer formats into the email workflow.

Working webhook-to-Volanea example

The following Node.js example shows the complete relationship among the SurveyMonkey notification, the response-details lookup, field mapping, and a Volanea send request. It assumes that survey question 222 collects an email address, 333 collects a first name, and 444 is an explicit follow-up consent field.

The Volanea key is read from process.env.VOLANEA_API_KEY, which is server-side configuration. The SurveyMonkey bearer token is likewise read from process.env.SURVEYMONKEY_ACCESS_TOKEN.

import express from "express";

const app = express();
app.use(express.json());

const SURVEY_ID = "9876543210";
const EMAIL_QUESTION_ID = "222";
const FIRST_NAME_QUESTION_ID = "333";
const CONSENT_QUESTION_ID = "444";

function answerText(response, questionId) {
  for (const page of response.pages ?? []) {
    for (const question of page.questions ?? []) {
      if (String(question.id) !== String(questionId)) continue;
      const answer = question.answers?.[0];
      return typeof answer?.text === "string" ? answer.text.trim() : "";
    }
  }
  return "";
}

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

app.post("/webhooks/surveymonkey", async (req, res) => {
  const hook = req.body;

  // Acknowledge irrelevant events without sending email.
  if (
    hook.event !== "response_completed" ||
    hook.object_type !== "response" ||
    hook.resources?.survey_id !== SURVEY_ID ||
    !hook.object_id
  ) {
    return res.sendStatus(204);
  }

  const responseId = hook.object_id;

  // In production, atomically insert responseId into a database here.
  // If it already exists, return 204: this is duplicate delivery.

  const smResponse = await fetch(
    `https://api.surveymonkey.com/v3/surveys/${SURVEY_ID}/responses/${responseId}/details`,
    {
      headers: {
        Authorization: `Bearer ${process.env.SURVEYMONKEY_ACCESS_TOKEN}`
      }
    }
  );

  if (!smResponse.ok) {
    console.error("SurveyMonkey response lookup failed", smResponse.status);
    return res.sendStatus(502);
  }

  const surveyResponse = await smResponse.json();
  const to = answerText(surveyResponse, EMAIL_QUESTION_ID).toLowerCase();
  const firstName = answerText(surveyResponse, FIRST_NAME_QUESTION_ID) || "there";
  const consent = answerText(surveyResponse, CONSENT_QUESTION_ID).toLowerCase();

  // Only send when the respondent explicitly opted in.
  if (!/^\S+@\S+\.\S+$/.test(to) || consent !== "i would like follow-up") {
    return res.sendStatus(204);
  }

  const emailResponse = 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: "Research Team <research@example.com>",
      to: [to],
      subject: "Thanks for completing our survey",
      html: `<p>Hi ${escapeHtml(firstName)},</p><p>Thanks for completing our survey. A member of our team will follow up shortly.</p>`,
      text: `Hi ${firstName},\n\nThanks for completing our survey. A member of our team will follow up shortly.`
    })
  });

  if (!emailResponse.ok) {
    console.error("Volanea send failed", emailResponse.status, await emailResponse.text());
    return res.sendStatus(502);
  }

  return res.sendStatus(202);
});

app.listen(3000);

Before deploying, compare the Volanea request fields and endpoint with the current email API reference and setup guides. In particular, use a verified sender identity, the authentication method configured for your account, and the recipient format specified in the current API documentation.

Field mapping decisions that prevent bad sends

The code intentionally uses explicit question IDs and a consent gate. That is not just defensive programming. Survey responses can contain personal information, free-form text, incomplete optional questions, or answers that should never be copied into an email body.

A sound mapping specification should answer these questions before engineering begins:

• Which question ID supplies the recipient address?
• Is the address collected from the respondent, pre-populated through a collector, or obtained from a separate customer record?
• What exact response represents consent to receive this type of email?
• Which answer fields may appear in a subject line or body?
• What fallback is acceptable when a name or optional answer is missing?
• Is the email transactional, operational, or marketing in nature?

If a message is promotional, a survey checkbox by itself may not satisfy every applicable consent requirement. Work with your privacy and legal teams on the wording, retention, unsubscribe treatment, and applicable jurisdictional rules. If it is transactional, keep the content tightly related to the action the person requested.

Keep Volanea authentication off the client and out of SurveyMonkey

The Volanea API key lives in your middleware’s server-side secret store. It does not belong in the SurveyMonkey survey definition, a custom collector URL, a pre-filled survey variable, or front-end code. SurveyMonkey should know only the public HTTPS address of your webhook endpoint.

This separation delivers several practical benefits. You can rotate the Volanea key without editing survey content. You can create different keys for staging and production. You can limit which server runtime reads the key. And your logs can identify a failed send without ever writing the credential itself.

Follow these operational rules:

• Use separate SurveyMonkey and Volanea credentials for development, staging, and production where possible.
• Never log Authorization headers, raw secret values, or entire response payloads containing unnecessary respondent data.
• Restrict access to secret configuration to deployment and operations roles.
• Rotate a credential immediately if it appears in source control, a ticket, a screenshot, or application logs.
• Use a verified sending domain and align your DNS authentication before sending production volume.

A further benefit of middleware is policy enforcement. Your server can reject addresses from a test domain, suppress internal recipients, block messages outside a geographic market, or select a sender based on the collector. SurveyMonkey alone cannot safely act as the email policy engine.

When this breaks: SurveyMonkey-to-email failure modes

Every integration has failure modes, and this one has a particularly important boundary: SurveyMonkey delivers a webhook, then your system calls two separate APIs. Build for ambiguity rather than assuming a webhook results in exactly one email.

Retries can create duplicate sends

Webhook delivery is generally at-least-once, not exactly-once. If your endpoint processes an event but responds too slowly, loses its response, or returns an error after calling Volanea, SurveyMonkey may send the same event again. The response ID will be the same.

Make the SurveyMonkey object_id your idempotency key. Insert it into a durable database with a unique constraint before sending, or store a record with states such as received, sending, sent, and failed. A duplicate delivery should find the existing response ID and return a successful no-op response.

Be careful with the sequence. Marking an event sent before the Volanea request succeeds can suppress a legitimate retry after an outage. Sending first and recording later can send duplicates if the process crashes between those operations. A queue plus durable state machine is the strongest option for meaningful volume.

Webhook timeouts and downstream slowness

A response-details API request or email send can be delayed by network issues, rate limits, DNS problems, or temporary provider errors. If the webhook handler waits on all of those operations, it risks timing out and triggering redelivery.

For production, acknowledge the notification after durably queueing it, then let a worker perform the SurveyMonkey and Volanea calls. Use bounded retry policies for temporary failures and alert on jobs that remain failed. Do not retry permanent failures indefinitely, such as an invalid recipient or a malformed configuration value.

Fields can be absent or change shape

An optional email question may be unanswered. A question can be deleted and recreated, changing its ID. A choice answer may use choice_id rather than text. Different survey designs can result in different response structures, and account access or feature availability can vary by plan.

Treat missing data as a normal branch, not an exceptional crash. If the address, consent, or required identifier is missing, record a non-send outcome and return success. Alert when the rate of missing required fields spikes, because that often signals a survey edit or a mistaken question-ID configuration.

Response lookup can fail even when the webhook is real

A legitimate webhook does not guarantee that your current OAuth credential can retrieve the response. Tokens can expire, permissions can change, or the survey can be moved to another owner. Log the response ID, survey ID, HTTP status, and a safe error category, then notify the integration owner to reauthorize or restore access.

Do not attempt to construct an email from the small webhook notification if the response-details lookup fails. That notification does not contain enough approved recipient information to do so safely.

Testing the integration safely

Start with a dedicated test survey and a sender address that is authenticated for a non-production domain or a controlled test subdomain. Use a mailbox you own. This lets you verify the complete flow without sending messages to real respondents.

A practical test plan includes the following cases:

1. Submit a response with a valid address and affirmative consent; confirm exactly one email arrives.
2. Submit a response with no email address; confirm that no email is attempted and the outcome is recorded.
3. Submit a response with consent declined; confirm that no email is sent.
4. Re-deliver the same webhook payload or invoke the handler twice with the same response ID; confirm that one message is sent.
5. Change an optional answer to include characters such as <, >, and &; confirm that HTML escaping prevents markup injection.
6. Temporarily force the Volanea request to fail; confirm that your queue or retry process preserves the job without sending duplicates.

Inspect delivery behavior beyond the API response. A successful send request means the API accepted the message; it does not guarantee inbox placement. Monitor bounces, complaints, suppression events, and authentication alignment. For valuable workflows, include a test that checks both your sending domain’s DNS records and the rendering of text and HTML versions.

Zapier or Make as the no-code middleware route

If your SurveyMonkey account does not expose the webhook capability you need, or if you do not want to operate an endpoint, Zapier or Make can act as middleware. SurveyMonkey has integrations with automation platforms that can start workflows from survey response activity, and those platforms can make outbound HTTP requests.

The key limitation remains the same: do not put a Volanea API key in anything visible to respondents. Configure it as a private connection credential or secret value in the automation platform, and restrict who can edit the scenario or Zap. If the platform offers a code step, use it only for modest transformations; move complex consent logic and durable idempotency to a server you control.

A typical no-code flow is:

1. SurveyMonkey response trigger in Zapier or Make.
2. Filter step that requires a valid address and affirmative consent.
3. Optional formatting or lookup step to normalize names and select a template.
4. Webhook/custom HTTP action that posts the message JSON to Volanea using a private authorization header.
5. Logging or alerting step for failures.

No-code routes are useful for low-volume internal alerts and quick prototypes. Their trade-offs are less control over raw event delivery, potentially harder duplicate handling, task-based cost, and fewer options for secure response storage. If an email triggers a customer promise, payment-adjacent action, or high-volume campaign, a dedicated webhook consumer is usually the safer long-term design.

Deliverability and message design after a survey

Survey completion is a strong contextual moment for an email, but context does not remove the need for good sending practices. The recipient should recognize why the message arrived, who sent it, and what happens next.

Keep confirmation-style messages simple. Use a recognizable From name, a subject that matches the survey action, and content that does not overstate what will happen. If follow-up may take several business days, say so. If the email contains a copy of answers or sensitive account details, reconsider whether email is an appropriate channel.

Avoid placing raw free-text answers directly in the subject line. Apart from privacy concerns, user-entered text can create awkward, misleading, or unsafe-looking subjects. In the HTML body, escape every dynamic field and use a plain-text alternative. If the email is marketing, include the appropriate unsubscribe mechanism and honor suppression decisions before calling the send API.

SurveyMonkey collectors can also affect your interpretation of data. A response coming through an anonymous collector may not provide a verified identity. Do not assume that an email typed into a free-form question belongs to the person who received a previous invitation. For account-specific workflows, use a secure identity or lookup process rather than trusting a survey answer alone.

A production checklist

Before turning on the workflow for respondents, verify each item below:

• The webhook is subscribed only to the intended survey and response_completed event.
• Your endpoint accepts HTTPS traffic and has observability for delivery failures.
• SurveyMonkey response IDs are stored as durable idempotency keys.
• The response-details API call uses a server-side OAuth token with the correct survey permissions.
• Question IDs, not labels or positions, drive field mapping.
• Consent logic is explicit and tested for blank, changed, and unexpected answers.
• The Volanea API key is stored only in a server-side secret manager or protected automation credential.
• Your sender domain is verified and authenticated for the environment in use.
• HTML dynamic values are escaped, and a plain-text message is supplied.
• Retries distinguish temporary infrastructure errors from permanent validation failures.
• Logs contain safe operational identifiers but not unnecessary survey answer data or secrets.

This checklist is not bureaucracy. It is what turns a seemingly small integration into an email flow that remains predictable when a survey changes, an API slows down, or a webhook is delivered more than once.

Conclusion

The best way to send email from SurveyMonkey with Volanea is not a direct browser integration or a nonexistent marketplace plugin. It is a controlled server-side flow built around the real response_completed webhook event: receive the notification, retrieve the detailed response, apply consent and field mapping rules, then send through Volanea.

That architecture gives you the controls email workflows need: private credentials, resilient retries, duplicate protection, safe HTML handling, and a clear audit trail. Start with one survey and one confirmation message, validate the edge cases, then expand to additional templates or follow-up paths only after the fundamentals are reliable.

FAQ

Can SurveyMonkey send directly to Volanea without middleware?

No native SurveyMonkey-to-Volanea app is required or assumed here. A SurveyMonkey webhook is a notification endpoint, while Volanea requires an authenticated API request. Use your own serverless endpoint, application server, or an automation platform as the secure intermediary.

What SurveyMonkey event should trigger the email?

Use the response_completed webhook event when the email should follow a completed survey response. It is more appropriate than acting on an early response creation or update event when incomplete responses must not receive a message.

Does the SurveyMonkey webhook include all survey answers?

No. The notification identifies the event and response-related resources. Fetch the completed response through GET /v3/surveys/{survey_id}/responses/{response_id}/details, then map the approved question IDs to email fields.

Where should the Volanea API key be stored?

Store it in server-side environment configuration or a managed secret store used by your middleware. Do not include it in survey questions, collector URLs, front-end code, or any respondent-visible configuration.

How do I stop duplicate emails when a webhook retries?

Use the SurveyMonkey response object_id as an idempotency key in durable storage. If the same completed-response ID arrives again, detect the existing record and avoid issuing another Volanea send request.