How to Send Email From SimpleSat With Volanea

SimpleSat is built to collect customer satisfaction feedback, while Volanea is built to deliver application email reliably. To send email from SimpleSat, connect the two through SimpleSat’s Zapier integration, route the response through a secure middleware endpoint, and have that server call Volanea’s email API.

There is an important architectural detail upfront: Volanea does not have a native SimpleSat marketplace app or one-click plugin. That does not prevent the integration, but it does mean the API key and send logic belong in a server-side hop—not in a browser, a survey page, or a client-visible automation field.

What this integration does

The practical use case is simple: a customer submits a SimpleSat survey response, and your workflow decides whether a follow-up email should be sent. A low score might create an immediate recovery message for an account manager to review. A high score might send a thank-you, a review invitation, or an internal notification that includes the response details.

The useful distinction is between the feedback event and the outgoing email:

• SimpleSat is the source of the customer-feedback event.
• Zapier receives the SimpleSat trigger and forwards a deliberately chosen set of fields.
• Your middleware validates the request, applies business rules, prevents duplicates, and keeps secrets safe.
• Volanea sends the final transactional or campaign-style message through its REST email infrastructure.

This design gives you control that a direct point-to-point connector usually cannot. For example, you can suppress sends for already-contacted respondents, select a template by score, send to an internal owner rather than the respondent, or queue the request while your own system is unavailable.

It is also a better fit for feedback data than putting raw survey content into a marketing list automatically. Customer comments can contain personal information, account-specific detail, or language that should be reviewed before a broad campaign action occurs.

The SimpleSat trigger: New Survey Response in Zapier

For this workflow, use SimpleSat’s Zapier trigger for a New Survey Response. It fires when SimpleSat records a new response to a survey. In Zapier, create a Zap, select SimpleSat as the trigger app, choose New Survey Response, connect the SimpleSat account, and test the trigger with a real or representative response.

The test step matters. Feedback tools frequently have fields that are only present when a survey configuration collects them. A survey may have a rating and a comment, while another has a rating but no comment, or a contact record without an email address. Do not build production rules from a single unusually complete sample.

SimpleSat’s Zapier trigger is the event source here. It is not a direct Volanea integration, and Zapier does not expose your Volanea key to SimpleSat. Instead, the next Zap step posts a JSON object to a URL you own. That separation is intentional: it lets your service authenticate the inbound request and make the outbound API call safely.

Decide what should cause an email

Before configuring the webhook action, write the rule in plain language. Good feedback automations are explicit about audience and timing. Examples include:

1. When a response has a detractor-level rating, notify the service owner internally with the score, comment, and customer context.
2. When a response has a promoter-level rating and a usable respondent email, send a thank-you message after a short delay.
3. When a response includes a comment, send an acknowledgement to the respondent only if the survey’s consent and privacy expectations permit it.
4. When a response comes from a strategic account, send to a shared success inbox rather than automatically emailing the customer.

A low score does not automatically mean “email the respondent immediately.” If the recipient has just supplied negative feedback, a templated message can feel impersonal. In many organizations, the better action is an internal alert, followed by a personal response from someone who understands the account.

Filter before you call your service

Add a Zapier Filter step after New Survey Response when the rule is straightforward. For example, permit the Zap to continue only when the rating is at or below the threshold your team uses for escalation, or only when the contact email exists.

Keep nuanced decisions in middleware rather than stacking many Zapier paths. A server-side rule can handle missing values, account exclusions, prior contact, quiet hours, and future changes in one reviewed codebase. A filter is still useful for reducing unnecessary webhook traffic and making the Zap’s purpose obvious to an administrator.

Why a middleware endpoint is the right connection

A Zapier webhook can post data to an HTTPS endpoint, but it should not call an email provider with a long-lived secret embedded in the Zap configuration. Put a small service between Zapier and Volanea. This can be a route in an existing application, a serverless function, or a lightweight worker.

The middleware has four jobs:

• authenticate or verify the inbound webhook;
• normalize SimpleSat response fields into your own stable event schema;
• enforce idempotency and business rules;
• call Volanea with a server-side API key.

This is not needless complexity. It makes operational failure safer. If Zapier retries after a timeout, your service can recognize the same response and avoid sending a second email. If SimpleSat data is incomplete, the service can reject or route the event for review without issuing a malformed send request.

A middleware route also preserves portability. If you later move from Zapier to Make, a native webhook feature, or another automation tool, the send service and Volanea call can remain the same. Only the inbound adapter changes.

Configure the Zapier webhook payload

After the SimpleSat New Survey Response trigger—and any filter or formatter steps—add Webhooks by Zapier. Use its POST action and point it at an HTTPS endpoint such as:

https://automation.example.com/webhooks/simplesat-response

