How to Send Email from Reviewflowz with Volanea

Send email from Reviewflowz when a review arrives by routing a Reviewflowz webhook to a secure server-side endpoint, then having that endpoint call Volanea’s transactional email API. This approach is deliberate: Reviewflowz can notify an HTTP endpoint about review activity, while Volanea handles the authenticated send, sender-domain controls, and delivery record.

There is no native Volanea app, Reviewflowz marketplace listing, or one-click Reviewflowz plugin to install. The dependable integration is a webhook-to-API flow:

1. A review arrives in Reviewflowz.
2. A Reviewflowz automation routes that event to an endpoint you control.
3. Your endpoint validates and maps the review data.
4. The endpoint sends an internal alert or follow-up message through Volanea’s POST /v1/send API.
5. A stable idempotency key makes upstream retries safe.

That setup is especially useful for notifying a customer-success inbox about a low rating, sending a sales team a high-value testimonial alert, or escalating reviews containing terms such as “refund,” “bug,” or “cancel.” It is not a way to email the reviewer automatically: public review records usually contain a reviewer name and review text, not a reliable or consented email address. In most implementations, the Volanea recipient is an internal teammate, shared inbox, help desk address, or CRM workflow address.

What triggers the email in Reviewflowz

The concrete Reviewflowz trigger for this integration is a review arrives. Reviewflowz describes review monitoring as a lifecycle with multiple events, including a review arriving, its rating changing, its text being edited, a review being removed, a reply publishing, and a tag matching. For an alert that should produce exactly one email per newly observed review, configure the automation around the arrival event rather than around later review updates.

This distinction matters. A public review is not always immutable. A customer can change a one-star rating to four stars, edit the written text, or delete a review altogether. If your intended message is “A new review needs attention,” the first-arrival event is the cleanest business event. If your intended message is “A review became urgent,” use a separate automation with narrow conditions, such as a rating threshold or a matching tag.

Reviewflowz supports routing review activity to webhooks, alongside destinations such as Slack, Microsoft Teams, Zendesk, Zapier, and email. Create an automation that filters the reviews you care about and routes the qualifying review arrives event to your endpoint’s HTTPS URL.

Recommended trigger rules

Start with a rule that is conservative enough for the team that receives it. A few useful examples are:

• Escalation alert: review arrives, rating is 1 or 2, send to support-escalations@yourcompany.com.
• Praise alert: review arrives, rating is 5, review text is longer than 80 characters, send to an internal marketing inbox.
• Topic alert: review arrives, an AI tag or keyword indicates “billing,” “refund,” or “outage,” send to the responsible team.
• Location alert: review arrives for a particular listing or location, send to that location’s manager.
• Language routing: review arrives and has a specified language, send to the regional support group.

Do not start by sending every event to every team. The point of a webhook-to-email integration is not to recreate a noisy review feed in another inbox. Filter before delivery so the email is an operational cue that someone can act on.

The Reviewflowz review payload to map

Reviewflowz exposes review data through a normalized schema across review platforms. The review record includes fields such as id, platform, rating, language, replied, created_at, author, text, and date. That normalized shape is valuable because a Google review, Trustpilot review, G2 review, or App Store review can be handled by the same relay code rather than by platform-specific parsers.

For the new-review webhook automation, map the normalized review record as the input your endpoint validates. The fields below are the review values to preserve in the alert:

{
  "id": "rev_8421",
  "platform": "trustpilot",
  "rating": 5,
  "author": "Jordan M.",
  "language": "en",
  "text": "Fast, friendly, it just worked.",
  "date": "2026-07-20",
  "created_at": "2026-07-20T09:41:00Z",
  "replied": false
}

Treat this as a review notification payload, not as a customer-contact record. author is display information for the reviewer. It is not an email address, and it should not be copied into Volanea’s to field.

Field mapping for an internal alert

A practical mapping looks like this:

Use id as the identity of the review, not author + rating + text. Reviewers may leave repeated reviews, and text can be changed later. A stable identifier is the right basis for deduplication.

The architecture: Reviewflowz webhook, private relay, Volanea API

