Query Availability

Retrieves the availability for sessions that match the provided query criteria (filtering and sorting).

The Calendar Availability APIs calculate the availability of sessions for appointments and classes, but not for courses.

The entire list of slots is returned in case you want to display both available and non-available slots in the calendar for your customers. Using the bookable property, you can limit the display to available slots only.

When querying, you must enter a start date and an end date. This avoids very large results that can impact performance.

Calculating availability

The availability is determined by checking:

• The sessions' open slots. A slot is considered open if the session's capacity is greater than number of participants.
• Booking policies. Policies that affect whether a slot is considered available include tooEarlyToBook, tooLateToBook, and bookOnlineDisabled.

Locked sessions do not impact session availability and bookable can be true even if locked is true. For example, if a session has a waitlist and a place frees up, the slot is offered to the customers on the waitlist, one by one. The session remains locked because there is still a wait-list, but for a period of time there is availability, until a customer on the waitlist takes the slot. Locking prevents customers who are not yet on the wait-list from grabbing the slot.

Handling Daylight Savings Time (DST) for local time zones

Because of DST, there are cases where certain times either do not exist or exist twice for a local time zone. For example, the time 00:05 on September 5th 2021 might not exist in Santiago, Chile, because at 00:00 the clock moved 1 hour forward to 01:00.

In this case, the Availability APIs take this into account and mediate the time gaps automatically. The non-existent local time is automatically moved forward 1 hour to match local DST. Local times that exist do not change. So if the Query Availability endpoint is called with a startDate of 2021-09-05T00:00:01.000 and an endDate of 2021-09-06T00:00:02.000, 2021-09-05T01:00:01.000 is used in the query instead. The start time shifts one hour forward and the end time remains the same.