Send email from Gorgias with Volanea by subscribing to a Gorgias ticket event, receiving that webhook in a server-side relay, and having the relay call Volanea’s email API. This approach keeps your Volanea API key out of Gorgias-visible configuration while giving you control over templates, recipients, retries, and duplicate prevention.

Volanea does not provide a native Gorgias app, Gorgias Marketplace listing, or one-click plugin. The practical integration is therefore a webhook-to-API workflow: Gorgias reports that something happened to a support ticket, your endpoint decides whether an email should be sent, and Volanea delivers the resulting transactional or operational message.

This guide uses the ticket-created webhook event as the concrete trigger. It is a useful starting point for notifications such as a new high-value support request, a new ticket from a VIP customer, or an internal escalation notice. The same relay pattern can later be extended to other Gorgias webhook events, but start with one narrowly defined event so that you can verify the behavior and avoid accidental mail loops.

What the Gorgias-to-Volanea integration does

Gorgias is the system that knows about a new support ticket. Volanea is the system that sends the email. The relay between them is important because a Gorgias webhook is a notification from Gorgias to your endpoint, not an email-send command with Volanea-specific authentication and templating built in.

The completed flow has five steps:

A new ticket is created in Gorgias.
Gorgias sends a ticket-created webhook request to an HTTPS endpoint you control.
Your relay checks the event, extracts the ticket ID, and optionally retrieves the current ticket from Gorgias’s API.
The relay applies business rules and maps ticket data into a Volanea email request.
The relay records that event as processed and sends the message through Volanea.

That separation is useful even for a simple internal notification. Your support operation will eventually need rules that Gorgias should not be expected to express in a raw webhook destination: skip spam tickets, route by tag, suppress non-actionable messages, change recipients by language, and attach a stable idempotency key to each send.

It also means the email is independent of the original helpdesk channel. For example, a customer can open a ticket through chat, Instagram, an order form, or email, while your relay sends the appropriate operations alert to an on-call address. The sender identity, recipient policy, and deliverability configuration remain owned by your email infrastructure rather than scattered across support automations.

The concrete Gorgias trigger: `ticket-created`

Gorgias webhooks publish events when supported resources change. For this integration, configure a webhook subscription for the ticket-created event and point it at an HTTPS URL served by your relay, such as https://support-email.example.com/webhooks/gorgias.

A ticket being created is the triggering record change. It is not the same thing as a ticket being assigned, closed, or receiving every subsequent message. That distinction matters: if your desired email is “a new support case needs review,” ticket-created produces one natural trigger per case. If you subscribe broadly to ticket updates, each tag, assignment, status, or message change can produce another event and make duplicate outbound email much more likely.

The webhook event is an envelope containing an event name and resource data. A representative ticket-created payload has this shape:

{
  "event": "ticket-created",
  "data": {
    "id": 842917,
    "uri": "/api/tickets/842917",
    "status": "open",
    "priority": "normal",
    "channel": "email",
    "subject": "Where is my order?",
    "customer": {
      "id": 123456,
      "email": "customer@example.net",
      "name": "Avery Chen"
    }
  }
}

Treat the webhook body as an event notification, not as a permanent contract for every field your template needs. The exact resource representation can vary as Gorgias adds fields, as channels differ, and as your account permissions or plan affect available data. In particular, do not assume that every ticket has a customer email, a meaningful subject, an order reference, tags, or a populated message body.

For a production send, use data.id as the ticket identifier and retrieve the ticket from Gorgias before rendering rich content. That gives the relay the current ticket data and prevents a sparse event body from becoming a broken email. It also lets you distinguish the customer-facing address from the internal operational address that should receive an alert.

Choose the recipient before writing code

A webhook relay can send two very different classes of mail:

Internal operational email, such as a new-ticket alert to support-leads@example.com, an escalation to an on-call engineer, or a fraud review notice.
Customer email, such as a post-support follow-up, a case-received notification, or an update generated by a separate workflow.

Start with internal operational email. Gorgias already has native support-conversation behavior, and sending a customer a second notification for every ticket can be confusing or can create a conversation loop. If you do send customer mail, make the trigger and consent basis explicit, exclude auto-replies, and decide whether the resulting email should appear in the Gorgias ticket history.

