How to Send Email From Eventbrite With Volanea

Eventbrite is excellent at collecting registrations, but its event workflow is not a general-purpose transactional email API. This guide shows how to send email from Eventbrite with Volanea by receiving an Eventbrite webhook, retrieving the relevant registration data, and sending a tailored email through Volanea’s REST API.

The important architectural detail is that Volanea does not have a native Eventbrite marketplace app or plug-in. The dependable route is an Eventbrite webhook connected to server-side middleware you control. That middleware is where credentials stay private, duplicate deliveries are handled, attendee data is mapped, and the Volanea API call is made.

What the Eventbrite-to-Volanea integration does

The most common use case begins when somebody completes registration for an event. Eventbrite records the registration as an order and can notify a subscribed webhook endpoint when the order.placed action occurs. Your endpoint receives a compact Eventbrite notification, looks up the order through Eventbrite’s API, and then asks Volanea to deliver the message.

That sequence is useful when Eventbrite’s own attendee email features are not the right channel for the message. For example, a ticket buyer may need a product onboarding email, a message containing information from your own application, a membership welcome sequence, or an internal notification to an event team.

A production flow looks like this:

1. An attendee completes an Eventbrite registration or ticket purchase.
2. Eventbrite emits an order.placed webhook notification to your HTTPS endpoint.
3. Your middleware verifies the request, records its idempotency state, and reads the notification’s api_url.
4. The middleware calls Eventbrite’s API to retrieve the order and attendee information needed for the email.
5. The middleware maps the order data into a Volanea send request.
6. Volanea accepts the request and returns a delivery request identifier.
7. Your middleware stores the outcome so a webhook retry cannot send the same email twice.

This is deliberately a server-to-server design. The browser used by the attendee never sees either the Eventbrite private token or the Volanea API key.

The real Eventbrite trigger: order.placed

For a registration-driven message, the Eventbrite webhook action to subscribe to is order.placed. In Eventbrite’s model, an order is created when a buyer or registrant completes an order; the order can contain one or more attendees and tickets. That is different from assuming there is one webhook per person.

This distinction matters for group registration. A purchaser can buy several tickets in a single order, and each ticket can have its own attendee details. Before building the integration, decide whether the email should go to:

• the purchaser only;
• every attendee associated with the order;
• the purchaser plus an internal team mailbox; or
• only attendees whose ticket class meets a business rule.

For a standard registration confirmation or a pre-event welcome, sending one message to the purchaser is usually the safest first implementation. If you send one email per attendee, deduplicate by attendee ID rather than by order ID.

Eventbrite webhooks are created through Eventbrite’s Webhooks API. They are not an Eventbrite Marketplace installation, and they do not themselves execute arbitrary JavaScript or transform a request into a call to another API. You register a publicly reachable HTTPS endpoint and choose the Eventbrite action that should notify it.

What Eventbrite posts to your endpoint

Eventbrite webhook notifications are intentionally small. They tell your application which resource changed and provide an API URL that your service can use to retrieve the canonical resource. A representative order.placed notification has this shape:

{
  "api_url": "https://www.eventbriteapi.com/v3/orders/1234567890/",
  "config": {
    "action": "order.placed",
    "user_id": "987654321"
  }
}

Do not treat that payload as a complete attendee record. It does not reliably contain the recipient address, ticket name, event title, answers to registration questions, or all attendee records. The api_url is the important field: use it on the server to fetch the order from Eventbrite before composing the email.

This resource-first webhook pattern also prevents a subtle mistake: mapping a webhook’s event or order identifier directly to a recipient email. An ID is not an email address, and a webhook event should never be assumed to contain the complete current state of the order.

Why middleware is required

A direct Eventbrite webhook cannot safely call Volanea on its own. Eventbrite delivers an HTTP request to an endpoint; it does not provide a native “send this payload to Volanea” configuration that stores and protects a Volanea secret for you.

Your middleware can be a small Node.js service, a serverless function, a container endpoint, or an API route in an existing application. Its job is modest, but it is security- and reliability-critical:

• accept Eventbrite’s webhook request quickly;
• validate that the request is expected;
• retrieve the order from the Eventbrite API with a private Eventbrite token;
• select the intended recipient or recipients;
• generate the subject and HTML/text content;
• call Volanea with a private API key;
• record the Eventbrite resource and send outcome for idempotency;
• return a successful response promptly after durable processing or queueing.

For teams that do not run an application backend, an automation platform can supply this middleware layer. Eventbrite offers Zapier integration, and Zapier or Make can receive an Eventbrite registration trigger and make an authenticated webhook request to another service. That can be appropriate for a low-volume operational alert. For attendee-facing email, a dedicated endpoint is usually more controllable because it can retrieve the authoritative order resource, retain audit data, handle retries predictably, and keep template logic in version control.

Create the Eventbrite webhook subscription

