How to Send Email From Tidio With Volanea

Send email from Tidio with Volanea by using Tidio Flows’ API call action to make a server-side HTTP request to Volanea’s REST API. There is no native Volanea app or Tidio Marketplace plugin to install, but Tidio can make outbound HTTP requests from a Flow, which makes a direct integration practical for confirmation emails, lead alerts, support summaries, and follow-ups.

This guide builds a real integration around a Tidio Flow. A visitor starts the Flow with Tidio’s Visitor Says trigger, submits a form, and then reaches an API call action. That action posts the collected fields to Volanea’s POST /v1/send endpoint. The key design requirement is simple: keep the Volanea secret key in Tidio’s server-side API-call authentication configuration—not in your website JavaScript, Widget SDK code, or any browser-visible configuration.

What this Tidio and Volanea integration does

Tidio is the conversation layer. It can collect details from a chat visitor, write those details to Contact Properties, branch a Flow based on their answers, and make an HTTP request when the visitor reaches an API call node. Volanea is the delivery layer: it accepts the normalized recipient, sender, subject, and message content, then queues the transactional message through its email-delivery pipeline.

A useful first use case is a “send me the details” chat journey:

1. A visitor types a phrase such as “email me the guide.”
2. A Tidio Flow begins with the Visitor Says trigger.
3. The Flow uses Send a form or Ask a question to collect the visitor’s name, email address, and request topic.
4. Tidio saves those answers as Contact Properties.
5. The visitor reaches an API call action.
6. Tidio sends an HTTP POST request to Volanea.
7. Volanea queues an email to the address the visitor supplied.

The direct route is appropriate when the email is a consequence of the chat interaction itself. Examples include a requested product sheet, a case summary, a booking confirmation, a support transcript summary, or a request for a sales follow-up.

It is not a substitute for consent management. If you want to send recurring newsletters or promotional campaigns, collect and store the correct marketing permission separately, use clear subscription language, and respect both unsubscribes and local legal requirements. A transactional email requested by a visitor in a chat is a different category from adding that person to promotional mail.

The real Tidio trigger: Visitor Says, form completion, then API call

The send starts in a Tidio Flow, not in a native integration listing. Tidio calls the entry point a trigger, and one of its Flow triggers is Visitor Says. That trigger is useful because it starts the Flow only when a visitor enters one of the phrases you configure.

For this example, create a Flow that begins when the visitor says a phrase such as:

• “email me the guide”
• “send a recap”
• “send product details”
• “contact sales”

After the trigger, add a Send a form action. Tidio’s Flow actions include both Send a form and API call, so you can collect structured visitor data before your outbound request runs. Configure the form to capture these values:

• Email address — required, saved as Tidio’s email Contact Property.
• First name — optional, saved as a Contact Property.
• Topic or product interest — required if the content depends on the request.
• Message or question — optional, useful for a sales or support handoff.

The concrete event that causes the email send is not “a contact record created” in the abstract. It is the visitor successfully progressing from the form step to the API call action in the same Flow. That distinction matters. A person can exist in Tidio without completing your request flow; do not automatically email every newly seen chat contact merely because they opened the widget.

Why use Contact Properties before the API call

Contact Properties give the Flow a stable place to store values collected in chat. Tidio supports default properties such as name and email, plus custom properties with types including text, email, number, phone, and URL. Store the form answers before calling Volanea so the Flow can reuse them in chat messages, conditions, CRM handoffs, and the outgoing HTTP body.

For this integration, create custom Contact Properties in Settings > Fields > Contact properties if you need information beyond name and email. For example:

Do not treat arbitrary chat text as trusted HTML. A visitor may type markup, URLs, special characters, or content you would not want rendered in an email. Your integration should escape untrusted values before placing them in HTML content, or use text-only content for visitor-provided text.

Choose the direct API-call architecture

Tidio’s Flow API call action supports HTTP methods including GET, POST, PATCH, PUT, and DELETE. For sending email, use POST, because Volanea’s send endpoint creates a new outbound email request.

The direct architecture is:

Visitor
  → Tidio Visitor Says trigger
  → Tidio Send a form action
  → Tidio API call action
  → POST https://api.volanea.com/v1/send
  → Volanea queues transactional email

This direct path has fewer moving parts than routing every request through Zapier or Make. It also avoids copying the Volanea key into a separate no-code account if you do not need transformations, approvals, database writes, or multi-step automation.

