Wix Events has no total ticket limit per event. Here's what works, and how I built one

Full disclosure up front: I build Wix apps, and one of them, Event Capacity & Waitlist, does what this post is about. I'll cover the built-in options first, because for many events they are enough, and then the technical side of how a shared limit can be built on top of the Wix Events APIs.

The problem

Wix Events sets ticket limits per ticket type, not per event. Wix says it directly in a feature request: "You cannot set a general ticket limit of how many tickets you can sell per event."

A typical case: a room for 40 people, with "Standard" and "VIP" tickets. You can't give each type 20, because you don't know the split. You can't give each type 40, because then you might sell 80.

Built-in option 1: one ticket type with price options

If your ticket types only differ in price (adult, child, member), use one ticket type with several price options and set its quantity to the room size. All prices then sell from one pool.

The catch: price options share one name, one description and one sale period. If VIP needs its own description, or early-bird tickets should stop on a date, they have to be separate ticket types again.

Built-in option 2: a seating map

A seating map caps the event at the seats and areas on the map. An "Area" element has a total number of spots, which works for standing room. But each seat or area belongs to one ticket type, so two types can't share the same free places.

Built-in option 3: RSVP events

RSVP events (no payment) have a guest limit and a built-in waitlist. Ticketed events don't: Wix's help article says "Waitlists are not available for ticketed events", and an event can't be switched from ticketed to RSVP later.

Building a shared limit on top of the APIs

Wix has no "event capacity" field to set, so the app works with what exists: each ticket definition's own limit, and the event's tickets-per-order setting. The idea is simple. After every order, recalculate each ticket type's limit:

// remaining = total capacity minus everything sold or held, across all types
const used = types.reduce((sum, t) => sum + t.sold + t.reserved, 0);
const remaining = Math.max(0, capacity - used);

for (const type of types) {
  const taken = type.sold + type.reserved;
  let limit = taken + remaining;                          // what it may sell now
  if (type.ownerLimit !== null) limit = Math.min(limit, type.ownerLimit);
  await setTicketLimit(type, Math.max(limit, taken));     // never below what's sold
}

A few things that turned out to matter:

• Remember the owner's own limits. If the owner set VIP to 20, the app must never raise VIP above 20, and it must put 20 back when the shared limit is switched off. The app stores what it wrote, so it can tell its own values apart from limits the owner changed later.
• Mixed orders. Per-type limits alone let one order take 4 Standard plus 4 VIP when only 4 places are left. The event's "ticket limit per order" counts across types, so the app keeps it at or below the places left.
• Held tickets count. Tickets in an open checkout are reserved, and they need to count as used, or two buyers can check out the same last place.
• Concurrent writes. A sale and a recalculation can touch the same ticket definition at once. Updates carry a revision, and a conflict means: read everything again and retry.
• Sold-out events get no more order events. If a recalculation is interrupted (for example, the owner leaves the page right after saving), nothing triggers the next one. The settings card now checks on open whether the stored limits match the settings, and finishes the update if not.

There's still a small window between an order and the recalculation, so two checkouts started at exactly the same moment could, in rare cases, go one over.

A waitlist for a ticketed event

When the shared total is used up, the app shows a "Join the waitlist" form on the event page (a site plugin on the event details page). When places free up, because an order is cancelled or the owner raises the total, it fires a Wix Automations trigger, so the site's own email goes to the next people in line. It doesn't send email itself, and it doesn't reserve the ticket: the person buys it the normal way.

Summary

• Ticket types that differ only in price: use price options. Free, and one pool.
• Fixed seats: a seating map.
• No payment needed: an RSVP event with its built-in waitlist.
• Different ticket types sharing one total, or a waitlist for a paid event: that needs an app.

If you go the app route, Event Capacity & Waitlist is on the Wix App Market, with a free plan for one event. I wrote a longer, non-technical walkthrough of the built-in options here: https://kayabyte.dev/guides/wix-events-total-ticket-limit-waitlist.html

Questions about the APIs or the approach are welcome in the comments.