Eventzilla
SchedulingConnect AI agents to Eventzilla, an event registration and ticketing platform. Agents pull attendees, orders, and transactions, manage free ticket types, check attendees in, confirm or cancel orders, and open or close ticket sales for an event.
What This Integration Enables
Eventzilla's public API is the box office, not the event page, and building against it goes better once that is accepted. Eventzilla's API v2 exposes no endpoint to create or update the event record itself: events are created in the Eventzilla dashboard by a person. What the API does expose is everything that happens to an event once it is live, which is the part that repeats and the part that costs somebody their evening. List Events, Get Event and List Categories read the catalog. List Event Attendees returns registrants with the ticket type, barcode, check-in status and the associated transaction reference on each one, which is what turns the attendee list into something a check-in app or a downstream CRM can consume directly. List Event Transactions returns the purchase side with the reference number, checkout ID, buyer, amount, tax, discount, Eventzilla fee, payment type and status, so revenue for an event is reconstructable per transaction rather than as a headline total.
The write surface is small, deliberate and money adjacent, and it is worth being precise about its edges. Create Ticket Type and Update Ticket Type apply to free ticket types, so an agent can open, resize, time box or hide a free tier and cannot conjure a paid one. Check In Attendee marks an attendee attended by ticket barcode and can also revert a check-in, which makes the check-in state correctable rather than one way. Confirm Order finalises a pending order by checkout ID and event ID and sends a confirmation email to the buyer by default, and Cancel Order voids an order and records the supplied comments as the reason. Toggle Event Sales turns ticket sales on or off for an entire event with a single boolean.
Eventzilla documents no webhook subscription API, so this connector ships no triggers. Every reactive flow here is a scheduled poll, and the natural cadence is set by what you are watching: attendee and transaction lists on the days a paid event is selling, ticket type sold counts hourly in the final week, and a single run the morning of the event to build the check-in roster. The offset and limit paging on List Events and the per event scoping on the attendee and transaction reads mean a poll can be narrow, which matters when an account carries a long history of completed events that nothing needs to re-read.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A check-in list that is right at the door
An organiser runs a conference where registrations keep arriving on the morning of the event. Rather than exporting a list the night before, the agent calls List Event Attendees on a short schedule through the morning, which returns each attendee with their ticket type, barcode and current check-in status. It pushes the roster into the check-in tool the door staff actually use and refreshes it in place, so a person who registered in the taxi is on the list when they reach the desk. As door staff scan, the agent calls Check In Attendee with the barcode, and where somebody is scanned in error it calls the same action with Check In set to false to revert it. Halfway through the morning it posts arrival counts by ticket type to the operations channel in Slack, which is the number the catering lead needs and the number nobody has time to count.
Box office orders that close themselves out
Some registrations do not go through the storefront. A sponsor is invoiced, a partner takes seats against a contract, a delegate pays by bank transfer. Those land as pending orders and stay pending until an organiser gets to them. The agent watches the payment side: when a matching payment appears in Stripe or an invoice is marked paid in Xero, it calls Get Transaction by reference number to confirm the Eventzilla side matches, then Confirm Order with the checkout ID and event ID, adding internal comments recording which payment evidenced it. Where a payment window closes with nothing received, it does not cancel silently: it assembles the pending orders with their age and value and puts them in front of the organiser, and calls Cancel Order only on the ones a person names, recording the reason in the comments so the audit trail explains itself later.
Selling against the room rather than against the allocation
A workshop is capped by the room, not by the ticket allocation, and the two numbers drift apart the moment a free tier is added. On a schedule the agent calls List Ticket Types for the event and reads the sold count and total quantity on each, then List Event Attendees to count actual registrants including any created outside the standard tiers. It compares the real total against the room capacity the organiser configured in the flow rather than against any number Eventzilla holds. As the gap closes it calls Update Ticket Type to bring the remaining free tier quantities down so the storefront stops offering seats that do not exist, and posts the current position to the event owner. The one thing it does not do on its own is close the event, because the last hundred metres of that decision belongs to a person.
Human-in-Loop Highlight
Toggle Event Sales is the gate, and it earns the gate because of its granularity rather than its reversibility. It is one boolean applied to an entire event. There is no per ticket type version of it, no scheduling, and no partial close: false means every person who reaches the registration page after that moment sees an event that is not selling, whichever tier they were coming for and whatever the marketing they clicked through from promised. Flipping it back to true restores the storefront and does not restore the people who bounced, and for a paid event that is unrecovered revenue that nobody will ever see in a report because the transaction never existed. The signal that triggers this decision is also the weakest one in the connector. Capacity has to be assembled from ticket type sold counts, an attendee count, and a room limit the flow was told about by a human at design time, and any of the three can be stale or simply wrong: a comp list issued outside the standard tiers, a block held for a sponsor, a hybrid event where half the registrations do not need a chair. So the agent brings the arithmetic and stops. It posts to the event owner in Slack: "Regional Ops Summit, 21 June. List Event Attendees returns 238 registrants. List Ticket Types shows General 180 of 180 sold, Member 44 of 60, Speaker Guest 14 of 20. You told me the room seats 240. That is two seats, and 26 tickets are still purchasable across the two open tiers. I can reduce Member and Speaker Guest to their sold counts with Update Ticket Type, which stops new sales on those tiers but leaves the event open, or I can run Toggle Event Sales with Sales Enabled false, which closes registration for the whole event including the sponsor block you may still be holding. Which one?" The owner picks, once, on the only decision here that cannot be quietly undone. That is the human-in-the-loop moment in event operations: an agent can count the room, and only a person should decide to shut the door on it.
Agent Capabilities
16 actionsEvents
5- List Events Returns the events on the account, filterable by publication status (Live, Draft, Unpublished, Completed) and by category, with offset and limit paging. Returns summaries including id, title, dates, venue and status.
- Get Event Returns the full detail of one event by numeric event id, including title, description, schedule, venue, organizer and configuration.
- List Event Transactions Returns the ticket purchase transactions for an event, each with the reference number, checkout id, buyer details, amount, tax, discount, Eventzilla fee, payment type and status. The read that makes per event revenue reconciliation possible.
- List Event Attendees Returns the attendees registered for an event, each with name, email, ticket type, barcode, check-in status and the associated transaction reference. This is the check-in roster and the CRM sync source in one call.
- Toggle Event Sales Turns ticket sales on or off for an entire event with a single flag. There is no per tier version of this, so false closes the storefront for every ticket type at once, which is why it runs behind an approval.
Ticket Types
3- List Ticket Types Returns the ticket types configured on an event with each type's id, title, price, total quantity, sold count, visibility and sales window. The sold count against total quantity is the capacity signal a scheduled poll watches.
- Create Ticket Type Creates a new free ticket type on an event, with name, total quantity, description, sales start and end, per order minimum and maximum, and visibility. Optionally carries attendee instructions and an unlock code for a hidden tier. Applies to free ticket types.
- Update Ticket Type Updates an existing free ticket type. Only supplied fields are sent, so bringing a remaining quantity down to the sold count is a single narrow call rather than a full rewrite of the tier.
Attendees
2- Get Attendee Returns one attendee by attendee id with name, email, ticket type, barcode, check-in status and transaction reference.
- Check In Attendee Checks an attendee in by ticket barcode, or reverts a previous check-in by setting Check In to false. The revert is what makes an automated door flow safe to run at all.
Orders
2- Confirm Order Confirms a pending order by checkout id and event id, with optional internal comments and control over whether a confirmation email goes to the buyer, which defaults to sending. The action for finalising offline and box office orders once the payment is evidenced elsewhere.
- Cancel Order Cancels an order by checkout id and event id, recording the supplied comments as the reason. Used to void a registration or as the Eventzilla side of a refund workflow that started in the payment processor.
Transactions
1- Get Transaction Returns one transaction by checkout id or reference number, with buyer details, amount, tax, discount, Eventzilla fee, payment type, date and status. The lookup that matches an inbound payment to the Eventzilla order it belongs to.
Users
2- List Users Returns the organizers and sub-organizers on the account with username, name, company, email, timezone, phone and user type.
- Get User Returns one organizer or sub-organizer by user id.
Reference Data
1- List Categories Returns the event categories available on Eventzilla, such as Business, Conferences, Networking and Training. Used to filter List Events by category name.
Frequently Asked Questions
What can FlowRunner do with Eventzilla?
FlowRunner agents can run List Events, Get Event, and List Event Transactions in Eventzilla, plus 13 more actions.
Does connecting Eventzilla to FlowRunner require OAuth?
No. Eventzilla connects to FlowRunner with an API key, no OAuth flow required.
Can Eventzilla trigger a FlowRunner workflow automatically?
Eventzilla doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Eventzilla
$100 in credits. No card required. Connect in minutes.