Skip to main content

Event groups

Rate limits

This endpoint belongs to the priority lane.

Sometimes you need to change the status of objects for a whole bunch of events at once. A good example is when you have a multi-day event (Friday to Sunday), for which you sell single-day tickets, but also combi-tickets for Fri-Sat, Sat-Sun or the whole weekend.

Event groups are only really useful in a couple of specific use cases, and they are incompatible with a number of features, such as best available seat selection.
In most cases, you should use seasons instead of event groups. They're basically event groups on steroids. takes care of the all-or-nothing aspect of grouped events: either booking succeeds for all events, or it doesn't succeed for any of them. So prefer doing a single change status call with a number of events as parameter, instead of changing the object status for each event individually.

Event Groups & Channels
An event group is an ad-hoc collection of events, and as such cannot have channels of its own. However, event groups do support channels, in the following way:

  • Channels on differents events are equal if their key is the same. So for instance, if Event1 had a channel with key 123 and Event2 has a channel with key 123, that's considered to be the same channel.
  • Seats that are assigned to a channel on all events, are assigned to the channel for the event group. This means that you can only book a seat on an event group if that seat is either:
    • not assigned to any channel on any event in the group
    • assigned to the same channel on all events in the group (and of course if you pass in the correct channel key when booking)

calling this API will be considered as a "booking" for each event in the event group for pricing purposes.

POST https://api-{region}
POST https://api-{region}
POST https://api-{region}
POST https://api-{region}


"objects": ["A-3", "A-5", "A-7"],
"events": ["event1", "event2", "event3"],
"status": "myCustomStatus"
  • objects: an array of object ids to release
  • events: an array of event keys
  • status: the status you want to assign to an object
  • holdToken (optional): the hold token must be supplied when you want to make sure that the same person that made the hold confirms his booking.
  • orderId (optional): an order id, defined by yourself, to be able to retrieve the objects IDs per order later on.
  • keepExtraData (optional): boolean. If set to true, the existing extra data doesn't get cleared
  • channelKeys (optional): an array of strings, i.e. the channel keys of the channel(s) to which the objects belong. If omitted, and the objects to be booked are assigned to a channel, the request will fail with 400 Bad request. Pass in NO_CHANNEL as channel key to allow objects without a channel.
  • ignoreChannels (optional): if true, the booking call succeeds, even if the booked objects belong to a channel. Useful inside a back office application, in which the user is allowed to book any seat - no matter the channel. Should not be used in combination with channelKeys.
  • allowedPreviousStatuses (optional): an array of strings, i.e. the list of statuses that the objects must be in. The request will fail with a 400 Bad Request if any of the objects have a status not present in the allowedPreviousStatuses list. Cannot be used in combination with rejectedPreviousStatuses.
  • rejectedPreviousStatuses (optional): an array of strings, i.e. the list of statuses that the objects cannot be in. The request will fail with a 400 Bad Request if any of the objects have a status that is present in the rejectedPreviousStatuses list. Cannot be used in combination with allowedPreviousStatuses.
Note differentiates between the technical label and displayed label for a bookable object. Changing the former in an active event can cause problems with existing bookings. Instead change displayed label, which is always safe. To learn more, see understanding labels


204 - No Content