Group tickets
A ticket type withgroup_size > 1 admits that many people per unit (a table for 4, a 2-for-1).
Everywhere the API counts tickets it multiplies: quantity is in units, and the tickets
locked, generated and counted against limits are quantity × group_size.
event.max_tickets_per_orderandmax_tickets_per_emailcap tickets, not units.ticket_type.max_per_ordercaps units of that ticket type.- Holds report both:
quantityandticket_count.
Who gets the tickets
By default every ticket of an order is issued to the buyer (customer) and the ticket email
goes to them. Two things change that.
attendees on an item
Send one attendee per generated ticket, exactly quantity × group_size of them, in order:
full_name and a valid email are required;
document_type, document_number and phone are optional. A list of the wrong length is
400 ATTENDEE_COUNT_MISMATCH.
This is how a storefront offers the choice on a group ticket:
require_individual_data on the event
When the event sets it, every ticket needs its attendee: the form must collect
quantity × group_size attendee blocks per item (all fields filled) and send them as
attendees. Checkout without them is refused.
requires_info on the ticket type
Independent of the above: a ticket type with requires_info: true asks the holder to complete
their check-in data (name, document) before the gate. UnderPass collects it in the ticket
email / tickets app; your storefront does not need to.
Document types
POST /api/checkout/allowed-document-types with the ticket_type_ids in the cart returns the
intersection of the localities’ allow-lists. Only offer those in the customer.document_type
selector; an empty list means the cart mixes localities with incompatible rules and cannot be
bought as one order.