A direct browser call to Volanea is the wrong design because it would expose a secret sending key. Instead, place a small relay between Reviewflowz and Volanea. That relay can be a Cloudflare Worker, serverless function, API route, container service, or existing application endpoint.

The relay has four jobs:

1. Accept the Reviewflowz POST request.
2. Check that it reached the intended private endpoint and that required review fields are present.
3. Build a safe, useful email from the review record.
4. Call Volanea with the secret key stored in the relay’s environment.

This boundary also gives you a place to apply business logic that should not live in a no-code rule: suppress repeated notifications, route by location, redact sensitive language from alert bodies, add a link to an internal review console, or push failed sends into a queue.

Why not post directly to Volanea?

Even where an outbound webhook destination can send custom headers, putting a full Volanea secret key into a third-party webhook configuration is a weaker secret-management pattern. A webhook target is configured in an application UI and may be visible to multiple administrators, exported during setup, copied into screenshots, or accidentally pasted into tickets.

More importantly, Reviewflowz is the event source, not the email-sending authority. Keep the Reviewflowz URL configuration limited to a relay URL and a separate endpoint token. Keep the Volanea key in a server-side secret store, where it can be rotated without editing Reviewflowz automations.

For Volanea send options and endpoint details, keep the implementation aligned with the email API reference and setup guides.

Working Cloudflare Worker relay code

The example below is a complete server-side relay for a Reviewflowz new-review webhook. It expects the normalized review fields shown earlier, rejects incomplete events, escapes review text before adding it to HTML, and sends an internal notification through Volanea.

Set these Worker secrets before deploying:

• VOLANEA_API_KEY: your Volanea secret key.
• ALERT_TO: the internal recipient, such as reviews@yourcompany.com.
• ALERT_FROM: a verified sender address, such as alerts@updates.yourcompany.com.
• REVIEWFLOWZ_ENDPOINT_TOKEN: a long random token used only in the webhook URL path.

Configure the Reviewflowz automation webhook URL as:

https://reviews-alerts.example.workers.dev/reviewflowz/YOUR_LONG_RANDOM_TOKEN

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // Reviewflowz calls this endpoint only for the "review arrives" automation.
    // The path token protects the endpoint without exposing the Volanea API key.
    if (
      request.method !== "POST" ||
      url.pathname !== `/reviewflowz/${env.REVIEWFLOWZ_ENDPOINT_TOKEN}`
    ) {
      return new Response("Not found", { status: 404 });
    }

    let review;
    try {
      review = await request.json();
    } catch {
      return Response.json({ error: "invalid_json" }, { status: 400 });
    }

    // Required normalized Reviewflowz review fields for this alert workflow.
    if (
      !review ||
      typeof review.id !== "string" ||
      typeof review.platform !== "string" ||
      typeof review.rating !== "number"
    ) {
      return Response.json(
        { error: "missing_required_review_fields" },
        { status: 422 }
      );
    }

    const escapeHtml = (value) =>
      String(value ?? "")
        .replace(/&/g, "&")
        .replace(/</g, "&lt;")
        .replace(/>/g, "&gt;")
        .replace(/"/g, "&quot;")
        .replace(/'/g, "&#039;");

    const author = review.author || "Unknown reviewer";
    const reviewText = review.text || "No written review was provided.";
    const observedAt = review.created_at || review.date || "Unknown date";
    const replyStatus = review.replied ? "Already replied" : "No reply recorded";

    const subject = `[${review.rating}/5] New ${review.platform} review from ${author}`;

    const text = [
      "A new review arrived in Reviewflowz.",
      "",
      `Platform: ${review.platform}`,
      `Rating: ${review.rating}/5`,
      `Author: ${author}`,
      `Language: ${review.language || "unknown"}`,
      `Observed: ${observedAt}`,
      `Reply status: ${replyStatus}`,
      "",
      "Review:",
      reviewText
    ].join("\n");

    const html = `
      <h2>New review arrived</h2>
      <table role="presentation" cellpadding="6" cellspacing="0" border="0">
        <tr><td><strong>Platform</strong></td><td>${escapeHtml(review.platform)}</td></tr>
        <tr><td><strong>Rating</strong></td><td>${escapeHtml(review.rating)}/5</td></tr>
        <tr><td><strong>Author</strong></td><td>${escapeHtml(author)}</td></tr>
        <tr><td><strong>Language</strong></td><td>${escapeHtml(review.language || "unknown")}</td></tr>
        <tr><td><strong>Observed</strong></td><td>${escapeHtml(observedAt)}</td></tr>
        <tr><td><strong>Reply status</strong></td><td>${escapeHtml(replyStatus)}</td></tr>
      </table>
      <h3>Review</h3>
      <blockquote>${escapeHtml(reviewText).replace(/\n/g, "<br>")}</blockquote>
    `;

    const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        // Stable per newly arrived review. Replays use the same logical send.
        "Idempotency-Key": `reviewflowz-review-arrived:${review.id}`
      },
      body: JSON.stringify({
        from: env.ALERT_FROM,
        to: env.ALERT_TO,
        subject,
        text,
        html
      })
    });

    const responseBody = await volaneaResponse.text();

    if (!volaneaResponse.ok) {
      console.error("Volanea send failed", {
        status: volaneaResponse.status,
        responseBody,
        reviewId: review.id
      });

      // Return a non-2xx result so the source workflow can treat delivery as failed.
      return Response.json(
        { error: "volanea_send_failed", reviewId: review.id },
        { status: 502 }
      );
    }

    return Response.json({
      ok: true,
      reviewId: review.id,
      volanea: JSON.parse(responseBody)
    });
  }
};