Use JSON as the request payload type. Create a static secret for this inbound connection, such as SIMPL​​ESAT_ZAPIER_WEBHOOK_SECRET, and send it in a request header that your middleware checks. The precise header configuration available in Zapier can vary by webhook action, so test it with the Zap’s test tool and inspect the received request before enabling the Zap.

Do not attempt to mirror every field SimpleSat makes available. Build a minimal contract that is sufficient for the email decision and message. The following is the JSON body your Zapier webhook step should construct by mapping values from the New Survey Response test record:

{
  "event": "simplesat.survey_response.created",
  "response_id": "{{New Survey Response ID}}",
  "survey_id": "{{Survey ID}}",
  "survey_name": "{{Survey Name}}",
  "submitted_at": "{{Response Created At}}",
  "rating": "{{Rating}}",
  "comment": "{{Comment}}",
  "contact": {
    "name": "{{Contact Name}}",
    "email": "{{Contact Email}}",
    "company": "{{Company Name}}"
  }
}

The double-braced strings above are mapping placeholders, not literal SimpleSat values. In the Zap editor, insert the corresponding fields from the SimpleSat New Survey Response output. Field labels can differ by SimpleSat survey configuration and Zapier’s current app version, so use the tested response shown in your own Zap rather than typing a label that is not available.

This is an important distinction about payload shape: SimpleSat’s Zapier trigger provides fields to Zapier, and the Webhooks by Zapier step sends the JSON shape you define. The object above is therefore the stable contract between Zapier and your middleware. It is preferable to making your code depend directly on every upstream field that may appear or disappear.

Field mapping choices

response_id is the most important field. Treat it as the idempotency identity for this workflow. If the trigger runs twice, or if Zapier retries delivery, the same response ID should produce at most one email for a given message purpose.

rating should be treated as data, not as a guaranteed integer. Convert and validate it in your service because survey scales vary. A five-point CSAT rating, a thumbs-up response, and an NPS-style scale do not mean the same thing. Store both the raw value and, if needed, a normalized category such as detractor, neutral, or promoter.

comment can be blank. Never require it unless the particular survey does. Escape it when placing it into HTML, and consider whether an internal alert should include the full text. Customer feedback is often sensitive.

contact.email can also be absent, malformed, or not appropriate for an automated follow-up. Validate it before using it as an email recipient. For one-off checks during testing, the email verification tool can help identify obviously invalid addresses; it is not a substitute for honoring consent, suppression, or your organization’s communication policy.

Store the Volanea API key only on the server

Create the Volanea API key in the Volanea account and store it as a secret in the environment where the middleware runs. For example, a serverless platform may store it as VOLANEA_API_KEY; a container platform may inject it from a secrets manager; an application server may read it from protected runtime configuration.

The key must not live in:

• a SimpleSat survey URL or embedded survey script;
• browser JavaScript or a mobile application bundle;
• a public Git repository or a pasted code sample;
• a Zapier field that is visible to broad workspace administrators when a server-side alternative is available;
• an email template, ticket note, or customer-facing configuration value.

A client-visible key can be copied and used to send mail under your account. That can create a security incident, damage deliverability, and make incident response harder because abusive messages appear to originate from your legitimate infrastructure.

Store a separate inbound webhook secret as well. The Volanea key authenticates your middleware to Volanea. The webhook secret authenticates the automation tool to your middleware. They serve different trust boundaries and should be rotated independently.

Use restricted operational access to the environment where those values are held. If you suspect exposure, rotate the Volanea key, update the secret, redeploy the middleware, and review sending logs for unexpected activity. Volanea’s email API setup guides are the right place to confirm the current API authentication and message-send requirements before deploying.

Send the Volanea message from middleware

The following Node.js example shows the application logic for the inbound payload defined above. It deliberately separates validation, idempotency, recipient selection, and the email send. Replace the indicated Volanea request details with the currently documented endpoint and authentication format from your Volanea account documentation before shipping; API URLs and required fields are provider contracts, not values to guess from an integration article.

import express from "express";

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

const seen = new Set(); // Use Redis or a database table in production.

