How to Send Email From Okendo With Volanea

Send email from Okendo without waiting for a native marketplace integration: receive an Okendo webhook in a server-side endpoint, validate and store the event, then call Volanea’s email API. This approach is particularly useful for review thank-yous, negative-review support alerts, UGC follow-ups, and internal moderation notifications.

There is an important limitation to understand first: Volanea does not provide a native Okendo app, marketplace listing, or one-click plugin. The supported integration pattern is an outbound Okendo webhook plus middleware you control. For an implementation that sends immediately and keeps the Volanea secret key private, use a lightweight serverless function, application endpoint, or worker between the two systems.

What triggers an email in Okendo?

For this integration, the concrete trigger is an Okendo Reviews webhook for a review that is Created. In practical terms, a shopper submits a product review through an Okendo review flow, Okendo creates the review record, and Okendo delivers a webhook event to the HTTPS endpoint you subscribed.

Okendo documents review webhooks for three review lifecycle changes:

• Created — the appropriate event for a newly submitted review and the primary trigger used in this guide.
• Updated — useful when a reviewer changes content, adds media, or when a review’s data changes after the original submission.
• Deleted — useful for downstream cleanup, but generally not a reason to send customer email.

A review-created event is a good fit when the email is about the act of reviewing: a thank-you note, a reward confirmation, a request for photo or video UGC, or a private support escalation for a poor rating. It is not a good fit for sending a review-request email after an order; that is a different lifecycle moment and should normally be owned by the review-request process.

Okendo webhooks are available for Reviews, Loyalty, Quizzes, and Surveys on Advanced and above plans. They are configured through the Okendo Merchant REST API rather than through a Volanea installation flow. If your Okendo plan does not include webhooks or API access, skip the direct route and use the middleware alternative described later in this guide.

The integration architecture

The reliable path has three distinct hops:

1. A shopper submits a review in Okendo.
2. Okendo posts the review-created webhook payload to your HTTPS receiver.
3. Your receiver validates the event, deduplicates it, builds the email, and sends it with POST /v1/send at Volanea.

Do not point Okendo directly at Volanea’s send endpoint. Okendo webhooks describe an event; they do not contain a Volanea authorization header, an email-ready body, or a safe place to retain a Volanea secret key. A direct webhook-to-email-API request would also leave you with no proper layer for authentication validation, field normalization, rate handling, or duplicate prevention.

The receiver can be small. It can run as a route in your existing application, a Cloudflare Worker, a Vercel or Netlify function, an AWS Lambda function, or an internal integration service. The critical requirement is that it is server-side, reachable over HTTPS, and able to respond quickly.

Okendo requires a successful HTTP 2xx response within 15 seconds. That means your endpoint should acknowledge receipt quickly rather than doing slow work in the request path. For small volumes, a single endpoint that validates, persists a record, queues the send, and returns 202 Accepted is enough. At larger volume, use a queue so webhook acknowledgement is independent from Volanea delivery work.

What Okendo sends for a created review

A review-created webhook contains the data required to make review-driven decisions, including review identifiers, subscriber and product identifiers, review content, rating, sentiment, recommendation status, review date, reviewer information, attached media, replies, reward or incentive information when applicable, tags, helpfulness counts, and review status.

The details matter because not every field should become email copy. A review body is user-generated content. A reviewer name can be blank. A product review may have no media. A reward may not have been offered. Your relay should treat optional fields as optional and choose defaults deliberately.

At a high level, the event is an envelope containing an event type, a sequenceNumber, and review data. The exact event structure below is the shape the receiver maps for the review-created flow:

{
  "eventType": "review.created",
  "sequenceNumber": 4182,
  "data": {
    "id": "review_01JQ9D3YB3PQ7X2R5K4N8T1V6M",
    "subscriberId": "subscriber_01JQ9CZZ7QW5P0D1A2B3C4D5E6",
    "productId": "gid://shopify/Product/8123456789",
    "variantId": "gid://shopify/ProductVariant/4455667788",
    "title": "Exactly what I wanted",
    "body": "The fit is great and delivery was quick.",
    "rating": 5,
    "sentiment": "positive",
    "recommended": true,
    "dateCreated": "2026-10-10T14:06:19.000Z",
    "reviewer": {
      "name": "Taylor Smith",
      "email": "taylor@example.com",
      "verified": true,
      "location": "Austin, TX"
    },
    "product": {
      "name": "Everyday Jacket",
      "handle": "everyday-jacket"
    },
    "media": []
  }
}