This is a direct HTTP route, but not a direct Reviewflowz-to-Volanea route. The relay exists to keep credentials private and make failure handling explicit.

Where the Volanea API key belongs

The Volanea API key belongs nowhere on the Reviewflowz side. Do not put it in a Reviewflowz webhook URL, visible custom payload field, browser JavaScript variable, mobile app configuration, or client-rendered environment variable.

Store it only in the secret manager or environment-variable system of the relay runtime. In the Worker example, VOLANEA_API_KEY is a Worker secret. The code can read it while processing the request, but neither the Reviewflowz automation nor a browser receives the raw key.

The only secret that may appear in the Reviewflowz webhook configuration is a dedicated endpoint token in the URL path. That token is not the Volanea key and should have a limited purpose: it lets the relay reject random internet traffic before it does any work. Rotate it if it is exposed, and rotate the Volanea key separately if there is any chance the sending credential was disclosed.

A practical secret-management checklist

• Use a Volanea secret key with the minimum practical project scope.
• Store the key in your serverless platform’s encrypted secret store.
• Use a separate endpoint token for the Reviewflowz webhook URL.
• Never put the Volanea key in a frontend bundle or browser-accessible .env variable.
• Restrict who can edit the Reviewflowz automation and who can read deployment secrets.
• Rotate the Volanea key when staff access changes or when a credential may have been copied outside approved systems.
• Log message IDs and review IDs, but do not log the API key or full sensitive payloads.

Designing the alert email for useful action

The email should help a human decide what to do next in seconds. That means the subject line needs rating and platform, the body needs the review text, and the email should tell the recipient whether a reply is already present.

A low-rating operational alert might use this subject:

[1/5] New Google review from Jordan M.

A five-star marketing signal might use this subject instead:

[5/5] New Trustpilot testimonial candidate

The relay can decide which subject to create based on the same fields used by Reviewflowz automation conditions. Keep that decision simple at first. You can always add routing and templates after the baseline event is delivering reliably.

Separate alert types rather than mixing intents

Avoid a single one-size-fits-all email for every review. Different teams need different context and different response times.

For example:

1. Support escalation emails should emphasize rating, platform, review text, language, and reply status.
2. Marketing opportunity emails should emphasize strong ratings, rich written feedback, and a reminder to seek permission before using a testimonial outside its original context.
3. Leadership digest emails should summarize trends instead of forwarding every individual review.
4. Product-feedback emails should include tags or keywords only when the team has agreed on a reliable taxonomy.

A clean implementation often uses multiple Reviewflowz automations, each calling a separate URL path or including a narrowly defined purpose in the relay route. That preserves understandable business rules and lets each email stream have its own recipient, sender identity, subject convention, and escalation policy.

