@wix/auto_sdk_bookings_bookings 1.0.57 → 1.0.59

package/build/cjs/index.d.ts

@@ -9,7 +9,7 @@ interface ConfirmOrDeclineBookingSignature {
      * on the `paymentStatus` you provide, double booking conflicts, and whether
      * the service requires business approval.
      *
-     * ## eCommerce checkout restriction
+     * ### eCommerce checkout restriction
      *
      * Call this method only when using a custom checkout page. Don't
      * call it when using a *Wix eCommerce checkout*
@@ -18,7 +18,7 @@ interface ConfirmOrDeclineBookingSignature {
      * the `paymentStatus` of the corresponding *Wix eCommerce order*
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/ecom/checkout/setup) | [REST](https://dev.wix.com/docs/rest/business-solutions/e-commerce/orders/introduction)).
      *
-     * ## New booking status
+     * ### New booking status
      *
      * The booking `status` is set to `DECLINED` if both of the following conditions
      * are met:
@@ -28,13 +28,13 @@ interface ConfirmOrDeclineBookingSignature {
      * If only one or none of these conditions is met, `status` is set to `PENDING`
      * or `CONFIRMED` depending on whether the service requires business approval.
      *
-     * ## Double bookings
+     * ### Double bookings
      *
      * If there is a double booking conflict, but the booking has already been at least
      * partially paid, the method still marks the booking as `PENDING` or `CONFIRMED`.
      * Then, it also sets `doubleBooked` to `true`.
      *
-     * ## Admin overwrites
+     * ### Admin overwrites
      *
      * There are small but important differences in confirmation behavior if the
      * booking was created with special `flowControlSettings`:
@@ -72,7 +72,7 @@ interface CreateBookingSignature {
      * Creates a booking.
      *
      *
-     * ## Appointment booking
+     * ### Appointment booking
      *
      * For appointment-based services, specify the relevant `slot` in
      * `bookedEntity.slot`. We recommend specifying the complete
@@ -80,7 +80,7 @@ interface CreateBookingSignature {
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/availability-calendar/query-availability) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/time-slots/availability-calendar/query-availability))
      * in your call's request to avoid failed calls due to unavailability.
      *
-     * ## Class session booking
+     * ### Class session booking
      *
      * For class services, specify the relevant event ID
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/calendar/events/introduction) | [REST](https://dev.wix.com/docs/rest/business-management/calendar/events-v3/introduction))
@@ -92,27 +92,27 @@ interface CreateBookingSignature {
      * `slot.timezone`, `slot.resource`, and `slot.location`. All manually specified
      * values are overridden.
      *
-     * ## Course booking
+     * ### Course booking
      *
      * For course services, specify the course's schedule ID in `bookedEntity.schedule.scheduleId`.
      * We recommend following [this sample flow](https://dev.wix.com/docs/rest/business-solutions/bookings/end-to-end-booking-flows#book-a-course)
      * to minimize failed calls due to unavailability.
      *
-     * ## Related resources
+     * ### Related resources
      *
      * Specifying a `resource` triggers an availability check, resulting in a failed
      * call if the resource is unavailable. Omitting a resource allows Wix Bookings
      * to assign a resource belonging to the relevant type randomly when the merchant
      * confirms the booking.
      *
-     * ## Participant information
+     * ### Participant information
      *
      * You must specify either `participantsChoices` or `totalParticipants`.
      * The call fails if the specified `participantsChoices` aren't among the supported
      * _service options and variants_
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/service-options-and-variants/introduction) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/services/service-options-and-variants/introduction)).
      *
-     * ## Notify customers
+     * ### Notify customers
      *
      * You can specify a `participantNotification.message` for the customer that's send
      * immediately. Ensure `participantNotification.notifyParticipants` is set to `true`
@@ -121,19 +121,19 @@ interface CreateBookingSignature {
      * If you specify `{"sendSmsReminder": true}`, the customer receives an SMS 24 hours
      * before the session starts. The phone number is taken from `contactDetails.phone`.
      *
-     * ## Booking status
+     * ### Booking status
      *
      * Bookings default to the `CREATED` status, not affecting the business calendar
      * or resource availability. You can specify a different status when the calling
      * [identity](https://dev.wix.com/docs/build-apps/develop-your-app/access/about-identities)
      * has `Manage Bookings` permissions.
      *
-     * ## Payment options
+     * ### Payment options
      *
      * The specified `selectedPaymentOption` indicates how the customer intends to
      * pay, allowing for later changes to a different method supported by the service.
      *
-     * ## Payment status
+     * ### Payment status
      *
      * A booking is initially created with `{"paymentStatus": "UNDEFINED"}` regardless
      * of the payment status specified in Create Booking. If a customer uses an
@@ -148,7 +148,7 @@ interface CreateBookingSignature {
      * payment status with Confirm Or Decline Booking
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/bookings/confirm-or-decline-booking) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/bookings/bookings-writer-v2/confirm-or-decline-booking)).
      *
-     * ## Booking form data
+     * ### Booking form data
      *
      * When customers sign up for a service, they must fill out the booking form.
      * To create a booking with a completed booking form, specify the relevant data in
@@ -157,7 +157,7 @@ interface CreateBookingSignature {
      * don't match, Create Booking fails. Therefore, we recommend specifying
      * only `booking.contactDetails.contactId` when providing `formSubmission`.
      *
-     * ## Admin overwrites
+     * ### Admin overwrites
      *
      * There are small but important differences when you specify special
      * `flowControlSettings`:
@@ -220,18 +220,18 @@ interface RescheduleBookingSignature {
      * a different session.
      *
      *
-     * ## Course booking limitation
+     * ### Course booking limitation
      *
      * You can't reschedule course bookings.
      *
-     * ## Appointment sessions
+     * ### Appointment sessions
      *
      * For appointments, the old session is removed from the business calendar
      * while a new session is added. We recommend calling Query Availability
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/availability-calendar/query-availability) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/time-slots/availability-calendar/query-availability))
      * first and specifying the entire retrieved `slot`.
      *