Why a server-side relay is the right connection

A webhook destination cannot safely be a browser application, a storefront theme, a client-side tag manager, or a public no-code configuration containing the Volanea bearer key. Anything reachable by a customer’s browser can expose credentials through page source, browser developer tools, request logs, extension access, or an accidental configuration export.

Put the integration in a server-side environment: a small Node service, a serverless function, a worker, or an automation platform with secret storage. The endpoint receives Gorgias’s HTTP request and makes the outbound Volanea API request from a trusted runtime.

This architecture also solves a practical data-mapping problem. Gorgias webhook bodies are Gorgias resource objects; Volanea’s send endpoint expects an email object. A relay can normalize missing values, escape dynamic text, select a verified sender, and use a fixed template rather than attempting to make one product’s object schema fit another product’s API directly.

Where the Volanea API key belongs

The Volanea API key does not belong in a Gorgias ticket macro, a ticket field, a tag, a browser-based script, or the webhook URL. In this relay design, there is no Volanea API key stored on the Gorgias side at all.

Store it as a secret environment variable in the system hosting the relay, for example VOLANEA_API_KEY. The relay reads it only when it makes the server-to-server request to Volanea. If you also fetch the full ticket from Gorgias, store the Gorgias API credentials there too, separately as GORGIAS_EMAIL, GORGIAS_API_KEY, and GORGIAS_DOMAIN.

Use least privilege operationally. Restrict access to deployment secrets, do not print authorization headers in application logs, rotate a key if it is exposed, and use separate credentials for development and production. A sending key is especially sensitive because an attacker can use it to impersonate your verified domain and damage deliverability.

For setup details and current request fields, keep the relay implementation aligned with the Volanea API reference and setup guides. API documentation should be the source of truth when you add attachments, reply-to addresses, tags, or provider-side message metadata.

Configure the Gorgias webhook carefully

Create the webhook from the Gorgias developer or API configuration area available to your account, select ticket-created, and enter the HTTPS endpoint for your relay. Before enabling the workflow for all traffic, point it at a staging endpoint and create a test ticket through the same channel your team normally uses.

Save an unmodified example request body from that test. Do not build solely from a generic sample because a chat-originated ticket, email-originated ticket, social ticket, and API-created ticket may expose different data. Your saved sample is the most useful input for testing the parser and template.

The endpoint should return a successful HTTP response promptly after it has accepted the event. Webhook producers generally interpret non-success responses or slow responses as a delivery failure and may retry. Sending the email synchronously before answering can work for a low-volume proof of concept, but a queue is safer at scale: acknowledge the webhook after validation and durable storage, then process the send asynchronously.

Define an explicit event policy

A ticket-created event alone is rarely enough to decide whether an email is worthwhile. Build a small policy around it. For example, only alert operations when the ticket is open and originated from a customer channel, and skip tickets created by internal API processes or known test contacts.

Useful policy checks include:

Ignore tickets whose customer email is in a test-domain allowlist or blocklist.
Skip tickets with a spam or automated tag once that tag is available in your workflow.
Send to a fixed internal group for normal tickets and a separate group for priority customers.
Use a fallback subject when Gorgias has no usable ticket subject.
Never use a raw customer-supplied value as an email recipient without validation and a clear product reason.

The policy should be deterministic. Given the same ticket and event, it should decide the same outcome every time. That makes retries safe and makes an incident easier to investigate later.

Working Node.js relay: Gorgias payload to Volanea email

The following Express example receives the Gorgias webhook, handles the ticket-created payload shape, fetches the ticket using Gorgias API credentials, and maps the result into a Volanea REST send request. It sends an internal alert, which avoids accidentally creating a second customer conversation.

import express from "express";

const app = express();
app.use(express.json({ limit: "1mb" }));

const {
  GORGIAS_DOMAIN,
  GORGIAS_EMAIL,
  GORGIAS_API_KEY,
  VOLANEA_API_KEY,
  ALERT_TO
} = process.env;

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