Create a webhook subscription with Eventbrite’s Webhooks API using an Eventbrite account token that has access to the organization and events concerned. The subscription points at an HTTPS URL owned by your application, such as https://hooks.example.com/eventbrite/order-placed.

The exact subscription request and authorization method should be taken from the Eventbrite API documentation for your account and API version. The key operational choices are the target endpoint, the order.placed action, and the Eventbrite user or organization scope. Keep the subscription narrow: do not subscribe to unrelated actions merely because your endpoint can receive them.

Before enabling a live event, test the endpoint against a private test event or a controlled registration. Confirm all of the following:

1. Eventbrite can reach the endpoint over public HTTPS.
2. The endpoint returns a successful HTTP response within Eventbrite’s delivery window.
3. The api_url can be retrieved using the Eventbrite token held by the service.
4. The returned order includes the buyer or attendee information your email requires.
5. The Volanea message uses a verified sender domain and a recipient address you control.

If Eventbrite exposes webhook configuration under account-specific API access rather than the dashboard plan you use, that is an Eventbrite access consideration, not something Volanea can bypass. In that case, use the Zapier or Make route, or obtain the required Eventbrite API access, rather than building around an unavailable webhook feature.

Fetch the order before mapping email fields

After Eventbrite sends the notification, call the api_url contained in the payload. Use server-side authorization. The resulting order resource provides information such as the order ID, event details, costs, buyer information, and attendee collection, subject to the data Eventbrite has collected and the permissions of the token.

The buyer record is often the best recipient for an order-level message. However, buyer information can be incomplete in some registration configurations, and the purchaser is not necessarily the attendee. Build explicit fallback rules rather than silently sending to an undefined field.

A practical mapping policy is:

Avoid putting raw registration answers straight into HTML. Treat free-text answers as untrusted input and escape them before rendering. The same applies to attendee names and event names, even though those values come from a trusted platform: safe HTML output is still good application hygiene.

Working middleware example: Eventbrite webhook to Volanea

The following Node.js example shows the complete hop. It receives Eventbrite’s order.placed payload, fetches the order using the webhook’s api_url, maps buyer and event data, and posts a transactional email to Volanea.

The Volanea key is read from a server environment variable. It is not included in Eventbrite’s webhook URL, request body, browser code, or an Eventbrite custom field.

import express from "express";

const app = express();
app.use(express.json({ type: "application/json" }));

const EVENTBRITE_TOKEN = process.env.EVENTBRITE_PRIVATE_TOKEN;
const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY;
const FROM_EMAIL = "Events Team <events@your-verified-domain.example>";

// Replace this with Redis, Postgres, or another durable shared store in production.
const processedOrders = new Set();

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

app.post("/eventbrite/order-placed", async (req, res) => {
  const webhook = req.body;

  // Eventbrite's notification identifies the action and the canonical API resource.
  if (webhook?.config?.action !== "order.placed" || !webhook?.api_url) {
    return res.status(400).json({ error: "Unexpected Eventbrite webhook payload" });
  }

  try {
    // Fetch the authoritative order resource; the webhook body is not attendee data.
    const orderResponse = await fetch(webhook.api_url, {
      headers: {
        Authorization: `Bearer ${EVENTBRITE_TOKEN}`,
        Accept: "application/json"
      }
    });

    if (!orderResponse.ok) {
      throw new Error(`Eventbrite order lookup failed: ${orderResponse.status}`);
    }

    const order = await orderResponse.json();
    const orderId = String(order.id);

    // Idempotency: Eventbrite can retry a webhook delivery.
    if (processedOrders.has(orderId)) {
      return res.status(200).json({ status: "already_processed", orderId });
    }

    const recipient = order?.buyer?.email;
    if (!recipient) {
      // Record this state in durable storage and alert your team in production.
      return res.status(202).json({ status: "no_buyer_email", orderId });
    }

    const name = order?.buyer?.first_name || order?.buyer?.name || "there";
    const eventName = order?.event?.name?.text || "your Eventbrite event";
    const safeName = escapeHtml(name);
    const safeEventName = escapeHtml(eventName);

    const volaneaResponse = await fetch("https://api.volanea.com/v1/emails", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        Accept: "application/json"
      },
      body: JSON.stringify({
        from: FROM_EMAIL,
        to: [recipient],
        subject: `You're registered for ${eventName}`,
        html: `<p>Hi ${safeName},</p><p>Thanks for registering for <strong>${safeEventName}</strong>.</p><p>Your Eventbrite order reference is ${escapeHtml(orderId)}.</p>`,
        text: `Hi ${name},\n\nThanks for registering for ${eventName}.\n\nYour Eventbrite order reference is ${orderId}.`,
        tags: [
          { name: "source", value: "eventbrite" },
          { name: "eventbrite_order_id", value: orderId }
        ]
      })
    });

    if (!volaneaResponse.ok) {
      const detail = await volaneaResponse.text();
      throw new Error(`Volanea send failed: ${volaneaResponse.status} ${detail}`);
    }

    processedOrders.add(orderId);
    const result = await volaneaResponse.json();
    return res.status(200).json({ status: "sent", orderId, message: result });
  } catch (error) {
    console.error(error);
    // A non-2xx response allows Eventbrite's delivery behavior to retry where applicable.
    return res.status(500).json({ error: "Webhook processing failed" });
  }
});

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