However, a direct path has an operational tradeoff: the email provider credential is configured in Tidio. That can be acceptable for a tightly controlled Tidio workspace, but a small middleware endpoint gives you stronger control over validation, auditing, response handling, rate limiting, and secret rotation. Later in this guide, there is a recommended middleware variation for production teams that need those safeguards.

When Zapier or Make is a better route

Tidio also offers a Send to Zapier Flow action. That route is useful if your Flow needs to enrich the data first, write a CRM record, wait for an approval, create a ticket, or combine Tidio data with an event from another application. Tidio’s Zapier action is one-way: Tidio sends collected data outward.

Use Zapier or Make when you need:

• A no-code approval or routing step before the email is sent.
• A CRM lookup to find an existing customer or account owner.
• A spreadsheet, database, or help-desk record created alongside the email.
• A middleware layer because you do not want the Volanea credential held in Tidio.
• More advanced retry and error-alerting controls than a Flow can provide.

For a normal request-confirmation email, though, the Flow API call is the cleanest path. It posts directly from Tidio to Volanea without pretending that an app installation or marketplace connector exists.

Configure the Tidio API call action

In the Tidio Flow editor, add an API call action immediately after the form or question actions that collect the data. Tidio’s API call configuration is where you choose the method, destination URL, headers or authentication, request body, and request test.

Configure it as follows:

Tidio documents API-key, none, bearer, and basic authentication options for Flow API calls. Choose Bearer for Volanea because Volanea’s REST API uses Authorization: Bearer <secret-key>.

Where the Volanea key belongs

Put the Volanea secret key in the Tidio API call node’s authentication configuration, inside the Flow editor’s HTTP-request configuration. Do not put it in any of these places:

• The Tidio Widget SDK snippet on your website.
• A JavaScript variable bundled into your frontend.
• A publicly readable environment variable prefixed for browser use.
• A Tidio contact field, session variable, form field, or chat message.
• The request body itself.

The Widget SDK runs in the visitor’s browser. Anything delivered there can be inspected in browser developer tools, copied from page source, captured from a network request, or extracted from a compiled JavaScript bundle. A Volanea secret key authorizes email sending; exposing it lets an attacker send mail through your account, burn sending capacity, harm domain reputation, and potentially trigger abuse complaints.

Tidio’s Flow API call is configured in the Tidio administration environment rather than supplied by the website visitor. Restrict who can edit Flows, review access when an employee leaves, and rotate the Volanea key promptly if a workspace credential may have been exposed. For a stricter boundary, store the Volanea key only in your server or serverless platform and have Tidio call that endpoint with a separate shared secret.

The payload Tidio sends and the Volanea field mapping

Tidio does not impose one universal webhook payload for Flow API calls. The request body is the JSON you configure in the API call action. That is an advantage: you choose a small, predictable payload rather than parsing a large generic event object.

In the request-body editor, use Tidio’s variable picker to insert the Contact Property values collected by the form. Do not manually guess the token syntax; insert each value from Tidio’s picker because the available fields depend on your Flow and stored properties.

The resolved request sent to Volanea should have this shape:

{
  "from": "Support Team <support@example.com>",
  "to": "jane@example.net",
  "subject": "Your requested product details",
  "html": "<p>Hi Jane,</p><p>Thanks for asking about Enterprise.</p><p>We will follow up shortly.</p>",
  "text": "Hi Jane,\n\nThanks for asking about Enterprise.\n\nWe will follow up shortly."
}

Map the values as follows:

A direct request body can work well when the subject and content are mostly fixed. For example, branch the Flow by requested_topic, then use one API call node for “pricing,” another for “demo,” and another for “support recap.” Each node can have a clear static subject and body while dynamically setting the recipient and greeting.

Direct Volanea request in the Tidio API call action

The following is the HTTP request your configured Tidio API call should produce after Tidio resolves the form and Contact Property values. It is shown as curl so you can test the Volanea side independently before adding it to the Flow.

curl --request POST "https://api.volanea.com/v1/send" \
  --header "Authorization: Bearer $VOLANEA_SECRET_KEY" \
  --header "Content-Type: application/json" \
  --header "Accept: application/json" \
  --data '{
    "from": "Support Team <support@example.com>",
    "to": "jane@example.net",
    "subject": "Your requested product details",
    "html": "<p>Hi Jane,</p><p>Thanks for asking about Enterprise.</p><p>We will follow up shortly.</p>",
    "text": "Hi Jane,\n\nThanks for asking about Enterprise.\n\nWe will follow up shortly."
  }'

Replace support@example.com with a sender address on a domain you have verified in Volanea. Do not use an arbitrary From address just because it looks right in a test. A sender domain that has not been authenticated can cause the request to be refused or delivery to perform poorly.