async function getGorgiasTicket(ticketId) {
  const basic = Buffer.from(
    `${GORGIAS_EMAIL}:${GORGIAS_API_KEY}`
  ).toString("base64");

  const response = await fetch(
    `https://${GORGIAS_DOMAIN}.gorgias.com/api/tickets/${ticketId}`,
    { headers: { Authorization: `Basic ${basic}` } }
  );

  if (!response.ok) {
    throw new Error(`Gorgias ticket fetch failed: ${response.status}`);
  }
  return response.json();
}

app.post("/webhooks/gorgias", async (req, res) => {
  const event = req.body;

  // The concrete Gorgias trigger for this integration.
  if (event?.event !== "ticket-created" || !event?.data?.id) {
    return res.status(204).end();
  }

  const ticketId = event.data.id;

  try {
    const ticket = await getGorgiasTicket(ticketId);
    const customer = ticket.customer || {};
    const ticketSubject = ticket.subject || "New support ticket";
    const customerName = customer.name || "Unknown customer";
    const customerEmail = customer.email || "No customer email available";

    const volaneaPayload = {
      from: "Support Alerts <alerts@your-verified-domain.example>",
      to: [ALERT_TO],
      subject: `New Gorgias ticket #${ticket.id}: ${ticketSubject}`,
      html: `
        <h1>New support ticket</h1>
        <p><strong>Ticket:</strong> #${escapeHtml(ticket.id)}</p>
        <p><strong>Subject:</strong> ${escapeHtml(ticketSubject)}</p>
        <p><strong>Status:</strong> ${escapeHtml(ticket.status || "unknown")}</p>
        <p><strong>Customer:</strong> ${escapeHtml(customerName)}</p>
        <p><strong>Customer email:</strong> ${escapeHtml(customerEmail)}</p>
        <p><a href="https://${escapeHtml(GORGIAS_DOMAIN)}.gorgias.com/app/ticket/${escapeHtml(ticket.id)}">Open ticket in Gorgias</a></p>
      `,
      text: [
        "New support ticket",
        `Ticket: #${ticket.id}`,
        `Subject: ${ticketSubject}`,
        `Status: ${ticket.status || "unknown"}`,
        `Customer: ${customerName}`,
        `Customer email: ${customerEmail}`
      ].join("\n")
    };

    const sendResponse = await fetch("https://api.volanea.com/v1/email/send", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${VOLANEA_API_KEY}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify(volaneaPayload)
    });

    if (!sendResponse.ok) {
      throw new Error(`Volanea send failed: ${sendResponse.status}`);
    }

    return res.status(200).json({ accepted: true, ticketId });
  } catch (error) {
    console.error("Gorgias-to-Volanea relay error", {
      ticketId,
      message: error.message
    });
    return res.status(500).json({ accepted: false });
  }
});

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

The important field mapping is visible in volaneaPayload: Gorgias ticket.id becomes the alert ticket number, ticket.subject becomes part of the email subject, ticket.status appears in the content, and ticket.customer.name and ticket.customer.email populate the operational context. ALERT_TO is deliberately a configuration value rather than a value taken from the webhook.

The from address must use a domain and sender identity you have configured for Volanea. Do not substitute a customer’s address into from; that is harmful for alignment and can trigger spoofing protections. If a human should be able to reply to the notification, add a controlled reply_to value supported by your Volanea send configuration, or direct staff back to the Gorgias ticket link.

Make the email useful without leaking support data

Support tickets often contain shipping details, account information, screenshots, order references, or messages that should not be copied into a broad internal distribution list. An alert should contain enough information to make a routing decision, not necessarily the complete ticket transcript.

The example includes the ticket ID, subject, status, customer identity, and deep link. That is usually enough for an on-call employee to open the properly permissioned ticket in Gorgias. If you add a message excerpt, cap its length and assess who receives the alert. HTML-escape every customer-derived value before inserting it into html; otherwise a customer’s text can alter the layout or insert a misleading link in the internal email.

Keep a text alternative as well as HTML. Plain-text content is useful for accessibility, mail clients that do not render HTML, and incident responders searching a mailbox. It also makes your alert legible if a template rendering issue occurs.