Idempotency: protect against duplicate review alerts

Webhook delivery is an at-least-once problem. An upstream service may retry because the relay was slow, because a network connection closed before it received the success response, or because it received a temporary failure. A retry can be correct behavior from the sender’s perspective, even when Volanea successfully accepted the first request.

Without protection, the second delivery becomes a second email. That is how a single one-star review turns into three duplicate alerts in a manager’s inbox.

The Worker sends this header:

Idempotency-Key: reviewflowz-review-arrived:rev_8421

That key is deterministic. The same newly arrived review produces the same key every time, so a retry represents the same logical send. Do not generate a random UUID for this use case; a new random value on every attempt would defeat duplicate protection.

Choose the key to match the event

For a review arrives automation, review.id is usually the correct key component. If you later make a separate “review updated” or “rating changed” automation, do not reuse the exact same key. Those are distinct business events and need a key that includes both the review identity and the event version or update timestamp.

Examples:

reviewflowz-review-arrived:rev_8421
reviewflowz-review-rating-changed:rev_8421:2026-07-21T10:00:00Z
reviewflowz-review-tagged:rev_8421:billing

The point is not to suppress all future activity for a review. The point is to make one defined event safe to replay.

When this breaks

Every integration breaks at boundaries: an event source retries, a payload is incomplete, a destination times out, or a credential changes. Plan for these specific Reviewflowz-to-relay-to-Volanea failure modes before the alert becomes part of an escalation process.

Reviewflowz retries create duplicate sends

If Reviewflowz retries a webhook after a timeout or non-success response, the relay may receive the same review more than once. The deterministic Idempotency-Key in the Volanea request is the first defense. It tells Volanea that repeat attempts with the same logical message should not produce extra deliveries.

Do not rely only on a “sent” boolean in application memory. Serverless runtimes can restart between attempts, and concurrent requests can race. If you need additional control, write the review ID and event type to a durable database before sending, or use a queue with deduplication. For most alert-only workflows, Volanea idempotency plus structured logs is a strong starting point.

The webhook times out before the relay answers

A relay that performs slow work before replying is more likely to be retried. Avoid fetching unrelated APIs, generating large reports, or waiting for human decisions inside the webhook request. Validate the review, make the Volanea request, and return a short response.

If your email composition grows more expensive, acknowledge the webhook after validation and put the send onto a queue. The queue worker can call Volanea asynchronously while retaining the same deterministic idempotency key. This design reduces the chance that a temporary email-provider delay becomes an upstream webhook retry storm.

Some payload fields are absent

Build the relay on the minimum fields required for the alert, not on every optional enrichment field. Review information can vary by source platform, connected listing, automation configuration, or account capability. A review may have a rating but no written text; an author may be absent or abbreviated; a language value may not be available; and fields available through one workflow or plan may not appear in another delivery configuration.

The example requires only id, platform, and rating. It treats author, text, language, date, created_at, and replied as optional. Test the actual payload delivered by your Reviewflowz automation before adding hard requirements. If your workflow needs a missing field, either change the alert copy to work without it or enrich the event server-side from the Reviewflowz API after validating that your account and integration scope can retrieve it.

The Volanea sender is not ready

Volanea can accept a valid API request only when the sender configuration is valid for your project. Use a verified sender address on a domain you control. Do not copy a teammate’s personal address into ALERT_FROM, and do not use an unverified From address just because it looks familiar.

A sender-domain failure should be visible in relay logs and monitored as a configuration issue, not silently ignored. Test with one internal inbox before enabling a Reviewflowz automation for all new reviews.

A review contains hostile or malformed text

Review text is external input. It can include HTML-like characters, unusual Unicode, links, profanity, personal data, or text crafted to disrupt an HTML email. Escape all dynamic values before inserting them into HTML, as the example does. Keep a plain-text alternative as well.

Do not render raw review text as HTML. If you later add links to an internal dashboard, generate those links yourself and URL-encode identifiers rather than trusting URLs included in review text.

The wrong team receives the alert

An email integration can be technically correct and operationally wrong. A five-star review routed to incident responders creates noise; a one-star review sent only to marketing creates delay. Make routing rules visible, give each team an owner, and review the automation conditions quarterly as review volume and organizational responsibilities change.

