Seasons

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.

Renderer

To render a season, just pass in the season key as event (since a season is an event):

new seatsio.SeatingChart({
    divId: 'chart',
    workspaceKey: 'aWorkspaceKey',
    event: 'aSeasonKey'
}).render();

Event manager

Just like when rendering a season, you can pass in the season key event to the event manager:

new seatsio.EventManager({
    divId: 'chart',
    secretKey: 'aWorkspaceSecretKey',
    event: 'aSeasonKey',
    mode: 'manageForSaleConfig' // or any other mode
}).render();

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.

Areas

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.

Channels

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.

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.

	Seasons	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.