The request uses a conventional Volanea email payload with from, to, subject, html, and text. Check the Volanea API reference and setup guides before deployment for the current endpoint, authentication format, message schema, attachment handling, and any account-specific sending requirements.

For real traffic, replace the in-memory Set with a database table or Redis key that persists across restarts and works across multiple instances. Store at least the Eventbrite order ID, intended message type, Volanea message identifier, status, and timestamp.

Keep API keys out of Eventbrite and the browser

The Volanea API key belongs only in the middleware’s secret manager or encrypted environment configuration. Examples include a cloud-function secret store, a container platform’s encrypted environment variables, or a managed secrets service.

Do not place the key in any of these locations:

• an Eventbrite event description, registration question, or custom field;
• a webhook query parameter such as ?api_key=...;
• JavaScript delivered to registrants’ browsers;
• a public Git repository or front-end build variable;
• a Zapier or Make field that could be shown in a task log without using that platform’s secure connection/secret facilities.

A webhook URL can itself be a sensitive ingress point, but it is not a substitute for request verification. Use a secret path component, validate Eventbrite webhook authenticity according to Eventbrite’s documented verification mechanism, restrict accepted methods and content types, and log minimally. Never log an authorization header or the full buyer record when an order ID is enough for troubleshooting.

Use separate Volanea API keys for development, staging, and production where possible. That makes it possible to revoke a compromised development credential without interrupting live attendee messages. It also prevents a test registration from accidentally emailing a real event audience.

Design the email around registration reality

An Eventbrite order confirmation is a transactional context, but not every message related to an event has the same purpose. Keep the trigger and email type aligned.

A good immediate post-registration email usually contains a confirmation or welcome, event name, next action, and a support path. It should not become a broad marketing newsletter simply because the recipient registered. Consent, local laws, and Eventbrite’s collected permissions still matter when a follow-up message promotes other events or products.

Useful messages to send after order.placed

• A membership activation message when a paid ticket creates access in another product.
• A personalized onboarding email with a link to select a session or complete a profile.
• An internal operations alert for high-value, VIP, or group orders.
• A calendar, venue, or preparation email generated from data in your own system.
• A receipt-adjacent support message when your business needs content not covered by the Eventbrite confirmation.

Use a verified Volanea sender domain that clearly matches the organization attendees recognize. Configure domain authentication before sending at volume, maintain a valid reply-to process, and avoid suddenly changing the From identity between Eventbrite’s own confirmation and your follow-up.

When this breaks: Eventbrite webhook failure modes

The fragile point is not usually the JSON formatting. It is the boundary between Eventbrite’s delivery attempt, your retrieval of the resource, and your email provider request. Treat each as independently fallible.

Retries can create duplicate sends

Webhook systems retry when they do not receive the expected success response, including cases where your application sent the Volanea email but crashed or timed out before responding to Eventbrite. If your handler blindly sends on every delivery, one registration can receive several copies.

Use an idempotency key based on the Eventbrite order ID and message purpose, such as eventbrite:order:1234567890:welcome-v1. Write a pending or sent record before, or atomically around, the Volanea call. If the same order arrives again, return success without sending another message. For per-attendee messages, key on attendee ID plus message purpose instead.

Webhook timeouts and slow downstream calls

Your endpoint must respond fast enough for Eventbrite’s webhook delivery expectations. A call to Eventbrite’s API plus template rendering plus a Volanea request may occasionally be slow, especially during an on-sale rush or provider incident.

A more resilient design acknowledges the webhook quickly after persisting a job, then performs Eventbrite lookup and Volanea delivery in a worker queue. The queue record should include the raw notification, received time, retry count, idempotency key, and status. This architecture avoids holding Eventbrite’s request open while an external email provider is slow.

Expected fields may be absent

Do not assume every order has buyer.email, every attendee has an email, or every event collects first names and custom answers. Eventbrite configurations, free registrations, privacy choices, account permissions, and plan or feature availability can affect which fields are available to an API caller.

Validate required fields before calling Volanea. When data is absent, do not manufacture a recipient address or send a malformed greeting. Store a structured skipped_missing_recipient state, alert the responsible team if it matters operationally, and make the fallback behavior intentional.

An order can contain multiple attendees