Testing the integration safely

Test each hop independently before you turn on a production review-arrival automation.

First, deploy the relay with a test Volanea key and an internal test recipient. Then send the sample normalized payload to the endpoint with curl:

curl -X POST \
  "https://reviews-alerts.example.workers.dev/reviewflowz/YOUR_LONG_RANDOM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "rev_test_8421",
    "platform": "trustpilot",
    "rating": 2,
    "author": "Jordan M.",
    "language": "en",
    "text": "Fast, friendly, it just worked.",
    "created_at": "2026-07-20T09:41:00Z",
    "replied": false
  }'

Then repeat the exact same request. The first request should create the logical email send. The repeat should exercise your idempotency path rather than creating a second alert. After that works, connect the Reviewflowz automation and trigger it with a controlled review event or its available test mechanism.

Your acceptance checklist should include:

• The Reviewflowz rule fires only for the intended review-arrival conditions.
• The relay receives JSON and rejects missing required identifiers.
• The email subject contains the correct rating and platform.
• Review text is readable in both HTML and plain text.
• The sender address is verified and appropriate for internal alerts.
• Replaying the same event does not create duplicate mail.
• A Volanea failure returns a non-success result that is visible in logs.
• An absent optional field produces a useful fallback rather than a runtime exception.

A Zapier or Make route when you do not want to host code

If you do not want to operate a Worker or serverless endpoint, Reviewflowz can route the review event to an automation platform such as Zapier. Use a webhook catch step as the trigger, then add a server-side HTTP request step that calls Volanea’s POST /v1/send endpoint.

The same security rule applies: save the Volanea API key in the automation platform’s protected connection or secret configuration, not in a value that is returned to a browser or included in an email template. Map the review record fields into the Volanea body, use Authorization: Bearer ..., and configure a stable idempotency key derived from review.id.

That route is convenient for a simple internal alert, but a private relay remains the better choice when you need strict payload validation, custom security controls, durable deduplication, redaction, high volume, or detailed observability. It also makes it easier to move automation tools later without changing your Volanea sending implementation.

Operational recommendations before launch

Start with a low-volume, high-value use case. A good first workflow is “send a team alert for every newly arrived review rated two stars or lower.” That creates obvious value, makes duplicates easy to notice during testing, and avoids filling inboxes with routine feedback.

As the workflow proves itself, expand carefully:

• Add high-rating testimonial notifications for marketing.
• Route by location, language, platform, or review tags.
• Create a separate event path for review updates instead of altering the new-review path.
• Store a review-to-message correlation record if teams need auditability.
• Monitor Volanea delivery events and relay error logs together.
• Review recipient lists so former employees and obsolete aliases do not continue receiving customer feedback.

For most teams, the important principle is simple: Reviewflowz decides which review event matters, your relay decides how to make the event safe and useful, and Volanea handles the authenticated transactional send. Keeping those responsibilities separate produces a cleaner, safer integration than attempting to turn a review webhook directly into a client-visible email API call.

FAQ

Does Reviewflowz have a native Volanea integration?

No. There is no native Volanea app, marketplace listing, or one-click Reviewflowz plugin. Use a Reviewflowz webhook automation plus a server-side relay or an automation platform HTTP step.

What Reviewflowz event should start the send?

Use the review arrives event when the goal is one alert for each newly observed review. Use separate workflows and separate idempotency keys for rating changes, edits, tag matches, or reply events.

Can I send the alert directly to the person who left the review?

Usually no. A public review record may include a display name, but it does not reliably provide a consented email address. Send the Volanea message to an internal team, shared inbox, or approved workflow destination instead.

Where should I store my Volanea API key?

Store it only in the server-side secret store for your relay, Worker, or automation platform connection. Do not put it in Reviewflowz payload fields, the webhook URL, browser code, or any client-visible configuration.

How do I prevent duplicate emails when a webhook retries?

Set Volanea’s Idempotency-Key header to a stable value derived from the Reviewflowz review ID and the specific event type, such as reviewflowz-review-arrived:rev_8421. Reuse the same key for retries of that same logical alert.