Availability Calendar: Migration Guide

This guide helps you migrate from Availability Calendar to the current Time Slots V2 API. Availability Calendar will be removed on March 31, 2026.

Overview

The Availability Calendar API provided a single method to retrieve appointment slot and class event availability information. This functionality has been redesigned and enhanced in the Time Slots V2 API with improved performance, better filtering capabilities, and support for multi-service bookings.

The Time Slots V2 API provides separate methods for:

  • Appointment availability: Retrieve availability for appointment-based services with enhanced filtering and capacity information.
  • Class availability: Retrieve availability for class sessions with improved capacity and waitlist handling.
  • Multi-service bookings: New capability for sequential multi-service bookings.

Key changes

  • Enhanced filtering: More precise filtering options with better performance and clearer parameter names.
  • Improved capacity handling: Better support for waitlists, booking capacity, and participant limits.
  • Clearer response structure: More detailed time slot information including policy violations and booking restrictions.
  • Better error handling: More specific error codes and clearer error messages.

API reference mapping

Availability CalendarTime Slots V2
Query Availability (appointments)List Availability Time Slots
Query Availability (classes)List Event Time Slots
N/A (new capability)List Multi Service Availability Time Slots

Time Slots V2 also provides Get methods to confirm availability immediately before calling Create Booking, helping you avoid double-booking conflicts.

Migration steps

To migrate your code, follow these steps:

  1. Update imports and URLs: Replace the JavaScript import statements or API call URLs in your code.

  2. Migrate appointment availability: Replace Query Availability calls for appointments with List Availability Time Slots:

    • Change startDate/endDate to fromLocalDate/toLocalDate with local time format.
    • Update filter structure to use the new filtering options.
    • Handle the enhanced response structure with additional capacity and policy information.

  3. Migrate class availability: Replace Query Availability calls for classes with List Event Time Slots:

    • Use serviceIds array instead of single serviceId.
    • Update date parameters to local time format.
    • Handle the new event-specific response structure.

  4. Leverage new capabilities: Consider using List Multi Service Availability Time Slots for sequential multi-service bookings if applicable to your use case.

  5. Add availability confirmation: Use the appropriate Get method (Get Availability Time Slot, Get Event Time Slot, or Get Multi Service Availability Time Slot) just before creating each booking to avoid conflicts.

  6. Test and validate: Run both APIs in parallel during migration to ensure feature parity and correct data handling.

For complete step-by-step implementation examples, you can follow the end-to-end booking flows.

Did this help?