Use a verified sender and stable stream

Operational notifications should come from a clearly recognizable sender, such as alerts@your-verified-domain.example, rather than from an individual support agent. A stable sender improves filtering rules, ownership, and auditability.

If your Volanea configuration distinguishes transactional mail from campaign mail, send these alerts through the appropriate transactional path. They are event-driven, time-sensitive, and expected by internal recipients. Make the subject line specific enough to triage without opening the message, but avoid placing sensitive customer data in the subject because subjects are exposed in mailbox previews and notifications.

Prevent duplicates and mail loops

The sample code explains the mapping, but it is not yet production-grade idempotency. Gorgias can retry a webhook when your endpoint times out or returns an error. A timeout is particularly dangerous: Volanea may have accepted the email, but the relay may fail before responding to Gorgias. The next webhook delivery could then send the same alert again.

Persist a deduplication record before or alongside the send. For a ticket-created alert, a simple key such as gorgias:ticket-created:<ticket-id> is appropriate because the desired business action is one alert per created ticket. Store the key in Redis, a database table with a unique index, or a durable queue system. If insertion conflicts, return success without sending another message.

For stronger auditing, store these fields with the key:

Gorgias event name and ticket ID.
Time the webhook was received.
The selected recipient group and template version.
Volanea response identifier, if returned by the send endpoint.
Final state: queued, sent, skipped, or failed.

Avoid making the email itself create another Gorgias ticket that triggers the same integration. This is a common loop when the relay sends to a mailbox connected to Gorgias. Internal alerts should go to an address that is not ingested as a new Gorgias customer conversation, or your event policy should recognize and exclude those internally generated tickets.

When this breaks

This integration crosses two HTTP systems and a relay, so failures are usually understandable once you identify the hop. Build visibility around each boundary instead of treating “no email arrived” as one undifferentiated problem.

Gorgias retries create duplicate sends

A Gorgias retry can occur when your endpoint returns a non-2xx response or takes too long to answer. If your code sends the Volanea request and then crashes, the next delivery can repeat the action. Solve this with a durable idempotency key keyed to the business event, not with a short-lived in-memory variable.

Do not mark the event as permanently complete before you know how your queue handles failures. A common pattern is to create a unique job record in a transaction, let a worker send the email, then record the provider result. A retry that finds the job record should not create a second job.

Webhook timeouts hide successful sends

A synchronous handler has to call Gorgias’s API and then Volanea before it can answer. Any network delay increases the chance that Gorgias regards the delivery as failed. At low volume this may be acceptable for testing, but production systems should accept, persist, and queue the event quickly.

If you cannot introduce a queue immediately, set conservative HTTP timeouts, log request durations, and use the deduplication record. Never blindly retry a failed fetch to the Volanea send endpoint unless you know whether the request reached Volanea; that uncertainty is exactly why idempotency is necessary.

Payload fields are missing or differ by channel and account

Some Gorgias data is not universal. A ticket may have no customer email, some channels may not provide the same customer identity fields, and fields available to one account configuration or plan may not be present in another. Webhook payloads can also be leaner than the full ticket resource.

Code defensively: test for event.data.id, use fallback text for optional values, and retrieve the full ticket only after validating the event. If the ticket fetch returns an authorization error, check the server-side Gorgias API credentials and the account’s API access before changing your template. If a field is essential to routing, skip the send and alert an administrator rather than sending a misleading message.

Volanea rejects the request or delivery is delayed

An API rejection generally points to request authentication, an unverified sender, an invalid recipient format, or a malformed payload. Log the HTTP status and a safely redacted response body. Do not log bearer tokens or complete ticket content in a shared log system.

An accepted API request is not identical to a delivered message. For internal alerts, inspect the recipient mailbox, filtering rules, and Volanea message events or logs. For customer-facing sends, monitor bounces, complaints, and suppression behavior; repeatedly attempting an address that has bounced is not a reliable recovery strategy.

Test the workflow before enabling it broadly

Use a separate test recipient and a sender domain already configured in Volanea. Create tickets from at least two sources, such as email and chat, because the field population can differ. Then intentionally send a malformed webhook and temporarily return a 500 response to confirm your deduplication logic handles retry behavior without producing multiple alerts.