app.post("/webhooks/simplesat-response", async (req, res) => {
  const suppliedSecret = req.get("x-simplesat-webhook-secret");
  if (!suppliedSecret || suppliedSecret !== process.env.SIMPLESAT_ZAPIER_WEBHOOK_SECRET) {
    return res.status(401).json({ error: "unauthorized" });
  }

  const { response_id, rating, comment = "", contact = {}, survey_name = "SimpleSat survey" } = req.body;
  const numericRating = Number(rating);

  if (!response_id || !Number.isFinite(numericRating)) {
    return res.status(400).json({ error: "response_id and numeric rating are required" });
  }

  // One idempotency key per response and message purpose.
  const messagePurpose = numericRating <= 2 ? "internal-recovery-alert" : "thank-you";
  const idempotencyKey = `simplesat:${response_id}:${messagePurpose}`;

  if (seen.has(idempotencyKey)) {
    return res.status(200).json({ status: "already_processed" });
  }

  const recipient = numericRating <= 2
    ? "customer-success@example.com"
    : contact.email;

  if (!recipient) {
    return res.status(202).json({ status: "skipped", reason: "no_recipient_email" });
  }

  const subject = numericRating <= 2
    ? `Follow up: ${survey_name} score ${numericRating}`
    : "Thank you for your feedback";

  const html = numericRating <= 2
    ? `<p>A new SimpleSat response needs review.</p><p><strong>Customer:</strong> ${escapeHtml(contact.name || "Unknown")}</p><p><strong>Score:</strong> ${numericRating}</p><p><strong>Comment:</strong> ${escapeHtml(comment || "No comment provided")}</p>`
    : `<p>Thank you${contact.name ? `, ${escapeHtml(contact.name)}` : ""} for sharing your feedback.</p>`;

  const volaneaResponse = await fetch(process.env.VOLANEA_EMAIL_SEND_URL, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify({
      from: process.env.VOLANEA_FROM_EMAIL,
      to: [recipient],
      subject,
      html
    })
  });

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

  seen.add(idempotencyKey);
  return res.status(200).json({ status: "sent", response_id });
});

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

app.listen(process.env.PORT || 3000);

The mapping in this code is intentional. response_id becomes the idempotency identity. rating selects the message purpose and recipient. contact.email is only used for the thank-you path, while low ratings go to an internal operational mailbox. comment is HTML-escaped before inclusion in an internal message.

For production, replace the in-memory Set with durable storage. Redis with an expiration, a database table with a unique key, or a queue system with de-duplication are common choices. An in-memory set is erased on restart and does not work correctly across multiple server instances.

Choose transactional, internal, and campaign use cases carefully

Not every email triggered by survey feedback belongs in the same stream. The category affects content, consent expectations, monitoring, and how your team should measure success.

Internal alerts

Internal alerts are usually the safest first automation. Send a low-score alert to a customer-success, service-delivery, or support mailbox. Include a link to the response in SimpleSat if your workflow has one, plus only the information the reviewer needs.

This route avoids surprising the customer while making sure that urgent feedback reaches a human quickly. It is especially appropriate when the respondent may expect a personal follow-up from their regular account contact.

Customer acknowledgements

A thank-you message can be appropriate when customers expect it and the response contains a usable address. Keep it short, identify the sender, and do not imply that someone has personally read the feedback unless that is true.

For negative feedback, be careful with automatic wording. “We are sorry to hear this” is not enough if the email asks the customer to repeat information they already submitted. A better flow is to alert a human and use the automation only to create a task or send a tailored reply after review.

Campaign follow-up

Adding respondents to a promotional campaign is a separate decision from acknowledging their survey response. Survey participation is not automatically marketing consent. If you use response data for segmentation, document the lawful basis and preference handling that applies to your organization.

Keep transactional and promotional programs logically separate. It improves auditability and reduces the chance that a feedback recovery message is delayed, suppressed, or evaluated like a marketing blast.

When this breaks

Every integration needs a failure plan. The failure modes in this specific SimpleSat-to-Zapier-to-middleware-to-Volanea path are predictable, and handling them before launch will save time during a real incident.

Zapier retries can create duplicate sends

A webhook sender may retry when it does not receive a successful response quickly enough, when a network connection closes, or when your endpoint returns an error. The first request may have reached Volanea even though Zapier did not receive your 200 response.

That is why response_id must become an idempotency key. Persist the key before or alongside the send result, use a unique database constraint where possible, and return a successful “already processed” response for a duplicate. Do not rely on a Zap being triggered only once.

Also distinguish message purposes. A response may legitimately create one internal alert and one customer thank-you. Use keys such as simplesat:response-id:internal-recovery-alert and simplesat:response-id:thank-you, not just the response ID alone.

Webhook timeouts can obscure a successful send

Your endpoint should validate, enqueue, and acknowledge quickly. Avoid waiting on slow downstream work if you can use a queue. A robust pattern is: verify the request, store an event keyed by response ID, return a 2xx response, then have a worker call Volanea.

If you do send synchronously, set a conservative outbound timeout, log the provider response, and retain enough state to reconcile uncertain outcomes. A timeout is not proof that an email was not accepted. Retrying blindly can create duplicates.

Some response fields may be missing

