How to Send Email From Pure Chat With Volanea

Send email from Pure Chat reliably by using its Zapier integration as the trigger layer and Volanea as the transactional delivery layer. Pure Chat does not provide a native Volanea app or a general outbound-webhook setting for posting directly to an email API, so the safe production path is Pure Chat → Zapier → your server-side relay → Volanea.

That architecture may sound like an extra hop, but it solves the two problems that matter most: Pure Chat can supply a meaningful chat event, while your relay keeps the Volanea API key out of browser code and gives you a durable place to validate data, control retries, and prevent duplicate sends.

What this integration actually does

This integration sends a transactional follow-up after Pure Chat captures a visitor’s email address. A typical message might confirm that the visitor’s question was received, summarize the next support step, or provide a requested resource.

The concrete Pure Chat trigger is New Contact Email Collected in Zapier. Zapier describes it as triggering when a new email address is collected by Pure Chat. The Pure Chat app also exposes New Chat Request and Finished Chat triggers, but neither is as suitable for a follow-up email because a chat request may not contain a usable email address and a finished chat may include conversations where the visitor never supplied one.

The flow should be intentional:

1. A visitor gives Pure Chat an email address during a chat or through the chat widget’s configured contact collection.
2. Pure Chat raises a New Contact Email Collected event to Zapier.
3. Zapier sends a small, normalized JSON request to a relay endpoint you control.
4. The relay validates the request, derives a stable idempotency key, and calls Volanea’s POST /v1/send endpoint.
5. Volanea queues the transactional email and applies its sending pipeline, including suppression checks and tracking instrumentation where configured.

This is not a marketplace installation. There is no Pure Chat app to install inside Volanea, and there is no Volanea plugin to add from a Pure Chat marketplace. The connection begins by creating a Zap and authenticating the Pure Chat trigger with the Pure Chat API key generated for Zapier.

Why Zapier is the correct middleware route for Pure Chat

Pure Chat’s documented integration route for connecting to other applications is Zapier. Its Zapier integration documentation instructs you to select Pure Chat as the trigger app and connect it using an API key generated from the Pure Chat account’s Integrations area. Zapier lists the Pure Chat triggers as instant events, including New Contact Email Collected, Finished Chat, and New Chat Request.

That is materially different from a native outbound webhook feature. With an outbound webhook feature, you would configure a destination URL inside Pure Chat and Pure Chat would make an HTTP request directly to it. Pure Chat’s public support material instead points to Zapier for this sort of workflow. Do not invent a direct webhook URL field in the Pure Chat dashboard, and do not expose a Volanea credential through widget JavaScript in an attempt to bypass the middleware hop.

The relay also separates responsibilities cleanly:

• Pure Chat collects chat context and contact information.
• Zapier watches the selected Pure Chat event and transports a selected set of fields.
• Your relay enforces business rules, keeps secrets server-side, and provides observability.
• Volanea performs the API email send.

This separation is useful when the workflow evolves. For example, you may later decide that only chats tagged as sales inquiries receive a message, that messages should be routed by chat-box name, or that visitors should receive different copy based on which site started the chat. Those are policy decisions for your Zap or relay—not reasons to give a browser access to a sending credential.

Choose the right Pure Chat trigger

The recommended trigger for this use case is New Contact Email Collected. It is the most direct expression of the event that makes an email follow-up possible: Pure Chat has collected an email address.

New Contact Email Collected: best for acknowledgment emails

Use this trigger when you want to immediately acknowledge a visitor who supplied an address. It works well for messages such as:

• “Thanks—we received your request and will reply shortly.”
• “Here is the guide you asked us to send.”
• “Your demo request is in our queue.”
• “Here are the support hours and ways to continue the conversation.”

Because the workflow begins only after an address is collected, it avoids building an email send around a blank, anonymous, or malformed chat contact. Still validate the address in your relay: collection is not the same as consent for marketing, and it is not a guarantee that every value is syntactically valid.

Finished Chat: best when the email depends on the conversation outcome

Use Finished Chat if a human or an automation needs the completed conversation before deciding whether to send. For example, you might send a transcript follow-up, a case reference, or a troubleshooting article after the operator closes the conversation.

This trigger needs more defensive logic. A finished chat can exist without an email address, depending on how the widget was configured and what the visitor supplied. It can also create a less immediate experience if an operator leaves a chat open for a long time. Do not assume that a finished-chat event is interchangeable with an email-captured event.