-     * ## Class sessions
+     * ### Class sessions
      *
      * For classes, the new session must be an existing session belonging to the
      * same class. We recommend retrieving `availabilityEntries.slot.eventId`
@@ -240,13 +240,13 @@ interface RescheduleBookingSignature {
      * to avoid failed Reschedule Booking calls due to unavailability. Specify
      * only `slot.eventId` instead of the entire `slot` object.
      *
-     * ## Notify customers
+     * ### Notify customers
      *
      * You can specify a `participantNotification.message` for the customer. To send
      * the message, you must also specify `participantNotification.notifyParticipants`
      * as `true`.
      *
-     * ## Admin overwrites
+     * ### Admin overwrites
      *
      * There are small but important differences when you specify special
      * `flowControlSettings`:
@@ -288,7 +288,7 @@ interface ConfirmBookingSignature {
      * Updates the booking status to `CONFIRMED` without checking whether the relevant slot or schedule is still available.
      *
      *
-     * ## eCommerce checkout restriction
+     * ### eCommerce checkout restriction
      *
      * Call this method only when using a custom checkout page. Don't
      * call it when using a Wix eCommerce checkout
@@ -297,17 +297,17 @@ interface ConfirmBookingSignature {
      * the `paymentStatus` of the corresponding Wix eCommerce order
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/ecom/checkout/setup) | [REST](https://dev.wix.com/docs/rest/business-solutions/e-commerce/orders/introduction)).
      *
-     * ## When to call Confirm Or Decline Booking instead
+     * ### When to call Confirm Or Decline Booking instead
      *
      * Confirm Booking doesn't check whether a slot or schedule is still available.
      * For these checks, call Confirm or Decline Booking ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/bookings/confirm-or-decline-booking) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/bookings/bookings-writer-v2/confirm-or-decline-booking)) instead.
      *
-     * ## Original status validation
+     * ### Original status validation
      *
      * You can only confirm bookings with a status of `PENDING`, `CREATED`, or
      * `WAITING_LIST`.
      *
-     * ## Double bookings
+     * ### Double bookings
      *
      * Confirm Booking doesn't check whether a slot or schedule is still available.
      * You can specify
