Seasons are groups of events, in which objects can be booked with a single operation.
A typical use case are season tickets in sports. If someone books seat A-1 for the season, it's booked in all events in the season.
Seasons behave like events. Meaning: all API calls that take an event key also work with a season key.
So to book places for the season, you use the same calls as for regular events.
The same goes for rendering a chart (and for the event manager): pass in the season key to render for the season.
To render a season, just pass in the season key as
event (since a season is an event):
Just like when rendering a season, you can pass in the season key
event to the event manager:
mode: 'manageForSaleConfig' // or any other mode
Changing object status
Regular objects (e.g. seats)
If you book an object in the season, it's made unavailable for selection in all events in the season.
Vice-versa, an object is not available at the season level when it's booked in at least one event.
For areas, the number of booked places for the season determines how many places are left in the events. If the area has a capacity of 50 and 35 places are booked for the season, 15 places are left for selection in the events of the season.
Booked places in events limit the number of available places on the season. E.g.:
- event A: 5 places booked in area
- event B: 12 places booked in area
- event C: 18 places booked in area
For an area with a capacity of 50, this leaves 32 places for selection on the season (which is 50 - 18, the highest number of bookings for an event)
Not for sale
Objects can be marked as not for sale for the season, or in individual events. If an object is not for sale for the season, it's unavailable in all events in the season.
If it's not for sale in at least one event, it's unavailable for the season as well (but still available in other events in the season).
You can only mark objects as "not for sale" - marking them as "for sale" is not supported on seasons or events in seasons.
Objects can be assigned to a channel in the season, or in an event. The list of channels is managed at the season level.
Events inherit channel assignments from the season. If seat A-1 is in channel VIP for the season, it's also in this channel for all events.
It doesn't work like that the other way around: when A-1 is in channel VIP in an event (or in multiple events), it's just unavailable for selection in the season - the season doesn't see A-1 as having been assigned channel VIP.
A social distancing ruleset can only be assigned to the season, not to events in the season. All events use the same ruleset as the season.
Seasons vs. event groups
Event groups seem to offer similar functionality as seasons. So which one should you use?
In most cases, you'll want to go for seasons. They offer much richer functionality (e.g. best available, channels) and support a larger number of events.
Event groups are very flexible though. You can decide per rendering and per API call which events make up the group. So if you want to let people choose 5 random events out of a set of 50, you should use event groups.
|Changing object status||✓||✓|
|Not for sale||✓||✓|
|Best available||✓||✗||Not supported for event groups|
|Channels||✓||✗||Not supported for event groups|
|Adding events||✓||✗||No easy way to transfer season bookings to new events in event groups|
|Many events (20+)||✓||✗||Status change calls in event groups get slow with many events|
|Creating on the fly||✗||✓||Event groups can be different per rendering and per status change call|
Used seats - billing
If a place is booked for the season, it counts as used on all events in the season and on the season itself.
So if the season consists of 5 events, booking A-1 leads to 6 (= 5 + 1) used seats for billing purposes.