New Chat Request: best for internal notifications, not visitor follow-up

New Chat Request runs when a website visitor initiates a request. It is useful for internal alerts—for example, sending a team inbox a notification that a high-value chat has started. It is not usually the correct trigger for emailing the visitor, because the visitor may not yet have provided an address.

For a visitor-facing follow-up, start with New Contact Email Collected. For an agent alert, New Chat Request can be appropriate, but address that email to an internal inbox rather than to a field collected from the visitor.

Configure the Pure Chat trigger in Zapier

Start in Zapier, create a new workflow, and choose Pure Chat as the trigger app. Select New Contact Email Collected as the trigger event, then connect your Pure Chat account.

Pure Chat’s setup guidance says the connection uses an API key generated from the Pure Chat account: open the Account area, choose Integrations in the left sidebar, select Zapier, and generate a key. That key authorizes Zapier to read the Pure Chat event data needed for the Zap. It is separate from the Volanea API key.

When configuring the trigger, select the relevant Chat Box Name if Zapier offers that filter for the connected account. Filtering at this step is useful if one Pure Chat account serves multiple sites or brands. A chat widget on support.example.com can have different confirmation copy, sender identity, or internal escalation rules than a chat widget on www.example.com.

Next, test the trigger with a real, disposable address. Open the site in a private browser session, start a chat, and submit an address through the widget. Testing with an actual new event matters because Pure Chat data varies with widget configuration: a widget that asks for name, email, phone number, and an initial question will yield more usable fields than a widget that only asks for email.

Do not publish the Zap yet. First inspect the available fields from the test record and decide which are safe and necessary to send downstream.

The payload: what Pure Chat sends and what your relay should receive

There is an important technical distinction here: Pure Chat does not send a native outbound HTTP payload to Volanea in this architecture. Pure Chat supplies the event to Zapier through its Zapier integration. Zapier then makes the outbound request to your relay.

That means there is no truthful, stable “Pure Chat webhook JSON schema” to paste into a direct Volanea request. Treat the fields visible in Zapier’s test event as the source of truth for your connected Pure Chat account. The exact available fields can differ depending on the event type, chat-box configuration, and information a visitor actually supplied.

For the New Contact Email Collected trigger, use the email field surfaced in the Zapier test record and map it into a deliberately small relay contract. Do not forward every available field merely because it appears in a test sample. Chat transcripts, visitor locations, referral URLs, and free-form message text can contain personal data and often are not needed for a simple acknowledgment.

A good normalized payload from Zapier to your relay looks like this:

{
  "event": "purechat.new_contact_email_collected",
  "email": "visitor@example.com",
  "chatBoxName": "Main website chat",
  "sourceEventId": "replace-with-the-stable-id-from-your-Zap-test-record-if-available"
}

The fields in this payload are your relay contract, not a claim that Pure Chat has a public native outbound-webhook schema. In the Zapier Webhooks action, map the actual Pure Chat email token from the trigger test data into email; map the displayed chat-box field into chatBoxName if you use it; and map a unique event or contact identifier into sourceEventId if the test record exposes one.

If the Pure Chat trigger result does not provide a stable record ID, do not manufacture one with the current timestamp. Instead, derive a conservative deterministic key in the relay from the address, event type, and an event-time field only if that time field is available. If there is no stable identifier or timestamp, use Zapier’s own run metadata only for observability, and accept that you need a short duplicate-suppression window in your relay.

Build the Zapier-to-relay request

Add an action step in Zapier and select Webhooks by Zapier. Zapier’s webhook documentation describes Custom Request as the appropriate choice when you need custom headers and raw JSON. Configure a POST request to an HTTPS endpoint you operate, for example:

https://email-relay.example.com/hooks/pure-chat-contact

Use JSON as the request format and map the Pure Chat trigger fields into the small normalized payload described above. Add a private shared-secret header that your relay verifies, such as:

X-Relay-Secret: <a-long-random-secret>

Do not use an unprotected public endpoint. A URL alone is not a trustworthy authentication mechanism, and a publicly exposed Zapier catch URL or relay URL can be abused if copied into client-side code, browser logs, issue trackers, or screenshots.

The request leaving Zapier should be small enough that you can reason about it. An acknowledgment workflow generally needs only the visitor email, an event label, a chat-box label, and an event ID. If you need to use free-form visitor content in email copy, sanitize it, encode it as plain text, and set a length limit before including it in a message body.

Make the Volanea REST API call in a secure relay

The following Node.js example shows the complete field mapping. Zapier posts the normalized Pure Chat event to your endpoint. The relay checks its shared secret, validates the email, builds both plain-text and HTML versions, and sends the message through Volanea.

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

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

const {
  RELAY_SECRET,
  VOLANEA_API_KEY,
  EMAIL_FROM = "Support <support@example.com>",
} = process.env;

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

app.post("/hooks/pure-chat-contact", async (req, res) => {
  // Zapier Webhooks action sends this header; never accept the endpoint anonymously.
  if (!RELAY_SECRET || req.get("x-relay-secret") !== RELAY_SECRET) {
    return res.status(401).json({ error: "unauthorized" });
  }

  const { event, email, chatBoxName = "", sourceEventId = "" } = req.body ?? {};

  if (event !== "purechat.new_contact_email_collected") {
    return res.status(400).json({ error: "unexpected_event" });
  }

  if (typeof email !== "string" || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    return res.status(422).json({ error: "valid_email_required" });
  }

  // Prefer a stable Pure Chat/Zapier event ID when your trigger output provides one.
  // The fallback is deterministic, not a newly generated UUID, so a repeated request
  // maps to the same logical email.
  const idempotencyMaterial = sourceEventId || `${event}:${email.toLowerCase()}:${chatBoxName}`;
  const idempotencyKey = `purechat-contact:${crypto
    .createHash("sha256")
    .update(idempotencyMaterial)
    .digest("hex")}`;

  const safeChatBoxName = escapeHtml(String(chatBoxName).slice(0, 120));

  const volaneaResponse = 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: EMAIL_FROM,
      to: [email],
      subject: "We received your chat request",
      text: "Thanks for contacting us. We received your message and will follow up soon.",
      html: `<p>Thanks for contacting us.</p><p>We received your message and will follow up soon.</p>${safeChatBoxName ? `<p><small>Chat source: ${safeChatBoxName}</small></p>` : ""}`,
    }),
  });

  const responseBody = await volaneaResponse.text();

  if (!volaneaResponse.ok) {
    console.error("Volanea send failed", {
      status: volaneaResponse.status,
      responseBody,
      idempotencyKey,
    });
    return res.status(502).json({ error: "email_provider_error" });
  }

  return res.status(202).json({ accepted: true, idempotencyKey });
});

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

The essential field mapping is explicit:

Volanea’s documented single-message endpoint is POST /v1/send. It accepts JSON message content, uses bearer authentication, and supports an Idempotency-Key header for safe retry handling. The from address must be one you are authorized to send from; set up and verify the sending domain before treating the workflow as production-ready. See the email API reference and setup guides for the current send schema, domain setup, and delivery-event options.

Where the API keys belong

The Volanea API key does not live on the Pure Chat side. Pure Chat is not making the direct Volanea call, and its browser-side JavaScript API runs in the visitor’s page context. Putting an email API key in widget configuration, page source, a frontend environment variable, or custom browser JavaScript would let any visitor extract and use the key.

There are three different credentials in this system:

1. Pure Chat’s Zapier API key connects Zapier to the Pure Chat account. Generate it in Pure Chat’s Integrations area for the Zapier connection.
2. The relay shared secret authenticates requests from the Zapier Webhooks action to your relay. Store it in Zapier’s server-side action configuration and in your relay’s secret store.
3. The Volanea API key belongs only in the relay’s server-side secret store, such as a platform environment variable or managed secret service.

This distinction limits blast radius. If someone gets access to the Pure Chat widget script, they should learn nothing that permits email sending. If a Zap configuration needs revision, the Volanea key remains absent from Pure Chat and absent from the visitor’s browser. If you need to rotate the sending key, update one server-side secret rather than editing deployed site code.

For a small prototype, you can put the Volanea bearer token directly in Zapier’s Webhooks action headers. That is still safer than client-side code because the request is made server-to-server. It is not the preferred production design, however: access to the Zap and its history may be broader than access to your production secrets, and it leaves less room for request validation, idempotency, audit logging, and content policy. Use a relay for customer-facing production sends.

Design the email as transactional, not promotional

A visitor who gives an address while asking for help has a clear expectation of a service-related response. That makes an acknowledgment, transcript follow-up, ticket update, or requested-document delivery a natural transactional use case.

It does not automatically make the visitor a marketing subscriber. Do not turn “we collected an email in chat” into permission for an unrelated newsletter, product announcement, or sales sequence. If you want to add a contact to marketing automation, collect explicit consent and keep that consent record separate from the transactional acknowledgment flow.

Good chat follow-up messages share a few traits:

• They identify why the recipient is receiving the email.
• They are short enough to scan after a chat session.
• They provide a useful next action or expected response time.
• They contain both HTML and plain-text content.
• They avoid quoting raw chat content unless there is a clear support need and a privacy review.

A minimal subject such as “We received your chat request” is often more reliable than a clever sales-oriented subject. The email should help the visitor continue a conversation they started, not surprise them with a campaign.

When this breaks

Every integration has failure modes. The important question is whether the workflow fails silently, sends the wrong content, or sends duplicate messages. This Pure Chat-to-Zapier-to-relay-to-Volanea path has specific places to inspect.

Retries can cause duplicate sends

Zapier, your hosting platform, or your own relay client can retry a request after a timeout or transient error. The first request may have reached Volanea even though the caller never received a response. If the retried request generates a fresh identifier, the visitor can receive two acknowledgments.

Use the same Idempotency-Key for retries of the same logical event. The example derives that key from a stable event ID when available. Do not generate a random UUID every time the relay receives a request; random keys defeat idempotency because every retry looks like a different send.

If the Pure Chat event output does not expose a stable ID, add an application-level deduplication record to your relay. Store a hash of the normalized event data with a short expiration window, record the Volanea response or message ID, and return the previous success response when the same event reappears.

A webhook timeout can leave the result ambiguous

A relay endpoint should acknowledge fast. It should validate the request, record the event durably if possible, and avoid slow operations before returning success. If it waits on downstream services too long, Zapier may regard the action as failed and retry even though Volanea accepted the message.

For higher-volume or business-critical workflows, queue the normalized payload before calling Volanea. Your HTTP endpoint can return 202 Accepted after the queue write, and a worker can make the Volanea API call. This reduces timeout ambiguity and gives you a durable retry path.

If you keep the synchronous version, log all of the following together: the incoming request identifier, source event ID, derived idempotency key, Volanea HTTP status, and Volanea response body. Those records are what let you answer “did we send it?” without guessing.

Some fields may be absent on individual chats

Pure Chat data is shaped by widget configuration and visitor behavior. A visitor may provide only an email address. They may decline to enter a name, never ask a question, or start a chat through a different widget than the one you used while testing.

Write the mapping as if every optional field can be missing. Never build a subject that becomes Hello undefined, never use a missing transcript as the only email body, and never use a blank chat-box name as a database key. The email address is the only required visitor field for the New Contact Email Collected use case.

Do not rely on fields that you have not seen in your own Zapier test record. Zapier’s event output is the practical contract for your account and selected trigger. Re-test after changing Pure Chat pre-chat fields, replacing a chat widget, or consolidating multiple sites into one Pure Chat account.

The address can be invalid, suppressed, or inappropriate to message

A collection event is not a deliverability guarantee. Visitors can mistype an address, use a disposable inbox, or enter an address that has previously bounced. Volanea can apply suppression logic during sending, but your application should still handle a non-success response without retrying blindly.

For workflows where an address is especially valuable—such as a sales handoff or account-recovery request—consider checking the address before initiating a costly downstream process. The free address verification tool can help during manual review and testing, while production systems should keep validation and consent decisions explicit in the relay.

A Pure Chat connection or selected chat box can change

If the Pure Chat Zapier key is revoked, regenerated, or connected to the wrong Pure Chat account, the trigger can stop delivering events. If the Zap filters by Chat Box Name and an administrator renames or replaces that widget, valid chats may no longer enter the workflow.

Maintain a simple acceptance test: once per release or configuration change, submit a test email through the live widget, confirm the Zap run, check the relay log, and verify the Volanea send result. This test catches integration drift before a real support request disappears.

Test the complete path before publishing

Do not test only the Volanea API call and assume the integration is done. The critical behavior lives in the mapping between systems.

Use this production-readiness checklist:

1. Verify your Volanea sending domain and use a matching sender address in EMAIL_FROM.
2. Create a Pure Chat test widget or use a controlled test page so production visitors do not trigger test messages.
3. Generate the Pure Chat Zapier key and connect it to the correct Zapier account.
4. Configure New Contact Email Collected for the right Chat Box Name, if applicable.
5. Submit a new test email through the chat experience—not by replaying a manually typed Zapier sample.
6. Inspect the Zapier trigger record and confirm the email field contains exactly what you expect.
7. Confirm the relay rejects requests without X-Relay-Secret.
8. Confirm the relay logs the derived idempotency key without logging the Volanea bearer token.
9. Verify the message arrives in a test inbox and that the plain-text fallback is readable.
10. Replay the exact same relay payload and verify it does not create a second logical send.

Testing the duplicate path is especially valuable. Integration problems rarely occur when every system is healthy; they occur when a connection is slow, a response is lost, an action is retried, or an operator edits a Zap during an incident.

Alternatives to this architecture

There are two reasonable alternatives, depending on your operating model.

Use Zapier’s direct webhook action for a lightweight workflow

For a low-risk internal alert or an early prototype, configure Webhooks by Zapier to call https://api.volanea.com/v1/send directly. Set the request method to POST, use JSON, provide the Authorization: Bearer header, set Content-Type: application/json, and add an Idempotency-Key header.

This removes the relay, but it also removes a policy enforcement point. It is workable when the email is simple and your Zapier access controls are strong. It is less suitable for workflows that need durable deduplication, content sanitization, consent checks, or controlled secret rotation.

Use a queue-backed relay for support-critical messages

For customer support, lead routing, or workflows where missing an email is expensive, keep the relay and add a queue. The relay authenticates and validates the event, writes it to durable storage, and returns quickly. A worker then sends through Volanea with controlled retry logic and a stable idempotency key.

This approach takes more engineering effort, but it gives you the best incident response path. You can replay failed jobs, inspect a clear event trail, change templates without editing a Zap, and separate transient delivery failures from upstream trigger failures.

Operational practices that keep the integration healthy

Treat this workflow as part of your support infrastructure, not as a one-time automation. Assign an owner for the Pure Chat configuration, the Zap, the relay, and the Volanea sending domain. The owner does not need to be the same person, but responsibility should be visible.

Monitor each boundary separately:

• Pure Chat: Are visitors still reaching the intended chat box and providing an email?
• Zapier: Are trigger events producing successful runs, filters, and webhook actions?
• Relay: Are requests authenticated, validated, queued, deduplicated, and answered quickly?
• Volanea: Are sends accepted, delivered, bounced, suppressed, or complained about?

Avoid putting full message bodies or API credentials into broad-access logs. Email addresses are personal data; chat transcripts may contain far more sensitive content. Log enough metadata to debug the request, then restrict access and set retention periods appropriate to your privacy policy.

Finally, make email copy configurable outside the Zap when possible. A template or server-side content function is easier to review, localize, test, and update than a large block of HTML embedded in an automation editor. Zapier should decide when the event happens. Your application should decide exactly what a customer receives.

Conclusion

To send email from Pure Chat with Volanea, use the real integration route Pure Chat offers: its Zapier triggers. Start with New Contact Email Collected, pass only the needed fields to a secured relay, and have the relay call Volanea’s POST /v1/send endpoint with server-side bearer authentication and a stable idempotency key.

That design avoids a nonexistent native plugin, keeps the Volanea key away from client-visible chat code, and provides a clear answer when something goes wrong. It also gives you room to grow from a simple acknowledgment into a reliable support follow-up system without rebuilding the integration from scratch.

FAQ

Does Pure Chat have a native Volanea integration?

No. Pure Chat does not provide a native Volanea app, marketplace listing, or direct Volanea connection flow. Use Pure Chat’s Zapier integration as the trigger layer and send through a secure relay or a configured Zapier webhook action.

What Pure Chat event should trigger the email?

Use New Contact Email Collected for a visitor acknowledgment because it runs when Pure Chat collects a new email address. Use Finished Chat only when the message depends on the completed conversation, and use New Chat Request primarily for internal alerts.

Can I put the Volanea API key in the Pure Chat JavaScript snippet?

No. The chat snippet runs in a visitor-accessible browser context. Any key placed there can be exposed and abused. Keep the Volanea key in a server-side relay secret store, or at minimum in a server-side Zapier webhook action—not in client code.

How do I stop duplicate emails if Zapier retries?

Create a deterministic Idempotency-Key from a stable source event ID and reuse it whenever the same event is retried. If the trigger does not expose a stable ID, persist a duplicate-detection record in your relay using normalized event data and a short retention window.

Why does my test event have fields that real chats do not?

Pure Chat event data depends on the selected trigger, your chat widget configuration, and what the visitor actually entered. Treat the Zapier test output for your account as the practical mapping reference, and code optional fields defensively.