Send email from Trustpilot when a new review arrives by connecting Trustpilot’s native review webhooks to a small server-side relay that calls Volanea. There is no native Volanea app, Trustpilot Marketplace listing, or one-click plugin for this workflow—but Trustpilot’s webhook notifications provide the direct integration point.
The practical use case is usually an internal notification, not an email to the reviewer. A newly published Trustpilot review can alert customer support, an account owner, a location manager, or an escalation mailbox within seconds. The relay receives Trustpilot’s review JSON, decides whether the review matters, formats the data safely, and uses Volanea to send the message from your verified domain.
This guide uses Trustpilot’s New Review webhook event for service reviews. In the webhook payload, that event is named service-review-created. The same architectural pattern applies to product reviews, revised reviews, and deleted reviews, but the field mapping below intentionally starts with the best-supported and most useful alert: a new service review.
What this integration does—and does not do
The flow is deliberately simple:
- A customer publishes a service review on Trustpilot.
- Trustpilot sends a JSON
POSTrequest to a webhook URL you control. - Your server validates the payload, checks whether it has already handled that review event, and applies any routing rules.
- Your server calls Volanea’s
POST /v1/sendendpoint with a secret API key. - Volanea accepts the email for delivery and returns a response your application can log.
Trustpilot describes webhook notifications as subscriptions that send JSON POST requests to your server when a selected review event occurs. In Trustpilot Business, the configuration path is Integrations > Developers > Webhook Notifications. Webhook notifications are available on Plus, Premium, and Enterprise plans according to Trustpilot’s current help documentation.
What this does not do is expose Volanea directly to Trustpilot or put an email key in a browser. Trustpilot’s webhook subscription asks for a destination URI; it is not a generic outbound HTTP workflow editor where you can safely configure a downstream email API secret. Your receiver is the security and reliability boundary between the two systems.
It also does not use the review author’s email address. Trustpilot’s documented service-review webhook payload does not include customer email addresses. If you need to associate the review with an existing customer, use referenceId as the lookup key in your own order, CRM, or customer database. Do not guess an address from a reviewer name.
The concrete Trustpilot trigger: New Review
For this integration, the initiating event is a customer writing a new review. In the Trustpilot Business interface, choose New Review in the Service Reviews webhook section. Trustpilot delivers the event in the JSON payload as:
service-review-created
Trustpilot supports review-created, review-deleted, and review-revised notifications for both service and product reviews. Start with one subscription for new service reviews. It gives your team a clean way to test the notification format, escalation rules, and email design before adding revision and deletion behavior.
A useful policy is to send every review to an archive or shared feedback inbox, while escalating only low-star reviews to a response team. That means a five-star review can produce a lightweight notification or simply be recorded, while a one- or two-star review creates a more prominent alert. The decision belongs in your relay, where it can be reviewed, versioned, and tested.
Create the Trustpilot webhook subscription
In Trustpilot Business:
- Open Integrations > Developers > Webhook Notifications.
- Under Service Reviews, select the New Review event type.
- Choose Add new subscription.
- Enter your public HTTPS endpoint, for example
https://hooks.example.com/trustpilot/reviews. - Use Test before saving the subscription.
- Save the subscription after your receiver returns a successful response.
Use a dedicated endpoint rather than reusing a public form handler or a catch-all API route. A dedicated endpoint is easier to monitor, easier to limit at the edge, and much less likely to be accidentally changed by unrelated application work.
Your server must be publicly reachable over HTTPS. A localhost URL, a browser route, or a private internal hostname cannot receive Trustpilot’s server-to-server request. For local development, use a controlled HTTPS tunnel only long enough to inspect the test payload; use a stable production hostname for the saved subscription.
Trustpilot’s service-review webhook payload
Trustpilot documents a new service review payload with an events array. Each event has an eventName, a version, and an eventData object. The important fields for an internal alert are the review ID, title, review text, star rating, language, creation time, reference ID, review link, consumer display name, and tags.
Here is the documented shape, shortened only by using example values of the same types:
{
"events": [
{
"eventName": "service-review-created",
"version": "1",
"eventData": {
"id": "53bffd360000640002975387",
"language": "en",
"title": "Great service",
"text": "Nothing other than excellent customer service.",
"referenceId": "ABC-123-xyz",
"stars": 5,
"createdAt": "2017-05-20T09:34:44.000Z",
"isVerified": true,
"locationId": "43f51215-a1fc-4c60-b6dd-e4afb6d7b831",
"link": "https://api.trustpilot.com/v1/reviews/53bffd360000640002975387",
"consumer": {
"id": "53bffc3900006400017e5db8",
"name": "Customer",
"link": "https://api.trustpilot.com/v1/consumers/53bffd360000640002975387"
},
"tags": [
{ "group": "Generic", "value": "Tag value" }
]
}
}
]
}
The events array matters. Do not write the integration as though Trustpilot will always send one top-level review object. Iterate through body.events, filter by eventName, and process every supported event in the delivery. That protects you if a delivery contains more than one item and makes your application’s intent explicit.
Field mapping for an internal alert
A sensible mapping looks like this:
| Trustpilot field | Volanea email use | Why it matters |
|---|---|---|
eventData.id | Idempotency key input and email metadata | A stable review identifier prevents duplicate alerts. |
eventData.stars | Subject line and escalation rule | Lets you route low-star reviews differently. |
eventData.title | Email subject and HTML heading | Gives recipients immediate context. |
eventData.text | Email body | Contains the reviewer’s feedback. Escape it before placing it in HTML. |
eventData.consumer.name | Email body | A display name only; do not treat it as an email address. |
eventData.referenceId | Customer or order lookup | Lets your internal systems find the associated transaction. |
eventData.createdAt | Email body and logs | Preserves the review timestamp. |
eventData.link | Email link | Lets the team open the review resource or retrieve more information. |
eventData.isVerified | Email body | Helps recipients understand review status. |
eventData.tags | Routing or context | Can support queue assignment if your tagging scheme is consistent. |
The destination address is your own internal mailbox or distribution list, such as reviews@yourcompany.com or support-escalations@yourcompany.com. It comes from a server environment variable, not from the Trustpilot payload.
Build the secure webhook relay
A server-side receiver can run in Express, Fastify, Next.js route handlers, a cloud function, or a worker runtime. The example below uses Express and Node.js because it makes the HTTP boundary easy to see.
The code performs four jobs:
- accepts the Trustpilot JSON payload;
- filters for
service-review-created; - derives a stable idempotency key from the review ID;
- sends an email using Volanea’s REST endpoint.
It intentionally returns a success response only after all event processing completes. For higher-volume environments, replace the in-request send with a durable queue: record the event, return success, and have a worker make the Volanea call. That design keeps webhook latency low and provides a recoverable audit trail.
import express from "express";
import crypto from "node:crypto";
const app = express();
app.use(express.json({ limit: "256kb" }));
const {
VOLANEA_API_KEY,
VOLANEA_FROM,
TRUSTPILOT_ALERT_TO,
TRUSTPILOT_WEBHOOK_PATH_TOKEN
} = process.env;
if (!VOLANEA_API_KEY || !VOLANEA_FROM || !TRUSTPILOT_ALERT_TO || !TRUSTPILOT_WEBHOOK_PATH_TOKEN) {
throw new Error("Missing required environment variables");
}
function escapeHtml(value = "") {
return String(value)
.replaceAll("&", "&")
.replaceAll("<", "<")
.replaceAll(">", ">")
.replaceAll('"', """)
.replaceAll("'", "'");
}
function starsLabel(stars) {
return "★".repeat(Number(stars) || 0) + "☆".repeat(Math.max(0, 5 - (Number(stars) || 0)));
}
async function sendReviewAlert(review) {
const reviewId = review.id;
const idempotencyKey = crypto
.createHash("sha256")
.update(`trustpilot:service-review-created:${reviewId}`)
.digest("hex");
const title = review.title || "Untitled review";
const reviewText = review.text || "No review text was supplied.";
const reviewer = review.consumer?.name || "Unknown reviewer";
const tags = Array.isArray(review.tags)
? review.tags.map((tag) => `${tag.group}: ${tag.value}`).join(", ")
: "None";
const subject = `[Trustpilot] ${review.stars}/5 review: ${title}`;
const text = [
`New Trustpilot service review: ${review.stars}/5`,
`Title: ${title}`,
`Reviewer: ${reviewer}`,
`Verified: ${review.isVerified ? "Yes" : "No"}`,
`Reference ID: ${review.referenceId || "Not supplied"}`,
`Created: ${review.createdAt || "Not supplied"}`,
`Tags: ${tags}`,
"",
reviewText,
"",
`Review API link: ${review.link || "Not supplied"}`
].join("\n");
const html = `
<h1>New Trustpilot service review</h1>
<p><strong>Rating:</strong> ${escapeHtml(starsLabel(review.stars))} (${escapeHtml(review.stars)}/5)</p>
<p><strong>Title:</strong> ${escapeHtml(title)}</p>
<p><strong>Reviewer:</strong> ${escapeHtml(reviewer)}</p>
<p><strong>Verified:</strong> ${review.isVerified ? "Yes" : "No"}</p>
<p><strong>Reference ID:</strong> ${escapeHtml(review.referenceId || "Not supplied")}</p>
<p><strong>Created:</strong> ${escapeHtml(review.createdAt || "Not supplied")}</p>
<p><strong>Tags:</strong> ${escapeHtml(tags)}</p>
<hr />
<p>${escapeHtml(reviewText).replaceAll("\n", "<br />")}</p>
${review.link ? `<p><a href="${escapeHtml(review.link)}">Open review resource</a></p>` : ""}
`;
const response = await fetch("https://api.volanea.com/v1/send", {
method: "POST",
headers: {
"Authorization": `Bearer ${VOLANEA_API_KEY}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey
},
body: JSON.stringify({
from: VOLANEA_FROM,
to: TRUSTPILOT_ALERT_TO,
subject,
text,
html
})
});
const responseText = await response.text();
if (!response.ok) {
throw new Error(`Volanea send failed (${response.status}): ${responseText}`);
}
return responseText;
}
app.post(`/webhooks/trustpilot/${TRUSTPILOT_WEBHOOK_PATH_TOKEN}`, async (req, res) => {
const events = Array.isArray(req.body?.events) ? req.body.events : [];
try {
for (const event of events) {
if (event?.eventName !== "service-review-created") continue;
if (!event.eventData?.id) {
throw new Error("Trustpilot event is missing eventData.id");
}
// Example policy: email only low-star reviews.
// Remove this condition to notify on every new service review.
if (Number(event.eventData.stars) <= 2) {
await sendReviewAlert(event.eventData);
}
}
res.status(200).json({ ok: true });
} catch (error) {
console.error("Trustpilot webhook processing failed", error);
res.status(500).json({ ok: false });
}
});
app.listen(3000, () => console.log("Webhook receiver listening on port 3000"));
The Volanea request uses POST https://api.volanea.com/v1/send, Bearer authentication, JSON content, and an Idempotency-Key header. The single-send endpoint supports a message addressed to one recipient or up to 50 recipients, but use one internal destination per alert where possible. Separate sends make escalation, investigation, and recipient-specific policy clearer.
Before enabling the production subscription, verify the domain used in VOLANEA_FROM. A message from an unverified sender domain should not be the first thing you discover through a negative-review alert. The Volanea API reference and setup guides cover authenticated sending, verified domains, templates, and response handling.
Keep the Volanea key out of Trustpilot
The Volanea secret key lives nowhere on the Trustpilot side. Store it only in the secret manager or encrypted environment configuration of the server, function, or automation platform that receives the Trustpilot webhook.
For the Express example, the relevant server-only variables are:
VOLANEA_API_KEY=sk_live_replace_with_your_secret
VOLANEA_FROM=Trustpilot Alerts <alerts@updates.example.com>
TRUSTPILOT_ALERT_TO=support-escalations@example.com
TRUSTPILOT_WEBHOOK_PATH_TOKEN=a-long-random-non-secret-route-token
Never place VOLANEA_API_KEY in:
- a website’s JavaScript bundle;
- a mobile application;
- a public Git repository;
- a Trustpilot review template or email template;
- a query string;
- a client-visible automation field;
- logs, error messages, screenshots, or support tickets.
A Volanea secret key authorizes email sending. If a browser or client application can read it, anyone who can inspect that client can potentially misuse it. The same problem applies to a generic webhook relay that exposes its action configuration publicly.
Trustpilot’s documented webhook setup centers on the subscription URI. Since the public instructions do not document a per-subscription custom authorization header or signing secret, do not invent either one. Use a long unguessable path token, terminate TLS correctly, apply application firewall and rate-limit controls at your hosting edge, and treat the endpoint as an internet-facing ingestion route. If your security model needs cryptographic source verification, place a gateway in front of the receiver and document the controls you have actually configured.
Rotate the Volanea key if it is ever exposed. Use separate keys for development and production where your account configuration permits it, and update the server secret before revoking the old key so review notifications do not silently stop.
Route and format the right alerts
A Trustpilot review event is not automatically a customer-support emergency. Sending every event to every person creates notification fatigue, which eventually makes important feedback easier to miss. Add explicit policy after you prove that the basic delivery works.
Useful routing rules
Consider rules such as:
- One- and two-star reviews: send immediately to the support escalation inbox.
- Three-star reviews: create an internal follow-up message during business hours.
- Four- and five-star reviews: send to a social-proof or customer-success digest rather than paging support.
- Specific
locationIdvalues: route to the manager responsible for that location. - Known
referenceIdprefixes: route enterprise, marketplace, or subscription orders to their owning team. - Sensitive text terms: notify a compliance or operations mailbox, but never make automated conclusions based only on keyword matching.
Keep the original review text intact for internal recipients, but HTML-escape it before composing the email. Review text is user-provided content. Without escaping, a quote containing markup-like characters can change the structure of your alert email or produce misleading visual output.
The example includes both plain text and HTML. Plain text improves readability in minimalist mail clients and makes the notification resilient when HTML is disabled. HTML lets you make the rating, reference ID, and next action visually scannable.
Add a stored template when the format stabilizes
Inline HTML is ideal for an initial integration because all mapping lives in one deployable unit. Once the message design is stable, consider moving the alert into a Volanea stored template and pass the review values as variables. That lets non-code changes to layout and copy be versioned in your email system, while the server still owns policy, escaping, recipient choice, and idempotency.
Keep sensitive or long raw data out of the subject line. Subject lines appear in inbox previews, notification banners, and forwarded threads. A rating, general title, and review ID are usually sufficient; place detailed feedback in the body.
Prevent duplicate email from Trustpilot webhooks
Webhook delivery is a distributed-systems boundary, not a database transaction. Your service can successfully submit an email to Volanea and then fail before it sends the HTTP success response to Trustpilot. The sender may treat that response failure as an unsuccessful delivery and attempt the webhook again. If your receiver blindly sends a new email for each request, your team can get duplicate alerts for one review.
That is why the example derives an idempotency key from two stable values:
trustpilot:service-review-created:<review-id>
The review ID is the essential part. It identifies the Trustpilot review associated with the event, while the event name prevents a future revised-review flow from colliding with the original-review flow. The same idempotency key must be reused only when retrying the same logical email action.
Volanea supports the Idempotency-Key header on POST /v1/send for safe retries. It is not a substitute for application records in every case, but it is a crucial second line of defense when the webhook processor repeats the same send attempt because of network uncertainty.
For production, add a durable event table or key-value record as well:
| Field | Example value |
|---|---|
source | trustpilot |
event_name | service-review-created |
review_id | 53bffd360000640002975387 |
notification_policy | low-star-alert-v1 |
status | accepted, skipped, or failed |
volanea_response | Stored response or message ID |
received_at | Your server timestamp |
Make the unique key (source, event_name, review_id, notification_policy). This lets you intentionally change policy later without accidentally replaying an old notification, while still preventing duplicate sends under the same policy.
When this breaks
Every integration eventually encounters a failure at one of its hops. The right response is to identify the hop instead of treating “no email arrived” as one generic problem.
Trustpilot retries cause duplicate alerts
If Trustpilot does not receive a successful response from your endpoint—for example, because your process crashes after submitting the Volanea request, your load balancer closes the connection, or the request times out—the same review notification can be delivered again. Trustpilot’s help page documents the POST delivery model but does not publish a retry schedule in the webhook setup article, so build for at-least-once delivery rather than assuming exactly once.
Fix: derive a deterministic Idempotency-Key from eventName and eventData.id, and persist a processed-event record. Never generate a random idempotency key for every retry; doing that defeats duplicate protection.
The webhook receiver times out
A slow endpoint can turn a valid review event into a reliability issue. DNS delays, cold starts, a slow database query, template rendering, or waiting on an outbound email request all increase the time before Trustpilot receives success.
Fix: acknowledge only after durable acceptance. At modest volume, the direct send approach shown above may be enough. At higher volume, write the event to a queue or database transaction first, return 200, then send through Volanea in a worker. Monitor queue age and failed jobs so a fast webhook acknowledgment does not hide a stalled downstream sender.
A field is missing or shaped differently than expected
Do not assume every service review contains a title, text, consumer name, reference ID, tags, or location ID. The documented payload includes these fields, but practical integrations must tolerate absent optional values, plan differences, historical data variations, and changes in the review source.
Fix: treat eventData.id and eventName as the minimum needed to identify the event. Use fallbacks such as Untitled review, Unknown reviewer, and Not supplied for display fields. Never make the alert recipient depend on consumer.name, and never expect an email address in the service-review webhook payload.
Your Trustpilot plan does not expose webhook notifications
Trustpilot’s current documentation lists webhook notifications on Plus, Premium, and Enterprise. If your account does not show Integrations > Developers > Webhook Notifications, do not pretend that a direct webhook subscription is available.
Fix: confirm the plan and enabled add-ons with Trustpilot first. Trustpilot also offers a Zapier integration for eligible plans, primarily documented for triggering Trustpilot review invitations from events in other apps. It is not the same thing as a native Volanea connector. If you use Zapier or Make as middleware for review alerts, store the Volanea secret in that platform’s protected connection or secret store, use a webhook action to call your own relay where possible, and preserve a stable review-ID-based idempotency key.
Volanea rejects the request
A 401 usually points to an invalid, revoked, or incorrectly injected API key. A sender-related authorization failure commonly means the from domain has not been verified or the sender format does not match your configuration. A 4xx response due to a malformed payload should be logged and investigated, not retried forever.
Fix: log the HTTP status and response body securely, excluding credentials. Confirm that VOLANEA_FROM uses a verified domain, that Authorization contains Bearer followed by the secret key, and that to, from, subject, and content fields are populated before sending.
The email was accepted but is not visible in an inbox
An accepted API response is not identical to a message appearing in a recipient inbox. Downstream suppression rules, recipient filtering, mail-client sorting, or later delivery events can affect the final outcome.
Fix: use a verified sending domain, monitor Volanea’s send and event data, and test with a real internal mailbox. For production alerting, use a dedicated recognizable sender such as alerts@updates.example.com, and make the reply path intentional rather than leaving the recipient unable to respond.
Test the whole path before relying on it
Trustpilot provides a Test action while creating the webhook subscription. Use it, but do not stop at checking that Trustpilot calls your endpoint. A meaningful test validates each boundary.
- Confirm your endpoint receives the expected
eventsarray and logs only non-sensitive identifiers. - Confirm your filter accepts the intended
service-review-createdevent. - Confirm the Volanea request returns a successful response.
- Confirm the email arrives in the chosen internal mailbox.
- Send the same payload twice and confirm the idempotency behavior prevents a duplicate notification.
- Test missing
title,referenceId,tags, andconsumer.namevalues. - Test a one-star review, a three-star review, and a five-star review against your routing policy.
- Intentionally make Volanea unavailable in a non-production environment and confirm your logs, retry behavior, and Trustpilot response handling are understandable.
Build an audit trail around review ID, event name, star rating, route selected, send result, and Volanea message identifier or response. Avoid logging full review text indefinitely unless you have a documented retention reason. Reviews can contain personal information, and operational logs often have broader access than the support team that actually needs the content.
Operational choices that scale
A direct webhook-to-email call is appropriate for low-volume, non-critical review notifications. As the workflow becomes business-critical, separate ingestion from delivery.
The more durable architecture is:
Trustpilot webhook
→ HTTPS receiver
→ validation + durable event record
→ queue
→ notification worker
→ Volanea POST /v1/send
→ email event monitoring
This adds moving parts, but it creates practical advantages. A temporary Volanea API problem does not force your webhook endpoint to remain open while it waits. An application deployment does not need to lose in-flight review alerts. You can replay failed events from your own record without asking Trustpilot to recreate a review. You can also change recipients or templates without changing how source events are ingested.
Use different environments and destinations. Development webhooks should point at a test receiver and test inbox, never the production escalation list. Production and staging should use distinct route tokens, distinct Volanea keys, and distinct sender identities where possible.
Cost is usually small for internal review alerts, but it is still worth understanding how individual sends, templates, and sending volume fit your account. Review transactional email pricing before expanding the workflow to multiple locations, every review, or several escalation recipients.
Conclusion
To send email from Trustpilot with Volanea, use Trustpilot’s native New Review webhook subscription as the trigger and a server-side relay as the bridge. For new service reviews, the event name is service-review-created, and the payload provides the review ID, rating, title, text, reference ID, review link, consumer display name, and related context.
Keep the Volanea API key on your server—not in Trustpilot configuration, frontend code, or a public automation step. Map the review into an internal alert, HTML-escape user-provided fields, and use a deterministic Idempotency-Key based on the event and review ID. Those few design decisions turn a basic review notification into an integration that remains useful when webhook deliveries are retried, fields are missing, or downstream systems are temporarily unavailable.
FAQ
Can I send the alert directly from Trustpilot to Volanea?
Not safely as a direct API-to-API configuration. Trustpilot’s documented webhook setup sends JSON to a subscription URL. Use a server-side endpoint you control, then have that endpoint call Volanea with the API key stored as a server secret.
What Trustpilot event starts this workflow?
For new service reviews, choose New Review under Service Reviews in Webhook Notifications. The JSON event name is service-review-created.
Can I email the person who wrote the Trustpilot review?
Not from the service-review webhook payload alone. Trustpilot documents that customer email addresses are not included. If you have a lawful existing customer relationship, use referenceId to look up the correct customer record in your own system and apply your communication and consent policies.
How do I stop duplicate Trustpilot review alerts?
Set Volanea’s Idempotency-Key header to a stable value such as trustpilot:service-review-created:<review-id>, and store a unique processed-event record in your database. This protects against repeat webhook deliveries after a timeout or uncertain response.
What if I cannot see Webhook Notifications in Trustpilot?
Check your Trustpilot plan and any enabled API or integration add-ons. Trustpilot currently documents webhooks for Plus, Premium, and Enterprise. If the capability is unavailable, use an approved middleware route only after confirming which Trustpilot events your account can expose.