SimpleSat survey designs and contact records can differ. A comment may be empty. A contact might not have an email. A company name may be unavailable. Some fields exposed through an integration can also depend on the connected account’s plan, permissions, configuration, or the way a survey was created.

Treat optional fields as optional. Validate required fields at the edge, define a fallback recipient for internal alerts, and record structured reasons for skipped sends. A 202 skipped: no_recipient_email outcome is much more useful than a generic error with no context.

Rating scales can be misunderstood

Do not hard-code “2 or lower is bad” until you know the survey’s scale. A five-star survey, a 1–10 survey, and a binary survey need different classification rules. Store survey configuration or map by survey ID so that a rating of 1 is not accidentally interpreted in the wrong context.

Email acceptance is not inbox placement

A successful API response means the provider accepted the request; it does not guarantee that the recipient saw it in the inbox. Use a verified sending domain, appropriate authentication, sensible content, and suppression handling. For internal alerts, make sure the destination mailbox or distribution group accepts the sender and is monitored.

Test the workflow before enabling it

Test with a dedicated internal recipient first. Use separate cases for a low rating with a comment, a high rating with an email address, a response without a comment, and a response without an email address. Review the Zap history, middleware logs, and Volanea send results together.

A practical test checklist is:

1. Submit a SimpleSat survey response and confirm New Survey Response appears in Zapier.
2. Confirm the webhook body contains the intended response_id, rating, comment, and contact fields.
3. Send the same payload twice and verify only one email is sent for the same purpose.
4. Remove contact.email and confirm the service skips or routes the event according to your policy.
5. Force a temporary Volanea failure and confirm the event is retried or recorded without duplicate sends.
6. Inspect the received email on desktop and mobile, including the rendered comment and sender identity.

Log event IDs, not more personal data than necessary. A useful log record includes the response ID, event time, selected rule, recipient class, provider result, and idempotency key. Avoid writing full comment text or email addresses to broad-access logs unless your privacy and retention policies support it.

Alternatives if Zapier is not your preferred automation layer

Zapier is a good route when you want a no-code SimpleSat trigger and a small amount of custom code. It is not the only operational pattern.

Make can play the same intermediary role if your team already uses it for workflow automation. The key design remains unchanged: take the new response event, send a minimal normalized JSON body to a secure endpoint, and let server-side code call Volanea.

If your organization has an integration platform, use it as the inbound event collector but keep the idempotency and secret-management requirements. If SimpleSat account features or plan limits mean a desired field is not present in the automation trigger, do not fabricate it from the email body. Use the available response identifier to fetch approved data from your system of record, or redesign the workflow around fields that are reliably available.

For teams that need zero custom infrastructure, an automation platform can sometimes call an email API directly. That approach is faster to prototype but weaker for secret governance, duplicate protection, and detailed logging. It is usually better reserved for low-risk internal notices than for customer-facing sends.

Operational guidance for long-term reliability

Assign ownership. Someone should own the SimpleSat survey configuration, someone should own the Zap, and someone should own the middleware and Volanea sending domain. A workflow that spans three systems fails silently when each team assumes another team monitors it.

Review the integration after survey changes. Adding a new question, changing rating scale, renaming a survey, or switching contact-data practices can affect fields and rules. Version the middleware event schema if multiple survey programs need substantially different data.

Set a retention policy for raw feedback in logs and queues. Feedback may be valuable operational data, but keeping it indefinitely in webhook logs is rarely necessary. Store the minimal information needed to trace delivery, and preserve the authoritative survey response in SimpleSat or your approved customer system.

Finally, monitor business outcomes, not just HTTP status codes. Track how quickly low ratings are reviewed, whether recipients receive useful follow-up, whether thank-you emails generate complaints, and whether automation meaningfully improves response time. The objective is better customer recovery and communication—not merely a successful API request.

FAQ

Can I send email from SimpleSat directly to Volanea?

Not through a native Volanea SimpleSat app or marketplace plugin. Use SimpleSat’s New Survey Response trigger in Zapier, post a controlled payload to middleware, and send from that server through Volanea.

Where should I put the Volanea API key?

Store it only in server-side secret storage used by your middleware, such as an environment secret or secrets manager. Do not place it in survey code, browser JavaScript, or a client-visible configuration.

How do I stop duplicate emails after a retry?

Use the SimpleSat response ID plus a message-purpose value as an idempotency key, persist it in a durable store, and treat repeated requests with the same key as already processed.

What if the SimpleSat response has no email address?

Do not attempt a customer-facing send. Skip the acknowledgement or route an internal alert to a known team mailbox, and log the reason so the workflow can be reviewed.

Should a negative SimpleSat score trigger an automatic customer email?

Usually, an internal alert and human review is safer. A negative score often needs account context and a personal response; automation is most valuable for ensuring the right person sees the feedback quickly.