@@ -326,12 +326,12 @@ interface ConfirmBookingSignature {
      * `{"checkAvailabilityValidation": false}`, the specified `doubleBooked` value
      * is ignored.
      *
-     * ## Payment status
+     * ### Payment status
      *
      * Also updates the booking's `paymentStatus`, if you specify a new payment
      * status.
      *
-     * ## Notify customers
+     * ### Notify customers
      *
      * You can specify a `participantNotification.message` for the customer. To send
      * the message, you must also specify `participantNotification.notifyParticipants`
@@ -383,7 +383,7 @@ interface DeclineBookingSignature {
      * slot or schedule is still available.
      *
      *
-     * ## eCommerce checkout restriction
+     * ### eCommerce checkout restriction
      *
      * Call this method only when using a custom checkout page. Don't
      * call it when using a Wix eCommerce checkout
@@ -392,23 +392,23 @@ interface DeclineBookingSignature {
      * the `paymentStatus` of the corresponding Wix eCommerce order
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/ecom/checkout/setup) | [REST](https://dev.wix.com/docs/rest/business-solutions/e-commerce/orders/introduction)).
      *
-     * ## When to call Confirm Or Decline Booking instead
+     * ### When to call Confirm Or Decline Booking instead
      *
      * The method doesn't check whether a slot or schedule is still available. For
      * these checks you can call Confirm or Decline Booking
      * ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/bookings/confirm-or-decline-booking) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/bookings/bookings-writer-v2/confirm-or-decline-booking)).
      *
-     * ## Original status validation
+     * ### Original status validation
      *
      * You can only decline bookings with a `status` of `PENDING`, `CREATED`, or
      * `WAITING_LIST`.
      *
-     * ## Payment status
+     * ### Payment status
      *
      * Also updates the booking's `paymentStatus`, if you specify a new payment
      * status.
      *
-     * ## Notify customers
+     * ### Notify customers
      *
      * You can specify a `participantNotification.message` for the customer. To send
      * the message, you must also specify `participantNotification.notifyParticipants`
@@ -430,24 +430,24 @@ interface CancelBookingSignature {
      * Updates the booking status to `CANCELED`.
      *
      *
-     * ## Appointments
+     * ### Appointments
      *
      * For appointments, the corresponding event is removed from the Bookings
      * calendar.
      *
-     * ## Class and course bookings
+     * ### Class and course bookings
      *
      * For class or course bookings, the relevant participants are removed
      * from the class session or the course. However, the class session or course
      * remain on the business calendar.
      *
-     * ## Notify customers
+     * ### Notify customers
      *
      * You can specify a `participantNotification.message` for the customer. To send
      * the message, you must also specify `participantNotification.notifyParticipants`
      * as `true`.
      *
-     * ## Admin overwrites
+     * ### Admin overwrites
      *
      * There are small but important differences when you specify special
      * `flowControlSettings`:
@@ -486,11 +486,11 @@ interface UpdateNumberOfParticipantsSignature {
      * the `totalNumberOfParticipants` for the relevant sessions.
      *
      *
-     * ## Appointment limitation
+     * ### Appointment limitation
      *
      * You can't update the number of participants for appointment bookings.
      *
-     * ## Participant information
+     * ### Participant information
      *
      * You must specify either `participantsChoices` or `totalParticipants`.
      * The call fails if the specified `participantsChoices` aren't among the
@@ -508,29 +508,29 @@ interface MarkBookingAsPendingSignature {
      * Updates the booking status to `PENDING`.
      *
      *
-     * ## Service requirement
+     * ### Service requirement
      *
      * By default, this method only works for services ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/services/introduction) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/services/services-v2/introduction)) with `service.onlineBooking.requireManualApproval` set to `true`.
      * If you attempt to mark a booking as pending for a service that doesn't require approval, the call fails unless you use the `skipPendingApprovalServiceValidation` admin overwrite.
      *
-     * ## Status requirements
+     * ### Status requirements
      *
      * - __Original status__: Booking must have `CREATED` status.
      * - __Target status__: Booking moves to `PENDING`.
      *
