Migrating to Booking Availability API V2

Read this if you're using our V1 API to fetch Booking Availability of Round Robin Meeting types.

Richard Gödel avatar
Written by Richard Gödel
Updated over a week ago

Previously, the booking information API GET /booking/team/:teamSlug/:meetingTypeSlug would fetch all hosts from the "team," and those hostIds were used to fetch availability of the meeting type using the GET /booking-availability API.

However, it was later expanded to accommodate additional scenarios where a host could be part of the team but not included in the round robin rotation. As a result, the booking availability API was enhanced to generate timeslots based on the appropriate hosts.

Similarly, the queueId from the booking information API is utilized in the GET /booking-availability API to generate slots based on hosts in the round robin or common availability.

Changelog

  • GET /booking/team/:teamSlug/:meetingTypeSlug -> GET /booking/v2/team/:teamSlug/:meetingTypeSlug

v2 API will now fetch availability of hosts in round robin instead of all hosts in team

  • GET /booking-availability -> GET /booking-availability/v2

Added queueId query parameter to fetch availability based on hosts in round robin

Migration guide

  1. Fetch hostIds and queueId from team meeting type information using GET /booking/v2/team/:teamSlug/:meetingTypeSlug API

  2. Use hostIds and queueId to fetch booking availability of hosts in round robin using GET /booking-availability/v2 API for team meeting type booking page

  3. When queueId is not provided, GET /booking-availability/v2 API will fetch common availability of all hosts specified in hostIds query parameter (used on rescheduling appointment when fetching availability for multiple hosts)

Did this answer your question?