Architecture and data flow

The Wix Bookings product/platform is comprised of multiple interconnected components. Together, these components enable sophisticated booking flows for customers, as well as powerful management capabilities for business owners. This architecture provides flexibility and adaptability, allowing you to extend, customize, or replace elements of the product in accordance with your specific needs.

The following are Wix Bookings’ main components and available customizations.

Services

The services API manages each business's offerings and all the information that customers need when deciding whether to book. Service booking policies manage the customers ability to book under time constraints, limit the maximum number of participants, ability to cancel and reschedule, and more.

Customizations:

• Set a variable per service that you can then use to offer different pricing based on the variable settings, with the Service Options and Variants API.
• In the UI, you can add:
  • site plugins to service pages.
  • dashboard plugins to staff pages.
  • dashboard plugins to booking list pages.

Time slots

Wix Bookings enables site contributors to decide exactly when customers can book services of all types, and verifies which time slots are available at any given time based on all relevant factors:

• For classes, Wix Bookings determines available time slots based on the class schedule, capacity, and any service policies that have been set, including whether waiting list functionality has been applied to this class.
• For courses, Wix bookings determines availability based on the course’s capacity and any service policies that have been set.
• For appointments, Wix Bookings determines available time slots based on:
  • session duration,
  • staff member and resource working hours and blocked time,
  • time buffers,
  • service policies.

Wix Bookings validates all these factors at multiple points in the booking flow:

• When displaying a service’s available time slots to customers.
• Before creating the booking (before payment is made).
• Before confirming the booking (after payment is made).

Bookings

Once a customer has selected one or more services and specific time slots for them, and provided the information requested in the booking form, a booking is created and the customer enters Wix eCommerce’s checkout flow. Under the hood, everything stored in the booking object is automatically mapped to Wix eCommerce’s Catalog service plugin for a seamless checkout experience. Once the customer has completed the checkout, the booking is confirmed.

Customizations:

• Manage the price of a booking externally with the Pricing Integration service plugin. Wix will call the integration whenever a customer enters the booking flow to get the price to be charged.
• Manage customer attendance with the Attendance API.

Calendar

Once the booking is confirmed, it is added to the business’s booking calendar and to the schedules of the relevant staff members, rooms, etc. The business’s booking calendar provides an up-to-date calendar view of the business. This view is used in the business’ daily operation, and is critical for managing and validating available time slots. The calendar can be filtered by service and by staff, to view working hours per staff, and so on.

Notifications

Notifications play a vital role in keeping both site contributors and customers up-to-date. This feature sends alerts to site contributors when specific events take place, such as new bookings, reschedulings, and cancellations. It also sends alerts to customers when specific events take place, like automatic reminders before a booking begins, and changes to their booking.

Customizations:
Apps can provide pre-installed automations that trigger notifications (or other actions) when specific conditions are met.

Standard booking flow

The primary customer-facing flow in Wix Bookings is the single-service bookings flow. The following diagram describes this flow:

1. When the customer views the site’s list of services, the client calls Query Services and displays all available services.
2. When the customer selects a specific service to view, the client:
   1. Calls Get Service (optional).
   2. Checks availability:
      • For appointments and classes: Calls Query Availability.
      • For courses: Checks the requested number of participants against the capacity (defaultCapacity in the Query Services or Get Service response).
   3. Displays details of the specific service and available time slots.
3. When the customer selects a time slot to book, the client displays a booking form, based on the Query Services (or Get Service) response.
4. Customer fills out the booking form.
5. When the customer clicks “book now”:
   1. The client calls Query Availability again to validate that the time slot is still available.
   2. Then the client calls Create Booking to create a booking for the customer.
   3. If a site contributor configured manual approval for this service, they will receive a notification requesting review and approval (limited to free or offline payments).
6. If online payment is required: the client leads the customer to the eCom checkout flow. If a Pricing integration is implemented, Wix calls the implementer to calculate the price to charge.
7. If the session is free or takes offline payments: the client skips checkout entirely.
8. When the customer has completed the eCom checkout flow (or when the session is free or the customer is paying offline), an Order Approved webhook is triggered.
9. Once the order is approved, Wix Bookings calls Confirm Or Decline Booking which triggers the following logic:
   1. If manual confirmation is enabled, Wix Bookings calls the internal Mark Booking as Pending endpoint to mark the booking as pending, and sends a notification to the site contributors to manually confirm the booking. When a site contributor confirms the booking, Wix Bookings calls the internal Confirm Booking endpoint to mark the booking as confirmed.
   2. If this booking causes an overbooking:
      • If payment was made: Wix Bookings calls the internal Confirm Booking endpoint and a notification about the overbooking will be sent to the site contributors.
      • If no payment was made: Wix Bookings calls Decline Booking.
   3. In all other cases, Wix Bookings calls the internal Confirm Booking endpoint to mark the booking as confirmed.

Once the booking is confirmed:

• A session is added to the business’s booking calendar, and to the schedules of any affected staff and resources.
• Any notifications that have been set up are triggered.
• Any automations set to be triggered by a session being booked are triggered, and any automations set to be triggered around a session start and session end are scheduled.
• The customer can view and manage their booking (cancel, reschedule, etc.) in the site’s members area.
• The site contributors can view and manage bookings in the site dashboard’s booking calendar.