Sending one message to buyer.email is not equivalent to notifying every attendee. Conversely, sending to every attendee can cause an unwanted duplicate when the buyer is also an attendee. Write the policy down, test group orders, and keep the deduplication key at the same entity level as the policy.

Eventbrite API lookup can fail after the webhook arrives

A valid webhook does not guarantee that your token can retrieve the resource forever. Tokens can be revoked, permissions can change, the resource can become unavailable, or the Eventbrite API can return a transient error. Queue retryable lookup errors with exponential backoff and alert on authorization errors rather than retrying them indefinitely.

Observability and deliverability after the handoff

A 200 response from your endpoint means only that your application accepted or processed Eventbrite’s notification. A successful Volanea API response means the message was accepted for sending. Neither statement alone proves that the attendee saw the email.

Track the workflow at three levels:

1. Webhook intake: Eventbrite notification received, action, order ID, and processing latency.
2. Message submission: Volanea request ID, recipient-domain category, template version, and idempotency result.
3. Delivery outcome: delivery, bounce, complaint, and engagement events where those are appropriate for the message type.

Avoid using full email addresses as primary log fields. Hash them or store them in access-controlled operational data. Order IDs and Volanea message IDs are generally better correlation identifiers.

Deliverability is also an integration concern. If Eventbrite registration messages suddenly generate bounces, do not immediately blame webhook code. Check whether the buyer field is being selected correctly, whether a custom registration question was mistakenly mapped as an email address, whether the sender domain is authenticated, and whether a template change introduced problematic content.

Alternatives to a custom webhook service

A custom endpoint is not the only implementation route, but it is the route with the clearest control over security and duplicate prevention.

Zapier or Make

An automation platform can use an Eventbrite registration trigger and an HTTP request step to call a Volanea endpoint. Store the Volanea key in the platform’s secure credential or connection setting, not in a mapped text field. This is fast to prototype and suitable for lower-volume workflows.

The trade-off is that data mapping, error recovery, branching, task costs, and deduplication are controlled through the automation platform. Confirm that its Eventbrite trigger exposes the buyer and attendee fields you require; do not assume a trigger sample represents every Eventbrite event configuration.

Scheduled Eventbrite API polling

If webhooks are unavailable to your Eventbrite account, a scheduled service can query Eventbrite orders and process records it has not seen before. Polling is less immediate and requires careful pagination and cursor/state management, but it can be a valid fallback.

Use the same idempotency scheme as the webhook approach. Polling without durable state simply moves the duplicate-send problem from webhook retries to repeated API scans.

Eventbrite’s own attendee emails

For standard event logistics, Eventbrite’s native attendee communication tools may be simpler than adding an API workflow. Use middleware and Volanea when the email needs data, branding, logic, or lifecycle coordination outside Eventbrite—not merely because an integration is possible.

Production checklist

Before turning on live sends, verify these items:

• Your Eventbrite webhook is subscribed to order.placed for the intended account scope.
• The endpoint is public HTTPS, accepts only expected requests, and follows Eventbrite’s documented verification guidance.
• The Eventbrite private token and Volanea API key are stored as server-side secrets.
• Your code retrieves the resource at api_url rather than expecting full attendee details in the webhook notification.
• The recipient policy is explicit for buyer, attendee, and group-order scenarios.
• Durable idempotency prevents duplicate sends across retries and deployments.
• The Volanea From domain is verified and your reply path is monitored.
• Missing fields, Eventbrite lookup failures, and Volanea API failures are visible in logs and alerts.
• Development and production use separate credentials and test recipients.

This setup creates a clean boundary: Eventbrite remains the source of registration events, your middleware owns business rules and security, and Volanea handles email sending. That boundary is easier to test and change than a fragile chain of client-side scripts or manually copied exports.

FAQ

Can I install Volanea from the Eventbrite Marketplace?

No. Volanea does not provide a native Eventbrite Marketplace app or plug-in. Use Eventbrite webhooks with server-side middleware, or use an automation platform such as Zapier or Make as the integration layer.

Which Eventbrite event should trigger the email?

For a registration-completion workflow, subscribe to the Eventbrite webhook action order.placed. Fetch the order from the webhook payload’s api_url before selecting recipients or creating the message.

Does the Eventbrite webhook include the attendee email address?

Do not rely on it to do so. Eventbrite webhook notifications are resource notifications and include an api_url; retrieve the order resource through Eventbrite’s API to obtain the available buyer and attendee data.

Where should I put the Volanea API key?

Store it only in server-side middleware secrets or a trusted automation platform’s secure credential storage. Never expose it in Eventbrite fields, a webhook URL, front-end JavaScript, or a public repository.

How do I stop duplicate emails after Eventbrite retries a webhook?

Persist an idempotency record keyed by Eventbrite order ID and message type before treating the send as complete. If Eventbrite delivers the same order notification again, return success without submitting a second Volanea message.