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)

Events in the past

As noted above, existing bookings have an impact on future booking behaviour within a season, e.g. booking an object on a single event means that object is no longer eligible to be booked at the season level. This may result in undesirable situations wherein you lose the benefits of seasons because of a single event. To prevent this, it is possible to mark events as in the past (see Update an event).

For a season with 4 events, an object in event 1 is booked for that specific event. An attempt to then book that object on the season level will fail. If event 1 has already happened, once that specific event is marked as in the past it will then be possible to book the object on the season level.

Once an event has been marked as in the past, this change cannot be reverted. It will also not be possible to make changes to the event if it is in the past.

> Create seasonA with event1, event2, event3, event4
 > OK

// Failing scenario
POST https://api-{region}.seatsio.net/events/event1/actions/book for object A1
 > OK
POST https://api-{region}.seatsio.net/events/seasonA/actions/book for object A1
 > Bad request, A1 is not available for season-level booking

// Successful scenario
POST https://api-{region}.seatsio.net/events/event1/actions/book for object A1
 > OK
POST https://api-{region}.seatsio.net/events/event1 {"eventKey": "event1", "isInThePast": true}
 > OK
POST https://api-{region}.seatsio.net/events/seasonA/actions/book for object A1
 > OK, A1 is now booked on the season level

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 use the mark-as-not-for-sale endpoint for seasons. mark-as-for-sale is not supported.

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