allowFreesale
is set to true on the product then this step is optional but it is advised you check it anyway if you can to check for closures.POST /availability/calendar
this endpoint is highly optimised and will return a single object per day. It's designed to be queried for large date ranges and the result is used to populate an availability calendar.POST /availability
this endpoint is slightly slower as it will return an object for each individual departure time (or day). You have to perform this step to retrieve an availabilityId
in order to confirm a sale, so if you just want to use this endpoint and skip the calendar endpoint then that's perfectly ok.localDateStart
and localDateEnd
. Each object is defined as:localDate
status
AVAILABLE
There are availabilities available on this date for sale.SOLD_OUT
This date was available but is now fully sold out.LIMITED
This date is available but has less than 50% capacity left.CLOSED
This date is closed and not available for sale.available
status == 'AVAILABLE' || status == 'LIMITED'
capacity
openingHours
openingHours[].from
openingHours[].to
id
localDateTimeStart
localDateTimeEnd
allDay
status
AVAILABLE
This availability is available for saleFREESALE
This availability has no capacity and is available.SOLD_OUT
This availability is notLIMITED
This availability is available but has less than 50% capacity left.product.availabilityType
the response will keep the same structure but will generally look slightly different. We've provided examples of that below:OPENING_HOURS
availability type:START_TIME
availability type:2020-07-01
then they must then pick a departure time. Again in this example the departure times would be: