SimpleTix can trigger useful attendee communications, but the safest way to send email from SimpleTix through Volanea is not to expose an email API key in a browser or ticket page. This guide uses the SimpleTix Zapier integration, a small server-side endpoint, and Volanea’s REST email API to turn a new attendee into a reliable transactional send.

SimpleTix does not provide a native Volanea app, marketplace listing, or one-click plugin. That matters because an integration should describe the route that actually exists: SimpleTix supplies the event data through Zapier, Zapier delivers a deliberately shaped HTTPS request to infrastructure you control, and that infrastructure calls Volanea with a secret API key.

The result is flexible enough for confirmation follow-ups, venue directions, schedule changes, access instructions, post-event surveys, and internal attendee alerts. It also gives you a proper place to validate data, suppress duplicate sends, and observe failures before an attendee misses an important message.

What the SimpleTix-to-Volanea flow looks like

The concrete SimpleTix event in this setup is the New Attendee trigger available through the SimpleTix app on Zapier. A ticket order can contain more than one attendee, so use an attendee-level trigger when the email should be personalized for every ticket holder rather than sent only once to the person who placed an order.

The sequence has four hops:

A person becomes a new attendee in SimpleTix after registration or ticket issuance.
Zapier receives the New Attendee trigger data from SimpleTix.
A Zapier Webhooks action posts selected attendee fields to a private endpoint on your server.
The endpoint validates the request, creates an idempotency record, and makes a server-to-server request to Volanea’s email API.

This division is intentional. Zapier is the connection layer; it is not the permanent home for long-lived mail credentials or the best place to implement database-backed deduplication. Your endpoint is the policy and security layer. Volanea is the delivery layer.

For a low-volume event, this may feel more elaborate than adding an email action to an automation. In practice, the extra hop solves the problems that become expensive later: a ticketing workflow runs again, an email field is blank, an attendee is transferred, or someone needs to determine exactly why a message was sent.

Why use Zapier rather than a direct SimpleTix webhook

SimpleTix’s public Zapier integration is the outbound automation route used here. It lets a Zap begin from SimpleTix data and continue to a Webhooks by Zapier action. This is different from claiming that SimpleTix has a native Volanea connector: it does not.

A Zapier webhook action can send an HTTP POST to an endpoint you own. That makes it a good handoff mechanism, but it should not call Volanea directly with a production API key. Values configured in third-party automation steps may be visible to Zap editors, copied into test data, or inadvertently included in screenshots and exported configurations. A restricted integration secret for your own endpoint is less damaging if exposed, and the Volanea key can remain solely in your server’s secret store.

Choose the right trigger grain

Use New Attendee when each ticket holder needs their own message. Examples include a QR-code delivery follow-up, an accessibility note, a workshop-specific instruction, or a “what to bring” email containing the ticket type.

Use an order-level process only when one message per purchase is genuinely correct, such as an internal sales notification. Sending an attendee-facing message from an order-level trigger can create a subtle error: one buyer may purchase tickets for several people, while only the buyer’s email is present or appropriate for the message.

Before enabling the Zap, create a test registration in a non-production event and inspect the sample fields Zapier receives. SimpleTix event configurations vary. Custom registration questions, ticket names, email collection rules, and whether the purchaser is also an attendee all affect what is available in the trigger data.

Do not treat a Zap sample as a schema contract

Zapier displays a sample record for field mapping, but a sample is not a guarantee that every historical or future attendee has every field. An event with required email collection produces a different practical result from an event where an email address was optional, imported, or collected only from the purchaser.

Build the outbound request from the stable fields you have verified in your own Zap. In particular, test a complimentary ticket, a multi-ticket order, a transferred ticket if your process permits it, and a registration with no optional custom answers. Those cases reveal missing values before a live campaign or event-day workflow depends on them.

Set up the Zapier handoff

Create a Zap with SimpleTix as the trigger app and select New Attendee. Connect the SimpleTix account requested by Zapier, select the relevant event when the trigger configuration offers an event choice, and test it using a real test attendee.

For the action, select Webhooks by Zapier and choose a POST-style request. Configure it to call a URL such as https://hooks.example.com/simpletix/attendee. This is an endpoint you operate, not a public frontend route and not a URL embedded in an attendee-facing page.

Use a request body you control rather than forwarding an opaque, unfiltered object. That gives the endpoint a small, documented contract and prevents accidental transmission of extra registration data. Map each value in Zapier using the field picker from the New Attendee test record.

A practical request body is:

{
  "source": "simpletix",
  "event_name": "{{SimpleTix New Attendee: Event Name}}",
  "attendee_id": "{{SimpleTix New Attendee: Attendee ID}}",
  "order_id": "{{SimpleTix New Attendee: Order ID}}",
  "email": "{{SimpleTix New Attendee: Email}}",
  "first_name": "{{SimpleTix New Attendee: First Name}}",
  "last_name": "{{SimpleTix New Attendee: Last Name}}",
  "ticket_type": "{{SimpleTix New Attendee: Ticket Type}}"
}

The strings inside {{...}} above describe the fields to select in Zapier; choose the actual field labels displayed by your SimpleTix test sample. Do not type those braces literally if Zapier has already inserted a mapped field token. If your trigger exposes different labels or does not expose one of these values, change the JSON key or omit it. The contract is the JSON keys sent to your endpoint, while the right-hand values are mappings from your particular SimpleTix trigger sample.

Add one header to the Webhooks action:

X-Integration-Secret: <a long random secret>
Content-Type: application/json

Store the same random secret as SIMPLETIX_ZAPIER_SECRET in the server environment. It is not a substitute for Volanea authentication. It only lets your endpoint reject random internet traffic before it processes a request.

The payload contract and field mapping

The JSON body above is the exact payload shape delivered from the SimpleTix-triggered Zap to your endpoint. It is intentionally smaller than a ticketing record. Only send fields the email needs and fields needed for idempotency or troubleshooting.

Here is what each field does:

source identifies the integration at the receiving endpoint. It is useful when one endpoint handles several automations.
event_name becomes an email-safe display value after escaping. Do not assume it is safe HTML just because it originated in an event system.
attendee_id is the preferred stable identifier for one-attendee-one-send deduplication.
order_id helps support staff trace the message to a purchase, but is not by itself a safe attendee-level deduplication key.
email is the recipient address and must be validated before Volanea is called.
first_name and last_name support personalization, but should be optional in code.
ticket_type can tailor content or provide a useful support reference.

Avoid putting a raw access credential, QR code, full payment value, or answers to sensitive registration questions into an email merely because they appear in an automation sample. Email is a copyable transport, and a recipient mailbox may be shared. Use a signed, expiring link to a ticket-management page where appropriate.

An important privacy boundary

The message recipient should normally be the attendee email mapped from the New Attendee trigger. Do not silently fall back to a purchaser email unless the meaning of the message is still correct and your registration terms support that use. A purchaser could be an administrator, a parent, or a colleague rather than the attendee.

Also decide whether this is transactional or promotional before sending. Event logistics, a requested receipt, and a material schedule change are generally operational messages. A future-event offer is marketing and should follow your consent, unsubscribe, and regional compliance process. Changing the sending API does not change that responsibility.

Build a secure Volanea middleware endpoint

The following Node.js example uses Express and the platform fetch implementation. It receives the controlled Zapier payload, validates it, deduplicates by attendee and message type, and then calls Volanea. It keeps the Volanea credential in VOLANEA_API_KEY, which is available only to the server process.

Consult the Volanea API setup guides when creating the sending domain, API credentials, and production sender identity. The example assumes EVENT_FROM_EMAIL is a verified sender on a domain you control.

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

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

const {
  SIMPLETIX_ZAPIER_SECRET,
  VOLANEA_API_KEY,
  EVENT_FROM_EMAIL,
  VOLANEA_API_URL = "https://api.volanea.com/v1/emails"
} = process.env;

// Replace this Map with a database table or durable KV store in production.
// The key should have a unique constraint so concurrent retries cannot both send.
const sent = new Map();

function safeText(value, fallback = "") {
  return String(value ?? fallback)
    .replace(/[&<>'"]/g, (character) => ({
      "&": "&amp;", "<": "&lt;", ">": "&gt;",
      "'": "&#39;", '"': "&quot;"
    }[character]));
}

function isEmail(value) {
  return typeof value === "string" && /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
}

app.post("/simpletix/attendee", async (req, res) => {
  const suppliedSecret = req.get("X-Integration-Secret") || "";
  const expectedSecret = SIMPLETIX_ZAPIER_SECRET || "";

  if (!expectedSecret || suppliedSecret.length !== expectedSecret.length ||
      !crypto.timingSafeEqual(Buffer.from(suppliedSecret), Buffer.from(expectedSecret))) {
    return res.status(401).json({ error: "unauthorized" });
  }

  const { source, event_name, attendee_id, order_id, email, first_name, ticket_type } = req.body;
  if (source !== "simpletix") return res.status(400).json({ error: "invalid source" });
  if (!attendee_id || !order_id || !isEmail(email)) {
    return res.status(422).json({ error: "attendee_id, order_id, and valid email are required" });
  }

  const messageType = "attendee-instructions-v1";
  const idempotencyKey = `simpletix:${attendee_id}:${messageType}`;
  if (sent.has(idempotencyKey)) {
    return res.status(200).json({ status: "already_sent" });
  }

  const name = safeText(first_name, "there");
  const event = safeText(event_name, "your event");
  const ticket = safeText(ticket_type, "your ticket");

  const volaneaPayload = {
    from: EVENT_FROM_EMAIL,
    to: [email],
    subject: `Details for ${event}`,
    html: `<p>Hi ${name},</p><p>Thanks for registering for <strong>${event}</strong>.</p><p>Your ticket type: ${ticket}.</p><p>Please keep this email for your records.</p>`,
    text: `Hi ${first_name || "there"},\n\nThanks for registering for ${event_name || "your event"}.\nYour ticket type: ${ticket_type || "your ticket"}.\n\nPlease keep this email for your records.`
  };

  const response = await fetch(VOLANEA_API_URL, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify(volaneaPayload)
  });

  const responseBody = await response.text();
  if (!response.ok) {
    console.error("Volanea send failed", response.status, responseBody, { attendee_id, order_id });
    return res.status(502).json({ error: "email provider rejected send" });
  }

  // In production, write this only after a successful provider response,
  // using a database uniqueness constraint on idempotencyKey.
  sent.set(idempotencyKey, { sentAt: new Date().toISOString(), email });
  return res.status(202).json({ status: "sent" });
});

app.listen(3000);

The field mapping happens in two places. Zapier maps fields from the SimpleTix New Attendee trigger into the compact request body. The endpoint maps email to Volanea’s to recipient array, EVENT_FROM_EMAIL to from, and the cleaned event and attendee data into the subject and message content.

Use the current endpoint and request schema in Volanea’s API reference if your account’s API version differs from the example. The security and integration pattern remains the same: Volanea credentials belong in server-side environment variables, never in SimpleTix custom code, a public ticket page, browser JavaScript, or an attendee-visible URL.

Configure authentication and sender identity

There are two secrets in this integration, and they have separate jobs.

SIMPLETIX_ZAPIER_SECRET is configured as a custom header in the Zapier webhook step and as a server environment variable. Its job is to authenticate the Zapier-to-your-server hop. Rotate it if a Zap editor leaves the organization or an automation export is exposed.

VOLANEA_API_KEY exists only in your deployment’s secret manager or environment configuration. Its job is to authorize the server-to-Volanea API call. It must not be added to the SimpleTix event description, embedded in a ticket template, stored in a client-side .env file shipped to a browser, or placed in a Zapier field mapping.

Use a purpose-limited key and a verified From address

Where your credential controls allow it, use a key dedicated to this event integration rather than a shared key used by every service. Record an owner, purpose, creation date, and rotation procedure. Revoking a compromised integration key should not require taking unrelated production mail offline.