Treat that payload as an inbound contract, not as trusted display content. Store the immutable review identifier and event identifier or sequence data that Okendo provides. Validate that the email value is usable before sending. Escape every user-controlled string before inserting it into HTML. Do not assume a rating, reviewer email, title, body, product name, media array, incentive, or sentiment is always present.

The practical mapping for a basic review thank-you is straightforward:

Do not send the full review body back to the reviewer by default. Quoting user-generated content in a thank-you email creates unnecessary rendering, privacy, and moderation complexity. Use the product name and rating for a simple confirmation, then reserve the review text for internal alerts or carefully reviewed support workflows.

Set up the Okendo webhook subscription

Okendo’s webhook documentation states that subscriptions are created through the Merchant REST API. This is a developer-oriented setup. You need an Okendo API credential with access to create subscriptions, a public HTTPS endpoint, and a way to retain the webhook signing secret or verification configuration supplied for the subscription.

Before subscribing, decide what your endpoint accepts. A narrow endpoint such as POST /webhooks/okendo/reviews is better than a generic public endpoint that tries to process unrelated sources. Keep environments separate as well: a staging Okendo subscription should call a staging receiver using a Volanea test key, while production should call a production receiver using a live key.

Use the Reviews Created topic for the first version. Avoid immediately subscribing to Updated unless you have a business case. An updated review is not inherently a new conversion event. If a shopper edits a typo, a simplistic workflow could otherwise send a second thank-you email.

Your receiver should do these things in this order:

1. Read the raw request body before transforming it.
2. Verify the Okendo webhook signature according to Okendo’s webhook verification documentation.
3. Parse the JSON only after verification succeeds.
4. Confirm that the event is the review-created topic your route accepts.
5. Write a durable deduplication record keyed to the review event.
6. Enqueue the email job or send with a stable Volanea idempotency key.
7. Return a 2xx status before the 15-second deadline.

Okendo notes that webhook delivery order is not guaranteed. Every event includes a sequenceNumber that can help you order events for the same resource type. That is useful when your workflow reacts to both creation and update events. For a created-only thank-you flow, stable deduplication is usually more important than trying to globally reorder every event.

Send the email through Volanea’s REST API

Volanea sends a single transactional message with POST https://api.volanea.com/v1/send. It accepts a secret sk_… or test sk_test_… key and supports the Idempotency-Key header for safe retries. A test key renders and logs messages without delivering them, which makes it the correct choice while validating mappings.

The following Node.js example is a complete server-side handler pattern. It maps a review-created payload into a thank-you email, protects the Volanea key with an environment variable, escapes user-controlled text, and uses the Okendo review ID as the logical send identity.

import express from "express";

const app = express();

// Preserve the raw payload for Okendo signature verification.
app.post(
  "/webhooks/okendo/reviews",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    try {
      const rawBody = req.body;

      // Verify using Okendo's documented webhook-signature procedure here.
      // Verification must use the untouched raw request bytes and your
      // server-side Okendo webhook signing secret.
      const okendoIsValid = await verifyOkendoWebhook(req.headers, rawBody);
      if (!okendoIsValid) {
        return res.status(401).json({ error: "Invalid Okendo signature" });
      }

      const event = JSON.parse(rawBody.toString("utf8"));

      // Only this route's intended event may create an email.
      if (event.eventType !== "review.created") {
        return res.status(204).end();
      }

      const review = event.data;
      const reviewId = review?.id;
      const recipient = review?.reviewer?.email?.trim().toLowerCase();

      if (!reviewId || !recipient) {
        // Return 2xx after recording an internal validation error so a bad,
        // permanently incomplete event does not create endless retries.
        await recordRejectedOkendoEvent({ event, reason: "Missing review ID or reviewer email" });
        return res.status(202).json({ accepted: true, sent: false });
      }

      // Your database should enforce a unique constraint on this value.
      // If it already exists, this is a retry or duplicate delivery.
      const firstTime = await claimEvent(`okendo:review-created:${reviewId}`);
      if (!firstTime) {
        return res.status(200).json({ accepted: true, duplicate: true });
      }

      const firstName = escapeHtml((review.reviewer?.name || "there").split(/\s+/)[0]);
      const productName = escapeHtml(review.product?.name || "your recent purchase");
      const rating = Number.isFinite(review.rating) ? review.rating : null;
      const subject = `Thank you for reviewing ${review.product?.name || "your purchase"}`;

      const html = `
        <p>Hi ${firstName},</p>
        <p>Thank you for sharing your feedback on <strong>${productName}</strong>${rating ? ` (${rating}/5)` : ""}.</p>
        <p>We appreciate you taking the time to help other shoppers make an informed choice.</p>
        <p>— The Example Store team</p>
      `;

      const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
        method: "POST",
        headers: {
          "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
          "Content-Type": "application/json",
          "Idempotency-Key": `okendo-review-created-${reviewId}`
        },
        body: JSON.stringify({
          from: "Example Store <reviews@example.com>",
          to: [recipient],
          subject,
          html,
          text: `Hi ${review.reviewer?.name || "there"},\n\nThank you for sharing your feedback on ${review.product?.name || "your recent purchase"}.\n\n— The Example Store team`
        })
      });

      const result = await volaneaResponse.json();
      if (!volaneaResponse.ok) {
        await markEventForRetry({ reviewId, status: volaneaResponse.status, result });
        return res.status(500).json({ error: "Volanea send failed" });
      }

      await markEventSent({ reviewId, volaneaResult: result });
      return res.status(202).json({ accepted: true });
    } catch (error) {
      console.error("Okendo webhook processing error", error);
      return res.status(500).json({ error: "Webhook processing failed" });
    }
  }
);

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

