Overview
Availability is at the core of all things OnSched, where the available time slots that are eventually booked are first driven. Availability is based on a number of different parameters that control its outcome, some are required, others are optional.
In order for an appointment to be booked it requires three basic parameters, the Who, the What, and the Where. In OnSched's terminology these first three parameters would translate to the following:
Who: The ID of the Resource that the appointment is being booked with
What: The ID of the Service being booked
Where: The ID of the Location where the appointment is being booked
The When is what we have left, which is determined using the Availability response.
What's required
In order for availability to be checked, the Service, the Resource and the Location must be determined.
The Service, however, is the only parameter that is required to calculate Availability. The Location, if unspecified, will default to the Primary Location and the Resource can be determined at random if unspecified using the Round Robin setting.
For more information on what's required see Required Availability Parameters.
What to expect
When called, Availability will return an object with all parameters that were passed in, in addition to two new arrays, availableDays and availableTimes. The availableDays array may be used to differentiate between the days on a calendar which are OPEN, and those that are CLOSED.
The availableDays array will only return a day as unavailable if the Location is CLOSED, this will not take into account days that are fully booked.
The availableTimes array contains all of the available time slots to display to the user. The time slot objects contain required parameters to pass along to Appointments in order to complete a booking.
The following is an example of the response from calling the Availability endpoint in our API. To see how this response is used to book an appointment, visit Appointment Booking .
{
"url":"string"
"object":"string"
"businessName":"string"
"locationId":"string"
"serviceId":"string"
"serviceName":"string"
"serviceDescription":"string"
"serviceDuration":0
"startDate":"string"
"endDate":"string"
"resourceId":"string"
"resourceIds":"string"
"resourceName":"string"
"resourceDescription":"string"
"calendarId":"string"
"calendarResourceGroupId":"string"
"tzRequested":0
"firstAvailableDate":"string"
"availableDays":[
{
available: false
bookingCount: 0
bookingLimit: 0
closed: false
date: "2021-05-30"
object: "availableDay"
reason: "Date in past"
reasonCode: 500
}
...
]
"availableTimes":[
{
allowableBookings: 0
allowableCapacity: 0
availableBookings: 0
availableCapacity: 0
date: "2021-07-01"
displayTime: "11:00 AM"
duration: 0
endDateTime: "2021-07-01T11:30:00-04:00"
resourceId: "27107"
startDateTime: "2021-07-01T11:00:00-04:00"
time: 1100
travelAppointmentId: ""
travelTimeMins: 0
}
...
]
}
How it's calculated
Availability is factored by checking four layers of availability before returning the results. If a time slot fits within all of these boundaries it is returned in the availableTimes array as described above. The layers of availability are:
- Business Location
- Calendar
- Resource(s)
- Service
Below is a breakdown of each layer and the actions that may affect the availability results, click on any action for more information.
Availability Layers | Actions Checked |
---|---|
Location | Business Hours, Public Holidays, Book Ahead / In Advance Restrictions |
Calendar | Weekly Calendar Availability, Calendar Blocks, Recurring Calendar Blocks |
Resource | Weekly Resource Availability, Resource Blocks, Recurring Resource Blocks, 2-Way-Sync Calendar Blocks (if applicable) |
Service | Weekly Service Availability, Service Blocks, Recurring Service Blocks |
Updated over 2 years ago