Set EVENT_FROM_EMAIL to a sender address on an authenticated domain, such as events@updates.example.com. Authenticate the sending domain with the DNS records Volanea provides. This protects deliverability and helps recipient systems align the visible From domain with the domain authorized to send. Do not use an unverified organizer address simply because it looks more familiar.

Reply handling deserves a decision too. If replies should reach event staff, configure the appropriate reply address in your email payload or sending configuration according to the API reference. If the message is operational but unmonitored, say so clearly and provide a support contact. A no-reply address without an alternate help route creates unnecessary attendee friction.

Test the complete path before publishing the Zap

A successful Zap test proves only part of the path. Test the whole route with a dedicated inbox and an event that is safe for trial registrations. Confirm both the delivery result and the rendered message.

Use this checklist:

Create a test attendee in SimpleTix and confirm the New Attendee trigger finds it.
Inspect the Zapier webhook task to confirm attendee_id, order_id, and email are populated as expected.
Confirm the endpoint returns a 2xx response and logs only non-sensitive identifiers.
Confirm Volanea accepts the request and the email arrives with the intended From domain, subject, text alternative, and reply behavior.
Run the same Zap input again and verify the endpoint returns already_sent rather than generating another message.
Test a missing-email or missing-attendee-ID record and ensure it is rejected or routed to a review queue rather than sent to an unintended recipient.

Keep test and production separate wherever possible. A staging endpoint, a staging sender address, and an allowlist of internal recipient addresses let developers change templates without sending accidental event mail to attendees.

When this breaks: failures specific to this hop

Ticketing-to-automation-to-email integrations fail at boundaries, not just inside code. Treat the SimpleTix-to-Zapier handoff, Zapier-to-endpoint delivery, and endpoint-to-Volanea send as separate observable stages.

Duplicate sends after retries or replayed trigger data

A request can reach your endpoint, cause Volanea to accept an email, and still appear failed to the prior system because the success response was delayed or lost. The automation may retry. Separately, polling-based trigger processing, task replay, a Zap being turned back on, or SimpleTix data being surfaced again can result in an attendee appearing more than once.

That is why the example uses attendee_id plus a versioned message type as its idempotency key. In production, enforce uniqueness in durable storage before or during the send workflow. An in-memory Map is only explanatory; it resets on a redeploy and is unsafe across multiple server instances.

Do not deduplicate only by email address. The same person may legitimately attend two events, buy multiple ticket types, or need a corrected operational message. Do not deduplicate only by order ID either, because an order can have multiple attendees.

Timeouts and slow responses

A webhook-style action has a finite request timeout. If your endpoint waits on a slow database, synchronous template rendering, several third-party APIs, and Volanea before responding, Zapier can time out even when the email eventually sends. That creates the classic duplicate-risk scenario.

Keep this endpoint small. Validate, create a durable job or idempotency record, and return quickly. A worker can perform the Volanea send afterward. If you send synchronously for simplicity, set strict outbound timeouts, log the provider response, and make idempotency non-negotiable.

Do not return a successful response before recording enough state to prevent a retry from becoming a duplicate. The appropriate design depends on your database and queue, but the goal is consistent: a given attendee and message type should have one authoritative send decision.

Missing fields on some registrations or plans

SimpleTix fields available to Zapier depend on event setup and the attendee record. Optional email collection, custom registration questions, imports, historical attendees, ticket transfers, and multi-attendee orders can produce blanks or values that differ from the one record used while building the Zap.

Never make a missing first name fatal if the message can safely say “Hi there.” Conversely, make a missing recipient email fatal: do not guess at a purchaser address or construct an address from another field. Return a 422 status, retain a privacy-conscious error record, and alert the event team to resolve the registration in SimpleTix.

If a required field is absent in the SimpleTix Zapier trigger sample, do not assume another SimpleTix plan or custom field will expose it. Review the SimpleTix/Zapier fields available for the connected account, then adjust the email copy and payload contract to data you can actually receive.

Authentication and sender failures

A 401 from your endpoint usually means the Zapier integration secret does not match, was rotated on one side only, or was not sent as a header. A 401 or 403 from Volanea generally points to the server-side API key or its permissions. A provider rejection related to the sender address is a sender/domain verification issue, not an attendee-data issue.

Keep errors separate in logs and alerts. “Zap failed” is not actionable enough. Include an internal correlation ID, the attendee ID, order ID, HTTP status, and stage name. Avoid logging email body content, API keys, access links, or full payment and registration details.

Make the message useful without turning it into a campaign

A ticketing event provides context other transactional flows do not. Use it carefully. The message should answer the questions that reduce support requests: what event is this, which ticket is associated with it, what should the attendee do next, and where can they get help?

Good attendee instructions are concise and specific:

Event name, date, time zone, and venue or virtual access process.
Ticket type when that changes instructions.
Arrival, check-in, accessibility, age, or equipment requirements.
A support route for corrections and transfer questions.
A link to the authoritative ticket or event page rather than a sensitive token copied into email.

Avoid placing urgency or promotional language in an operational message just because an attendee exists in SimpleTix. If you later add a marketing workflow, make its consent state, audience criteria, unsubscribe handling, and send cadence explicit and separate from this confirmation-style automation.

Version your messages deliberately

The idempotency key in the example includes attendee-instructions-v1. That suffix is practical. If the event moves and every attendee needs a corrected message, changing to attendee-instructions-v2 allows one intentional additional send while preserving protection against retries of the earlier workflow.

Versioning is better than deleting deduplication records in a hurry. It creates an audit trail: which message category was sent, to whom, and when. It also makes it possible to update a template without accidentally re-mailing everyone unless that is the explicit objective.

Operational ownership, monitoring, and deliverability

Assign ownership before event day. One person should own the SimpleTix event configuration, another may own the Zap, and an engineering or operations owner should control the endpoint and Volanea credentials. If none of those owners knows who responds to a failed attendee send, the integration is not operationally complete.

Track at least these metrics: trigger records received, requests rejected for validation, duplicate requests suppressed, Volanea acceptance responses, provider failures, and delivery or bounce signals available from your email platform. Compare counts after ticket-sale peaks. If SimpleTix shows 200 new attendees and the endpoint accepted 197, investigate the difference rather than assuming it is harmless.

Sender reputation is also a system concern. Authenticate the domain, use a recognizable From name, keep transactional content relevant, process hard bounces and complaints, and avoid sudden volume spikes from an untested automation. A well-built integration protects both the immediate event experience and the ability to reach attendees for the next important update.

Conclusion: a secure way to send email from SimpleTix

The reliable way to send email from SimpleTix with Volanea is a controlled automation path: SimpleTix New Attendee in Zapier, a Webhooks by Zapier POST containing only needed fields, and server-side middleware that calls Volanea with a protected API key.

That approach does more than send a message. It distinguishes attendee-level events from order-level events, avoids exposing credentials, handles missing data, and gives retries somewhere safe to land. Start with one clearly transactional message, test unusual registration cases, add durable idempotency, and expand only after the basic path is observable.

FAQ

Does SimpleTix have a native Volanea integration?

No. This setup does not rely on a native SimpleTix or Volanea marketplace plugin. It uses the SimpleTix Zapier integration and a Webhooks by Zapier action to pass data to middleware that you control.

What SimpleTix trigger should start the email?

Use the New Attendee trigger when each ticket holder needs an individual email. It is a better fit than an order-level event for attendee instructions because one order may include multiple attendees.

Can Zapier call Volanea directly?

Technically an HTTP action can call an API, but do not place a production Volanea API key in a Zap step. Put the key in server-side secret storage and have a private middleware endpoint make the Volanea request.

How do I stop a retry from sending two emails?

Use a durable idempotency record keyed by the SimpleTix attendee ID and a message type or version. Return a successful “already sent” response for repeated requests rather than making another provider call.

What should happen when an attendee has no email address?

Reject the payload, log a non-sensitive identifier and the reason, and send it to an operational review process. Do not guess at another address or substitute the purchaser’s email without an explicit, appropriate rule.

How to Send Email From SimpleTix With Volanea