EventSquare

A sponsor asks for thirty seats across two nights, and the answer they get should be true when they read it. The agent starts at Get Event with the event slug to resolve which editions are published, calls Get Edition for the ticket types, shows, prices and availability, and then Get Show for each of the two nights, since availability is a per show property rather than a per event one. For an assigned seating show it goes one level further and calls Get Seatmap using the reference the show returned, which gives sections and per seat availability, so the proposal can name blocks of adjacent seats rather than a quantity. What the sponsor receives back is a specific offer: these sections, these rows, this price per ticket type, quoted at a stated time. Nothing has been reserved at this point, which is the correct default, because a quote that silently holds inventory is how an event ends up with a third of its house locked in unfinished conversations.

After an order completes in EventSquare's own checkout, the collection is the object worth automating around. Given a collection UID from an order confirmation, the agent calls Get Collection for the buyer details and the order summary, Get Collection Tickets for the individual tickets with their barcodes, types, shows and seat assignments, and Get Collection Actions to see what is actually available for that pocket, such as a download or a resend. That combination answers most of the volume a ticketing inbox carries. A buyer who says the tickets never arrived gets a factual answer about what exists and which actions are offered, posted to the support channel in Slack with the ticket count and seat list attached, rather than a member of staff opening the back office and reading it out. Because there is no trigger, this runs from the inbound request or from a scheduled sweep of recent collection UIDs held in Airtable, not from an event pushed by EventSquare.

When a group booking is approved, the hold has to be built and then, more importantly, cleaned up. The agent uses Update Cart Item to set the reserved quantity for each ticket type, scoped to the show and, for assigned seating, to the specific seat places from the seatmap, and reads the result back with Get Cart to confirm the reserved types, quantities, seats, applied deals and running total match what was approved. From that point the cart has a life of its own, so the flow keeps a scheduled check against it: if the sponsor has not completed the purchase by the agreed deadline, the agent does not simply let it sit. It posts the position and, once released, calls Remove Cart Item or sets the quantity to zero so the seats return to public sale before the on sale window that matters. The pattern worth copying here is that the creation of the hold and the expiry of the hold are both events a person hears about, because in ticketing an unreleased hold is a lost sale that nobody ever sees.