A compact test plan is:

Create one normal ticket and confirm exactly one email is sent.
Re-deliver the captured webhook body and confirm it is recorded as a duplicate rather than resent.
Create a ticket without a customer email and confirm the fallback content is safe.
Check that the Gorgias ticket link opens for the intended internal recipient.
Rotate a staging Volanea key and confirm the failed request is observable without exposing the key in logs.

Only then add routing rules, richer content, or customer-facing communication. This order matters because the basic integration’s reliability is more valuable than an elaborate template that occasionally sends twice.

Alternatives when you do not want to host code

A serverless relay is usually small enough to maintain, but a managed automation platform can be reasonable for low-volume workflows. Use a Gorgias trigger supported by the platform, perform any required filtering or data lookup in the automation, and store the Volanea credential only in that platform’s encrypted connection or secret facility.

There are trade-offs. Automation platforms may add latency, constrain payload transformations, make deduplication harder, and charge per task. They can also obscure retry behavior: a task retry and a webhook retry are separate sources of duplication. Before relying on one, verify that it can make a custom authenticated HTTP request to Volanea and that it provides a durable way to prevent repeated sends for the same ticket.

For teams already using a queue or integration service, the webhook relay should publish an internal event such as support.ticket.created instead of calling Volanea inline. That decouples Gorgias availability from email delivery and allows multiple downstream consumers, such as Slack escalation, CRM enrichment, and fraud review, to work from one ticket event.

Operational checklist for a durable integration

Before considering the integration finished, confirm the following:

The Gorgias subscription is limited to the event you actually need, initially ticket-created.
The webhook endpoint uses HTTPS and is not a browser-executed endpoint.
Volanea and Gorgias credentials are stored only as server-side secrets.
The sender domain and from address are configured for Volanea.
Customer-derived HTML is escaped and sensitive ticket details are minimized.
A durable idempotency key prevents retry-driven duplicate email.
Logs contain event IDs, ticket IDs, timing, and status, but not API keys or full sensitive bodies.
A mailbox connected back into Gorgias cannot create a notification loop.

Once this checklist is in place, the pattern is reusable. You can add an escalation path for tickets that meet a tag rule, send a digest from a scheduled job, or notify a regional support team based on a customer attribute. Keep each new use case as a separate event policy and template rather than turning every ticket change into an email.

Conclusion

The reliable way to send email from Gorgias with Volanea is not a marketplace installation; it is a controlled webhook integration. Use Gorgias’s ticket-created event to notify a server-side relay, retrieve and validate the ticket data, map only the fields your email needs, and send through Volanea with a secret bearer key held outside Gorgias.

The details that make this reliable are not cosmetic: a verified sender, safe content handling, explicit recipient rules, durable idempotency, and quick webhook acknowledgement. Build those in from the first test and you will have a support-event email workflow that can grow without exposing credentials or flooding recipients with retry duplicates.

FAQ

Can I install Volanea from the Gorgias Marketplace?

No. Volanea does not ship a native Gorgias Marketplace app or plugin. Connect Gorgias to a server-side webhook relay, then have that relay call Volanea’s REST API.

What Gorgias event should start the email?

Use ticket-created for a one-time new-ticket notification. It is a clear record-created trigger and is less likely to generate repeated sends than a broad ticket-update workflow.

Should the Volanea API key be entered in Gorgias?

No. Keep the Volanea API key in server-side secret storage in your relay, worker, or approved automation platform. Do not place it in browser code, webhook URLs, ticket content, or client-visible configuration.

How do I stop duplicate alerts when Gorgias retries a webhook?

Create a durable unique idempotency record such as gorgias:ticket-created:<ticket-id> before processing the send. If the same event is delivered again, acknowledge it without creating another email.

Can this workflow send email to the customer who opened the ticket?

It can, but use extra care. Validate that a customer email exists, avoid duplicate messages that Gorgias already sends through the support channel, and define a clear consent and suppression policy before using support events for customer-facing mail.

How to Send Email From Gorgias With Volanea