Resources · n8n integration

Eventbrite n8n integrationAutomate Eventbrite with n8n.

Hundreds of registrations, zero manual copy-paste. The Eventbrite n8n integration is trigger-only: one node, 15 webhook events in 6 families, from order.placed to attendee.checked_in. Made for event organizers who track tickets, check-ins and refunds without exports.

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the Eventbrite n8n integration actually do?

The Eventbrite n8n integration pushes what happens on your events into the rest of your tools, through a single webhook. A webhook is a URL that n8n registers with Eventbrite when you activate the workflow; from then on, Eventbrite calls that URL a few seconds after each event, with no polling. The catalog ships the Eventbrite Trigger and no action node, so the work happens on the listening side: 15 events, grouped in 6 families, and whatever you decide to do with them downstream.

An attendee list that fills itself. Tick order.placed and every completed checkout starts a workflow. One branch writes the registration to a shared sheet through Google Sheets, another sends the practical details to the buyer. The organizer stops exporting a CSV the night before the event.

A check-in desk the whole team can see. attendee.checked_in and attendee.checked_out fire as badges are scanned. Route them to a channel in Slack and the room count updates itself, with a quiet alert when a VIP badge goes through the door.

Refunds that never turn into support tickets. order.refunded and order.updated keep the finance side honest: the seat goes back to available in your own base, the accounting line is flagged, and nobody discovers the gap two weeks later. A record in Airtable works well for that, because the same table can hold both the order and its status history.

No action node exists for this tool, so building on top of an event means adding an HTTP Request node once the trigger fires. It calls whatever Eventbrite endpoint the workflow needs, and it reuses the credential already sitting in the trigger, nothing new to configure.

Two things trip up a first build. Organization Name or ID and Event Name or ID are both required fields on the trigger, and there is no field that watches an entire account at once, so a series with several separate listings needs a separate workflow for each one. The second is Resolve Data: leave it off and every payload carries only a URL back to Eventbrite, which the next node then has to fetch manually before it can read a single field. New to n8n itself? The n8n training walks through triggers, credentials and expressions before this page assumes you know them.

Connect

How do you connect Eventbrite to n8n?

  1. 01

    Generate a private token in Eventbrite

    Start with an Eventbrite account, the only thing required before anything else. The authentication documentation on the Eventbrite API platform has a Get a Private Token section that walks through generating the token. Store it only inside n8n: it works like a password, and whoever has it can read the organization behind it.

  2. 02

    Create the credential in n8n

    n8n supports two ways in. Most builders paste the token from the previous step into the Private Key field of an API private key credential. The alternative, OAuth2, is documented by Eventbrite for app partners whose own users need to grant access rather than share a token. Either way, open the Credentials menu, create the credential once, and it shows up in every workflow from then on.

  3. 03

    Point the trigger at one event

    With the credential ready, drop the Eventbrite Trigger on the canvas and pick it from the dropdown. Set Organization Name or ID and Event Name or ID, tick what belongs under Actions, save, and flip the workflow to active. Nothing arrives before that last step: an inactive workflow has no webhook registered with Eventbrite at all.

Triggers

What can the Eventbrite Trigger listen to?

Eventbrite Trigger is the node that starts a workflow when something happens in Eventbrite. It listens to 15 events, listed below by family. Pick one or several, activate the workflow: n8n registers the webhook on your Eventbrite account.

What you see in n8n

Every event, by family

One row per object, one chip per action. The event to tick in the node is object.action; hover a chip to read exactly when it fires.

event.*4
  • event.
    • created
    • published
    • unpublished
    • updated
attendee.*3
  • attendee.
    • checked_in
    • checked_out
    • updated
order.*3
  • order.
    • placed
    • refunded
    • updated
ticket_class.*3
  • ticket_class.
    • created
    • deleted
    • updated
organizer.*1
  • organizer.
    • updated
venue.*1
  • venue.
    • updated

Configuration notes

01Set up the Eventbrite TriggerNothing about this node is complicated once you know what each field controls. Four settings decide what n8n hears from Eventbrite, and get one wrong and the workflow either watches the wrong event or never fires at all.

Nothing about this node is complicated once you know what each field controls. Four settings decide what n8n hears from Eventbrite, and get one wrong and the workflow either watches the wrong event or never fires at all.

Key parameters

  • Organization Name or ID: the Eventbrite organization the trigger works on. Choose it in the list, or specify an ID with an expression such as {{ $json.field }} when the value comes from an earlier node.
  • Event Name or ID: limits the trigger to a single event. Same list, same fallback to an ID through an expression.
  • Actions: the events to listen to. There are 15 of them, spread across 6 families, and there is no wildcard, so tick every event the workflow needs to handle.
  • Resolve Data: off by default, the webhook data only contains the URL to retrieve the object data manually. Switch it on and n8n resolves that data automatically.
Use cases
a workflow built with a single event selected and Resolve Data on is ready to write straight into a spreadsheet row, no extra lookup step needed.
02order.*: the money side of a registrationThree events track a single order end to end, and most registration workflows start from one of them.

Three events track a single order end to end, and most registration workflows start from one of them.

Key parameters

  • order.placed: a buyer completed a checkout. This is the entry point for confirmation messages, CRM records and seat counters.
  • order.updated: the order changed after the fact. Useful when a workflow already wrote the order somewhere and needs to keep that copy aligned.
  • order.refunded: money went back. The seat is free again on your side, and the accounting line needs a flag.
When to use it
this family answers how many tickets moved and what they are worth. Tick all three and an external table stays accurate without anyone updating it by hand, which matters most once more than one person is selling for the same organization.
03attendee.*: what happens at the doorPeople move through a door, and this is the family that watches them do it: three events, and none of them touch money or the event page itself.

People move through a door, and this is the family that watches them do it: three events, and none of them touch money or the event page itself.

Key parameters

  • attendee.checked_in: a badge was scanned at the entrance, so the person is now in the room.
  • attendee.checked_out: the same attendee was checked back out.
  • attendee.updated: an attendee record changed, which is what you watch when a name or a ticket assignment gets corrected before the doors open.
When to use it
this is the family for anything happening at the door itself, a live headcount on a screen, a badge printer queue that only prints for people who showed, a thank-you sequence that skips no-shows entirely. Two separate events for entering and leaving is what lets a workflow tell current occupancy apart from total traffic, a distinction that matters the moment a venue has a capacity limit to respect.
04event.*: the publication lifecycleFour events, the largest family here, and all four describe the page itself rather than anything sold on it.

Four events, the largest family here, and all four describe the page itself rather than anything sold on it.

Key parameters

  • event.created: a draft exists in the organization, before anything reaches the public.
  • event.published: the page is live and seats can be sold.
  • event.unpublished: it left public view.
  • event.updated: a detail changed, date, description or anything else on the record.
When to use it
event.published works well as the internal signal to start an announcement sequence, and event.updated is the one worth wiring up so an outdated date never lingers on a partner's site. Some teams also route event.created to a checklist reminder, catching a draft that is still missing a venue or a price before it goes anywhere near the public.
05ticket_class.*, organizer.updated and venue.updatedThree quiet families share a note because none of them fire during a sale: they report on how the event itself is set up.

Three quiet families share a note because none of them fire during a sale: they report on how the event itself is set up.

Key parameters

  • ticket_class.created: a new ticket type exists, early bird, standard or student.
  • ticket_class.updated: an existing ticket type changed after publication.
  • ticket_class.deleted: a ticket type was removed, which is a different signal from a simple edit.
  • organizer.updated: the organizer profile changed.
  • venue.updated: the venue record changed.
When to use it
a channel wired to ticket_class.deleted turns an accidental removal into something noticed within minutes instead of at the next sales report, and venue.updated deserves the same treatment whenever an address already feeds printed signage or a mailing that has gone out. None of these five events looks urgent by itself, which is exactly why they get missed.
Need help

Need help automating Eventbrite with n8n?

A person reads every message.

FAQ

Eventbrite and n8n, common questions

01Is the Eventbrite n8n integration free?
Yes, on the n8n side. Because the Eventbrite Trigger ships as part of n8n itself, there is no separate package to install and no extra fee layered on top, whether the workflow runs on n8n Cloud or on a self-hosted instance under the Community Edition's Sustainable Use license. Behavior does not change between the two: a trigger built on Cloud moves to a self-hosted server without edits. Eventbrite's own pricing is a separate matter this page leaves alone. The one thing needed regardless of hosting is an Eventbrite account that can issue a token.
02What credentials does the Eventbrite Trigger need?
Two methods work, and both start from an Eventbrite account. The fast path is the API private key: generate it in the Eventbrite API platform under Get a Private Token, then paste that string into the credential's Private Key field. The slower path is OAuth2, meant for app partners who need end users to authorize the connection themselves rather than share one token. Whichever method you pick, the credential lives in the Credentials menu, created once and offered by name in every workflow that adds the trigger afterward.
03What are the limits of Eventbrite in n8n?
The catalog here is trigger-only: 15 events across 6 families, 0 operations, and the trigger sits at version 1. Anything the trigger cannot cover goes through the HTTP Request node instead, calling any Eventbrite API endpoint while reusing the same credential through predefined authentication. Two design choices matter early. The trigger locks onto a single organization and a single event, both required fields, so covering several events means building several separate workflows. And with Resolve Data left off, the payload only carries a URL back to the object, not the object itself.
04Does the Eventbrite Trigger work in real time?
Yes. The mechanism is a webhook: activating the workflow registers a URL with Eventbrite, and every event lands within seconds after it happens, no polling loop involved. That speed is what makes a live check-in counter possible, since attendee.checked_in needs to update a screen before the next guest reaches the door. One gap to plan around: while a workflow sits inactive, Eventbrite has nothing to call, so nothing is buffered, and turning the workflow back on does not backfill what fired during the pause.
05n8n or Make for Eventbrite?
It depends, though both tools handle Eventbrite fine day to day. Hosting is the first of four things to weigh: n8n runs on your own infrastructure or on n8n Cloud, while Make only exists as a hosted service, which settles the data control question at the same time for teams that need attendee records to stay in-house. Cost model is next, since Make charges per operation, worth checking against how many events a packed registration week can generate. Visual logic differs too, though that is mostly a matter of habit rather than capability.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.