The example intentionally leaves verifyOkendoWebhook, claimEvent, and the event-log functions as application-specific functions. Those are not optional in production. Signature verification proves that an incoming request came from the configured Okendo webhook path rather than an arbitrary internet client. The database claim prevents your application from processing the same review-created event twice. The Volanea idempotency header adds another protection layer if the send request itself must be retried.

For complete endpoint details and current request fields, consult the email API reference and setup guides. The from address must use a sending domain that you have verified in Volanea.

Choose the right email behavior for each review

A review-created event should not always send the same message. The rating, review state, customer relationship, and brand policy should determine what happens next.

Positive review follow-up

For four- and five-star reviews, a short thank-you is usually enough. If you have a legitimate UGC program, you can conditionally follow up with customers who submitted a review without attached media. Keep that workflow separate from the basic confirmation so that the first email remains simple and predictable.

Useful conditions include:

• Rating is 4 or 5.
• The review has been accepted by your moderation policy, if your brand requires moderation before outreach.
• The reviewer has a valid email address.
• The review has no attached photo or video.
• The reviewer has not already received the specific UGC follow-up.

Negative review support escalation

For ratings of one or two, do not send an automated message that argues with the reviewer or asks them to revise their rating. A safer use is an internal notification to support, CX, or product teams. If you do email the customer, make it a service-recovery outreach with a clear reply path and a human owner.

Build the support email around the product, review ID, rating, and a link to the internal review-management context. Do not automatically expose unescaped review HTML to your team’s email client. Plain text or safely escaped excerpts are safer.

Three-star reviews

A three-star review is ambiguous. It may be a satisfied customer with a concrete improvement request or a customer who is unhappy but not seeking assistance. Treating every three-star review as either advocacy or escalation creates noise. Start by notifying a team inbox or segmenting the review data, then add customer-facing automation only after checking volume and tone.

Where the Volanea API key belongs

Your Volanea secret key belongs only in the trusted server-side environment that sends the API request. In the example, that is process.env.VOLANEA_API_KEY, populated through your platform’s secret manager or encrypted environment-variable configuration.

It does not belong in any of these locations:

• Okendo review-widget JavaScript delivered to a shopper’s browser.
• A public Shopify theme setting, metafield, or storefront script.
• A browser-side environment variable with a NEXT_PUBLIC_, VITE_, or similar client-exposed prefix.
• An email template, webhook destination URL query string, support ticket comment, or front-end analytics configuration.
• A Zapier or Make field that can be rendered into logs, notifications, or user-visible steps without access controls.

A Volanea sk_… key is a secret credential with API access. If it reaches client-visible code, anyone who retrieves the page source, browser bundle, network trace, or a copied configuration value can use it to attempt sends under your account. Rotating the key later limits damage, but it does not undo messages already sent or reputation harm already caused.

Okendo is the event source, not the secret store for Volanea credentials. The direct webhook approach means the key lives in your receiver’s deployment secrets. If you use middleware, store the key in the middleware platform’s encrypted connection or credential store, not inside a visible request payload.