-     * ## Checkout restrictions
+     * ### Checkout restrictions
      *
      * Only call this method if the customer paid via a custom checkout. For Wix eCommerce checkouts ([SDK](https://dev.wix.com/docs/sdk/backend-modules/ecom/checkout/introduction) | [REST](https://dev.wix.com/docs/rest/business-solutions/e-commerce/purchase-flow/checkout/introduction)), Wix Bookings automatically manages the bookings' statuses based on payment processing.
      *
      * When using custom checkouts, you can also update the booking's `paymentStatus` by specifying a new payment status.
      *
-     * ## Business workflow
+     * ### Business workflow
      *
      * After marking a booking as `PENDING`, the business must manually approve or reject it. You can call these methods:
      * - Confirm Booking ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/bookings/confirm-booking) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/bookings/bookings-writer-v2/confirm-booking)).
      * - Decline Booking ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/bookings/decline-booking) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/bookings/bookings-writer-v2/decline-booking)).
      *
-     * ## Resource availability and scheduling
+     * ### Resource availability and scheduling
      *
      * Marking a booking as `PENDING` immediately affects resource availability:
      *
@@ -538,16 +538,16 @@ interface MarkBookingAsPendingSignature {
      * - **Availability**: The time slot becomes unavailable for other bookings, even while pending approval.
      * - **Resource assignment**: Available resources ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/resources/introduction) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/resources/resources-v2/introduction)) are automatically assigned if none were explicitly selected during booking creation.
      *
-     * ## Double bookings
+     * ### Double bookings
      *
      * By default, the method doesn't check for availability conflicts. To detect and handle double bookings, use the `checkAvailabilityValidation: true` admin overwrite.
      *
-     * ## Notify customers
+     * ### Notify customers
      *
      * You can specify a `participantNotification.message` for the customer.
      * To send the message, you must also specify `participantNotification.notifyParticipants` as `true`.
      *
-     * ## Admin overwrites
+     * ### Admin overwrites
      *
      * There are small but important differences when you specify special
      * `flowControlSettings`:
@@ -582,11 +582,11 @@ interface CreateMultiServiceBookingSignature {
      * Creates a multi-service booking and all included single-service bookings simultaneously.
      *
      *
-     * ## When to call this method
+     * ### When to call this method
      *
      * Create sequential appointments where customers book related services together. For adding existing single-service bookings to an existing multi-service booking, call Add Bookings to Multi Service Booking ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/bookings-writer-v2/add-bookings-to-multi-service-booking) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/bookings/bookings-writer-v2/add-bookings-to-multi-service-booking)) instead.
      *
-     * ## Requirements and behavior
+     * ### Requirements and behavior
      *
      * __Package constraints__: Multi-service bookings support 2-8 appointment-based single-service bookings only (course and class bookings aren't supported). All single-service bookings must be at the same location with sequential scheduling and no gaps between appointments.
      *
@@ -596,7 +596,7 @@ interface CreateMultiServiceBookingSignature {
      *
      * __Package notifications__: Customers receive 1 unified notification for the entire multi-service booking. Wix Bookings doesn't send notifications for the package's individual single-service bookings.
      *
-     * ## Related methods
+     * ### Related methods
      *
      * Verify availability first with List Multi Service Availability Time Slots ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/time-slots/multi-service-availability-time-slots/list-multi-service-availability-time-slots) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/time-slots/time-slots-v2/list-multi-service-availability-time-slots)).
      *