For more send parameters, authentication details, templates, domain setup, and response handling, use the Volanea email API reference and setup guides.

A safer production pattern: Tidio to middleware to Volanea

Direct sending is convenient, but a middleware endpoint is the more durable architecture when chat-triggered email matters to revenue, support, or compliance. The middleware receives a deliberately limited payload from Tidio, validates it, generates a stable deduplication key, safely builds the email, and calls Volanea with the secret stored in its server environment.

The flow becomes:

Tidio Flow API call
  → POST https://your-domain.example/tidio/email-request
  → validate and normalize payload
  → send POST https://api.volanea.com/v1/send
  → return a short JSON response to Tidio

In Tidio, configure the API call URL as your endpoint instead of the Volanea endpoint. Store a separate shared token in Tidio’s Bearer authentication field. Your server verifies that token before it uses its own VOLANEA_SECRET_KEY environment variable.

This makes the Tidio credential revocable without directly exposing the provider credential to every person who can edit the Flow. It also gives you an audit trail: you can log the Tidio contact identifier, request type, request timestamp, result, and Volanea message ID without logging the customer’s full message content or API secret.

Working Node.js middleware with field mapping

This example uses Express. The Tidio Flow posts a small JSON body containing the fields your Flow collected. The endpoint validates required fields, converts visitor content to safe HTML, builds a plain-text alternative, and calls Volanea.

import express from "express";
import crypto from "node:crypto";

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

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

app.post("/tidio/email-request", async (req, res) => {
  const authorization = req.get("authorization") || "";
  const expected = `Bearer ${process.env.TIDIO_RELAY_TOKEN}`;

  if (!crypto.timingSafeEqual(
    Buffer.from(authorization.padEnd(expected.length)),
    Buffer.from(expected)
  )) {
    return res.status(401).json({ error: "Unauthorized" });
  }

  // Tidio Flow request body after Contact Property values are resolved.
  const {
    contactId,
    email,
    firstName = "there",
    requestedTopic = "your request",
    visitorQuestion = ""
  } = req.body;

  if (!contactId || !email) {
    return res.status(422).json({
      error: "contactId and email are required"
    });
  }

  const safeName = escapeHtml(firstName);
  const safeTopic = escapeHtml(requestedTopic);
  const safeQuestion = escapeHtml(visitorQuestion);

  const payload = {
    from: "Support Team <support@example.com>",
    to: email,
    subject: `Your Tidio request: ${requestedTopic}`,
    html: `
      <p>Hi ${safeName},</p>
      <p>Thanks for contacting us about <strong>${safeTopic}</strong>.</p>
      ${safeQuestion ? `<p>Your question:</p><blockquote>${safeQuestion}</blockquote>` : ""}
      <p>We have received your request and will follow up shortly.</p>
    `,
    text: [
      `Hi ${firstName},`,
      "",
      `Thanks for contacting us about ${requestedTopic}.`,
      visitorQuestion ? `Your question: ${visitorQuestion}` : "",
      "We have received your request and will follow up shortly."
    ].filter(Boolean).join("\n")
  };

  // One stable key for one logical chat-email request.
  const idempotencyKey = `tidio-request/${contactId}/${requestedTopic}`;

  const response = await fetch("https://api.volanea.com/v1/send", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.VOLANEA_SECRET_KEY}`,
      "Content-Type": "application/json",
      Accept: "application/json",
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify(payload)
  });

  const result = await response.json().catch(() => ({}));

  if (!response.ok) {
    console.error("Volanea send failed", {
      status: response.status,
      contactId,
      result
    });
    return res.status(502).json({
      error: "Email provider rejected the request"
    });
  }

  return res.status(200).json({
    ok: true,
    result
  });
});

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

The matching Tidio-to-middleware body should resolve to this shape:

{
  "contactId": "tidio-contact-id-from-your-flow",
  "email": "jane@example.net",
  "firstName": "Jane",
  "requestedTopic": "Enterprise",
  "visitorQuestion": "Can someone send the implementation guide?"
}

Use the variable picker in Tidio’s API call editor to populate each value from the current contact and the Contact Properties your form saved. The field names in this JSON are your own middleware contract, so they remain stable even if you rename a label shown to agents in Tidio.

Prevent duplicate emails before they reach an inbox

Chat automation creates an at-least-once delivery problem. A visitor can refresh, revisit a Flow, submit a form twice, or reach the same API call after a transient error. Separately, an upstream system may retry an HTTP request when it did not receive a response quickly enough. If every attempt becomes a new email request, one visitor may receive several copies.

Volanea supports the Idempotency-Key header on POST /v1/send. Send the same key with the same logical message when retrying. That lets Volanea recognize that a retry is not a new requested email.

Do not generate a fresh random idempotency key for every retry. That defeats duplicate protection: Volanea sees each retry as a different intended send. Instead, derive the key from stable business data, such as:

tidio-request/{contactId}/{flow-purpose}/{request-id}

A good key distinguishes genuinely different requests. If the same customer requests a pricing guide today and a support summary tomorrow, those are separate emails and should use different keys. If the same form submission is retried because the sender timed out, use the original key again.

Add a Tidio-side guard too

Idempotency protects the email send, but it is still useful to stop unnecessary Flow re-entry. After a successful API call, use Tidio’s Update Contact Property action to set a value such as last_email_request_type or guide_email_sent.

Then add a condition before the API call:

• If guide_email_sent is not set, continue to the API call.
• If it is already set, show a chat message such as “We have already sent that guide—please check your inbox and spam folder.”

This is a user-experience guard, not your only safety mechanism. Contact Property conditions can race if two browser sessions submit at nearly the same time. The stable Volanea idempotency key remains the stronger final protection.

When this breaks: Tidio-to-Volanea failure modes

Every integration breaks at the boundary between systems eventually. Build this Flow expecting missing data, timeouts, retries, permissions changes, and sender-domain configuration mistakes.

Tidio retries or the visitor reaches the API call twice

A repeated Flow execution can create duplicate sends if you post directly to Volanea without an idempotency key. This is particularly easy to miss during testing: one request can complete, but a slow or interrupted response can make the caller unsure whether it completed.

What to do: use a middleware endpoint and send Idempotency-Key with a stable event-specific value. If you use direct Tidio-to-Volanea sending and cannot configure a stable idempotency header, use a Tidio Contact Property guard, but recognize that it is less robust than server-side deduplication.

The webhook or API call times out

An API call can fail from Tidio’s point of view even if the downstream system eventually processes it. A slow middleware route may also cause Tidio’s Flow to stop or continue without a useful response.

What to do: return quickly. Your middleware should validate, enqueue or send, and respond with a compact JSON result. Avoid doing slow CRM lookups, report generation, or several serial third-party calls before returning. If a request needs heavy work, persist it to a queue and return an acknowledgement after validation.

Do not blindly retry with a new key after a timeout. Retry with the same request body and the same idempotency key. That makes an uncertain outcome safe to repeat.

Email or other Contact Properties are missing

A Flow may reach an API call with an empty recipient if the visitor skips a field, an older contact lacks the property, a branch bypasses the form, or a test starts in the middle of the Flow. Tidio Contact Properties also depend on the property definitions and Flow configuration in the current project.

What to do: make the email field required in the form, add a condition that checks the email value before the API call, and validate again in middleware. A missing recipient should produce a controlled chat response or an internal alert—not an attempt to send to an empty string.

Do not assume a field available in one Tidio plan, workspace, or Flow is available everywhere. Tidio’s OpenAPI and webhooks are associated with Plus arrangements, while the Flow API call functionality has its own product and plan considerations. Confirm the features enabled in the specific Tidio project before designing a production dependency around them.

The Volanea key is rejected

An invalid, revoked, expired, or incorrectly pasted key causes authorization failure. So does sending a key with the wrong authentication scheme.

What to do: configure Bearer authentication, not a custom key header guessed from another provider’s documentation. Confirm the request has Authorization: Bearer <Volanea secret key>, then rotate the key if there is any chance it entered browser-visible code, screenshots, public repositories, chat transcripts, or logs.

The From address or domain is not ready

The send request can be accepted only when the sender configuration meets Volanea’s requirements. A From address on an unverified or unauthenticated domain is not a harmless detail; it is a deliverability and authorization dependency.

What to do: verify the sending domain before enabling the Flow. Use an operational address such as support@yourdomain.com or hello@yourdomain.com, not an employee’s personal address. Test a real message to a mailbox you control, including a domain outside your own organization.

The HTTP body contains invalid JSON or unsafe HTML

Because the Tidio API call body is configured by you, malformed quotes or unescaped dynamic content can break JSON. Visitor text inserted into an HTML body can also alter the message if it is not escaped.

What to do: keep the direct-request body simple. For more than a name and a category, use middleware that validates JSON and escapes user-entered values. Always send a text version too, so recipients who use plain-text clients receive a readable message.

Test the full path before publishing the Flow

A successful test in Tidio only proves that Tidio could attempt the request. It does not prove the email entered an inbox, rendered correctly, or had the correct recipient and sender.

Use this production-readiness checklist:

1. Verify the sender domain in Volanea. Confirm the From address belongs to that verified domain.
2. Create a test Flow. Use a distinct Visitor Says phrase, such as “email test details.”
3. Submit the form as a visitor. Use a real mailbox you can inspect.
4. Inspect the Tidio API call test and Flow behavior. Confirm the request runs only after the form is complete.
5. Confirm the Volanea send result. A request acceptance is not the same as inbox placement, so check the message status and event data.
6. Review the received email. Check the subject, greeting fallback, text rendering, links, and From address.
7. Run the same request twice. Confirm the duplicate-protection logic behaves as intended.
8. Test failure paths. Remove an email value in a test branch, use a bad topic, or temporarily point to a non-production endpoint and make sure the Flow fails safely.

Do not test with a large live audience first. Chat flows often have broad triggers, and a simple condition mistake can produce many sends quickly. Start with an internal trigger phrase and a test-only sender while you validate the mapping.

Deliverability and message design for chat-triggered email

The person receiving this message has usually just interacted with you in chat. That context should be evident in the email. A generic “Hello” with no explanation can look unexpected, especially if the visitor used a work email address or asked for material after a long chat.

Use a subject that describes the exact action:

• “Your requested implementation guide”
• “Recap of your support request”
• “Details for the plan you asked about”
• “Next steps from your chat with Support Team”

The first sentence should establish why the recipient received it: “You asked us in chat to send details about Enterprise.” That makes the message recognizable in an inbox and reduces accidental spam reports.

Keep chat-derived transactional mail focused. Do not attach a promotional newsletter to a request-confirmation message merely because you have the email address. If you need promotional permission, ask for it separately with an explicit choice and record the result. Also ensure that the message type aligns with your suppression and unsubscribe policies.

For clean addresses collected in a chat, you can optionally direct visitors to an address-checking step before making a commitment based on the email. Volanea provides a free email address verification tool for checking whether an address is usable before a workflow depends on it.

Direct API call versus middleware versus Zapier

There is no single best route for every Tidio project. The right choice depends on how much control you need around credentials, data validation, transformations, and failure recovery.

A practical progression is to start with a direct API call for a low-risk internal notification, then move external customer messages to middleware once you need traceability or high confidence around duplicates. You do not need to redesign the Tidio Flow: only change its API call URL from Volanea’s endpoint to your own relay.

Conclusion

To send email from Tidio with Volanea, build around what Tidio actually provides: a Flow with a Visitor Says trigger, a form or question action that saves Contact Properties, and an API call action that sends an outbound HTTP POST. There is no native Volanea Tidio app required—and no marketplace-installation flow to invent.

For straightforward notifications, configure the API call to post directly to https://api.volanea.com/v1/send with Bearer authentication stored in the Flow’s server-side configuration. For customer-facing production sends, put a small middleware endpoint between Tidio and Volanea. It keeps the Volanea key out of Tidio, validates missing fields, escapes visitor text, records outcomes, and uses Idempotency-Key to prevent duplicates when the network becomes uncertain.

The quality of the integration comes down to disciplined field mapping: collect an email explicitly, validate it twice, use a verified sending domain, make the email clearly related to the chat request, and treat retries as a normal part of distributed systems rather than an edge case.

FAQ

Does Volanea have a native Tidio integration?

No. Volanea does not ship a native Tidio Marketplace app or plugin. The integration uses Tidio Flows’ API call action to make an HTTP request to Volanea’s REST API, optionally through your own middleware.

What Tidio event triggers the email?

In this setup, a Visitor Says trigger starts the Flow. The email request occurs when the visitor completes the form or question path and reaches the Flow’s API call action.

Can I put the Volanea API key in the Tidio widget code?

No. Widget code runs in the visitor’s browser and is client-visible. Put the key in Tidio’s API call Bearer-authentication configuration or, preferably, store it only in a server-side middleware environment variable.

How do I stop duplicate emails from Tidio retries?

Use Volanea’s Idempotency-Key header with a stable key that identifies one logical send. Reuse that same key and request body if the send must be retried after a timeout or uncertain response.

Should I use a Tidio Flow API call or Zapier?

Use the direct API call for a simple chat-to-email action. Use Zapier, Make, or middleware when you need multi-app routing, CRM lookups, data transformations, approvals, stronger logs, or stricter credential isolation.