Use a test key in development and a live secret key only after the sender domain, event mapping, and duplicate controls have been tested. Keep separate keys by environment and rotate immediately if a credential is exposed in a repository, ticket, screenshot, browser console, or automation history.

When this breaks: Okendo-to-Volanea failure modes

Every webhook integration eventually encounters a timeout, a replay, an incomplete payload, or a downstream API error. The right goal is not “never fail.” It is “fail without silently losing an event or sending the same customer multiple messages.”

Okendo retries create duplicate webhook deliveries

A webhook sender retries when it does not receive a successful response. The initial request may have reached your endpoint and even triggered a Volanea call, while the response back to Okendo was delayed or lost. When Okendo retries, a naïve handler sends the email again.

Prevent this at two layers. First, persist a unique event claim such as okendo:review-created:<review-id> before the send. The claim must be atomic: a database unique constraint or transactional insert is stronger than a process-local memory cache. Second, send the same stable logical key as Volanea’s Idempotency-Key, such as okendo-review-created-<review-id>. Never generate a new random idempotency key on every retry; that defeats the purpose.

For workflows where a review can be deleted and later recreated, include the actual event or review-created identity in your deduplication design. The desired business rule is one confirmation per intended review submission, not one confirmation per HTTP delivery attempt.

Your endpoint exceeds Okendo’s 15-second deadline

Okendo requires an HTTP 2xx response within 15 seconds. A slow database, cold start, template lookup, or transient Volanea request can make a synchronous endpoint miss that deadline. The likely result is a retry even if work eventually completes.

Acknowledge early and work asynchronously. A durable queue is the strongest pattern: validate the signature, insert the incoming event and its dedupe key, enqueue a job, then return 202. A worker reads the job and calls Volanea. If the Volanea call fails, retry the job with controlled backoff using the same idempotency key.

Do not return 200 before you have durably recorded the event. A 200 means you accepted responsibility for processing it. If your process crashes immediately afterward and there is no database write or queue message, the event is lost with no retry.

Required fields are missing or vary by product and plan

Some review-related data is inherently optional. A reviewer can submit no title, no media, or no location. A customer might have no usable email. Reward and incentive fields apply only when those features and circumstances exist. Product metadata can also differ based on configuration.

Write field-level guards rather than relying on every property. Reject or quarantine events without the minimum needed to send: normally a stable review ID and a valid recipient email. For fields used only for personalization, fall back gracefully. Use “your recent purchase” if a product name is unavailable, and “there” if the reviewer name is missing.

Do not treat missing optional data as a transient technical error. Retrying an event with no recipient email will not create an email address. Record the reason in an internal event log, return a 2xx after accepting the event, and alert only if the missing-field rate indicates a mapping or plan-access problem.

A Volanea request times out after acceptance

A network timeout is ambiguous: Volanea may not have received the request, may have accepted it, or may be processing it. Retrying without a stable idempotency key risks duplicate email. Retrying with the same idempotency key lets Volanea recognize the logical send attempt.

Keep the idempotency key tied to the business event, not the HTTP attempt. okendo-review-created-review_123 is useful. crypto.randomUUID() generated inside each retry is not.

The sending domain is not ready

A Volanea email call can be refused if the from identity is not permitted for the project or its domain has not been verified. This is a configuration failure, not a customer-data failure. Fix domain authentication and sender policy before repeatedly replaying production events.

Start testing with a Volanea test key and an address your team controls. Once the HTML, text fallback, from address, and mapping work, verify the production sender domain and switch the worker to the live key.

Middleware option: Zapier or Make when you cannot host a receiver

If you do not have a server endpoint, Okendo specifically identifies middleware such as Zapier as an option for receiving webhook events. This is the practical alternative for teams without application engineering capacity, but it still requires careful secret handling and duplicate control.

The middleware flow is:

1. Subscribe an Okendo Reviews created webhook to a Zapier Catch Hook or Make custom webhook URL.
2. Filter for the review-created event and require a valid reviewer email.
3. Build a stable deduplication value from the review ID.
4. Send a server-side webhook request from the middleware platform to Volanea’s POST /v1/send endpoint.
5. Store the Volanea secret key in the platform’s credential or connection configuration.
6. Monitor middleware task history and Volanea send logs during the first production days.

Middleware is a reasonable starting point for low-volume, operational workflows such as alerting a support inbox after a one-star review. It becomes less attractive for high-volume customer email because task retries, branching, payload transformations, rate limits, and auditability can become harder to reason about than a small dedicated receiver.

Do not put the Volanea key in the Okendo webhook URL or expose it in a front-end form. If the middleware product cannot send custom authorization headers from protected credentials, use a tiny relay endpoint instead.

Testing before you turn it on

Test the integration as a pipeline, not simply as two API calls that happen to return 200. The important outcomes are that the expected person gets one useful message, the right event is recorded, and retried delivery does not create another message.

Use this rollout checklist:

1. Create a Volanea test key and configure it only in your staging receiver or protected middleware credential.
2. Use a test recipient controlled by your team.
3. Subscribe only to the Okendo Reviews created event for staging.
4. Submit a real test review with a rating, title, body, and no media.
5. Confirm the receiver verifies the webhook and records the event before sending.
6. Confirm Volanea logs the message using the test key without delivering it.
7. Repeat delivery of the identical webhook payload and confirm the relay returns a duplicate outcome without another send.
8. Test missing reviewer name, missing product name, missing media, and missing recipient email scenarios.
9. Test a 1-star review path separately from a 5-star thank-you path.
10. Verify the production sending domain, change to a live key, and send one monitored production test.

Store correlation data in both directions. At minimum, retain the Okendo review ID, webhook event type, sequence number if present, recipient address, Volanea response data, final send status, and timestamps. This makes support investigations much easier: you can answer whether the review existed, whether the event was received, whether your dedupe logic skipped it, and whether Volanea accepted the message.

Deliverability and customer-experience considerations

A successful API response is not the same thing as a good customer email program. Review-triggered messages can improve engagement, but they can also feel excessive if they arrive immediately after every action with no clear value.

Keep a clear purpose for each email. A review thank-you should thank the customer. A service-recovery message should offer help. An internal moderation alert should go to employees, not the reviewer. Avoid turning a transactional acknowledgement into a promotional campaign unless the customer has the appropriate marketing consent and the message is designed for that channel.

Use a verified from domain that matches the brand customers recognize from their purchase and review experience. Include a plain-text email body as well as HTML. Keep subject lines specific, such as “Thank you for reviewing Everyday Jacket,” rather than vague subjects like “Important update.”

For customer-facing emails, rate-limit your own workflow. A shopper who submits multiple reviews in a short period might receive an overwhelming number of individual messages. Depending on your program, you may prefer a single daily digest, a per-order cap, or a rule that excludes customers who received a recent review acknowledgement.

Conclusion

To send email from Okendo with Volanea, use an Okendo Reviews created webhook as the trigger, process it in a protected server-side receiver, and send through Volanea’s POST /v1/send endpoint. There is no native Okendo marketplace app to install, and that is a feature of the architecture rather than a blocker: the relay gives you control over validation, customer logic, sender identity, retries, and security.

The essential production safeguards are simple but non-negotiable: verify the webhook before trusting it, respond within Okendo’s 15-second window, persist events before acknowledging them, guard missing optional fields, keep the Volanea secret key server-side, and use the review ID as a stable duplicate-prevention value in both your database and the Volanea Idempotency-Key header.

FAQ

Can I connect Okendo directly to Volanea without code?

Not as a direct native integration. Volanea does not provide a native Okendo app or marketplace plugin. Okendo can send webhook events, so use a server-side relay or middleware such as Zapier to transform the event into a Volanea API request.

What Okendo event should trigger the email?

Use the Okendo Reviews Created webhook event when a shopper submits a new review. It is the appropriate event for review thank-yous, internal alerts, and rating-based follow-up workflows.

Does Okendo webhook delivery guarantee order?

No. Okendo states that delivery order is not guaranteed. Webhooks include a sequenceNumber that can help order events for the same resource type, but every receiver should also deduplicate repeated deliveries.

Where should I store the Volanea API key?

Store the Volanea sk_… key in a server-side environment secret or encrypted middleware credential. Never put it in an Okendo storefront widget, Shopify theme code, browser-side environment variable, public webhook URL, or client-visible configuration.

How do I prevent duplicate review thank-you emails?

Create an atomic database record keyed by the Okendo review-created event or review ID, then call Volanea with a stable Idempotency-Key such as okendo-review-created-<review-id>. Reuse that exact key on retries.