@@ -675,17 +675,17 @@ interface MarkMultiServiceBookingAsPendingSignature {
      *
      * Call this method for multi-service bookings requiring manual business approval before confirmation.
      *
-     * ## Status requirements
+     * ### Status requirements
      *
      * - __Original status__: All single-service bookings must have `CREATED` status.
      * - __Target status__: All bookings move to `PENDING` together (all-or-nothing operation).
      *
-     * ## Checkout restrictions
+     * ### Checkout restrictions
      *
      * Only call this method if the customer paid via a custom checkout. For Wix eCommerce checkouts,
      * Wix Bookings automatically manages the bookings' statuses based on payment processing.
      *
-     * ## Additional updates
+     * ### Additional updates
      *
      * - __Payment status__: Updates if you specify a new `markAsPendingBookingsInfo.paymentStatus`.
      * - __Customer notifications__: Send messages using `participantNotification`.
@@ -706,17 +706,17 @@ interface ConfirmMultiServiceBookingSignature {
      *
      * Call this method for multi-service bookings requiring manual business approval.
      *
-     * ## Status requirements
+     * ### Status requirements
      *
      * - __Original status__: All single-service bookings must have `PENDING`, `CREATED`, or `WAITING_LIST` status.
      * - __Target status__: All bookings move to `CONFIRMED` together (all-or-nothing operation).
      *
-     * ## Checkout restrictions
+     * ### Checkout restrictions
      *
      * Only call this method if the customer paid via a custom checkout. For Wix eCommerce checkouts,
      * Wix Bookings automatically manages the bookings' statuses based on payment processing.
      *
-     * ## Additional updates
+     * ### Additional updates
      *
      * - __Payment status__: Updates if you specify a new `confirmBookingsInfo.paymentStatus`.
      * - __Customer notifications__: Send messages using `participantNotification`.
@@ -737,17 +737,17 @@ interface DeclineMultiServiceBookingSignature {
      *
      * Call this method to reject multi-service bookings that can't be accommodated or don't meet business requirements.
      *
-     * ## Status requirements
+     * ### Status requirements
      *
      * - __Original status__: All single-service bookings must have `PENDING`, `CREATED`, or `WAITING_LIST` status.
      * - __Target status__: All bookings move to `DECLINED` together (all-or-nothing operation).
      *
-     * ## Checkout restrictions
+     * ### Checkout restrictions
      *
      * Only call this method if the customer paid via a custom checkout. For Wix eCommerce checkouts,
      * Wix Bookings automatically manages the bookings' statuses based on payment processing.
      *
-     * ## Additional updates
+     * ### Additional updates
      *
      * - __Payment status__: Updates if you specify a new `declineBookingsInfo.paymentStatus`.
      * - __Customer notifications__: Send messages using `participantNotification`.
@@ -805,16 +805,16 @@ interface AddBookingsToMultiServiceBookingSignature {
      * Expands an existing multi-service booking by adding existing single-service bookings to the package.
      *
      *
-     * ## When to call this method
+     * ### When to call this method
      *
      * Call this method to add 1 or more existing single-service bookings to an existing multi-service booking.
      * For creating a new multi-service booking with new single-service bookings, call Create Multi Service Booking ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/bookings/create-multi-service-booking) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/bookings/bookings-writer-v2/create-multi-service-booking)) instead.
      *
-     * ## Package integration
+     * ### Package integration
      *
      * The timing of the single-service bookings to add must be compatible with the multi-service booking's sequential schedule to ensure no gaps or overlaps between services in the updated package.
      *
-     * ## Requirements and limitations
+     * ### Requirements and limitations
      *
      * - __Maximum capacity__: The total number of single-service bookings can't exceed 8.
      * - __Booking eligibility__: You can add only independent single-service bookings that aren't part of another multi-service booking.
@@ -832,7 +832,7 @@ interface RemoveBookingsFromMultiServiceBookingSignature {
      * Removes single-service bookings from a multi-service booking and converts them to independent single-service bookings.
      *
      *
-     * ## Removal options
+     * ### Removal options
      *
      * __Remove all permitted bookings__: If you specify an empty `bookings` array, all single-service bookings for which the call's [identity](https://dev.wix.com/docs/build-apps/develop-your-app/access/about-identities) has read permissions are removed from the multi-service booking.
      *
@@ -840,7 +840,7 @@ interface RemoveBookingsFromMultiServiceBookingSignature {
      *
      * __Sequential scheduling__: To maintain sequential scheduling, remove only first or last single-service bookings. For middle bookings, first reschedule all relevant single-service bookings to eliminate gaps. To do so, call Reschedule Multi Service Booking ([SDK](https://dev.wix.com/docs/sdk/backend-modules/bookings/bookings/reschedule-multi-service-booking) | [REST](https://dev.wix.com/docs/rest/business-solutions/bookings/bookings/bookings-writer-v2/reschedule-multi-service-booking)) before removing the unwanted bookings.
      *
-     * ## Removal behavior
+     * ### Removal behavior
      *
      * __Independent bookings__: Removed single-service bookings become independent bookings.
      * You can manage them using single-service booking methods.