Get to know our frameworks

Select an app template built on your preferred framework.

Build apps on our native app editor. Use drag and drop elements, Velo code and Wix APIs to develop custom features.

Streamline your app development process with the Wix CLI. Get a familiar developer experience with minimal setup and configuration.

Take full control over your app's tech stack, deployment, and hosting.

App templates

Wix Blocks templates

Wix CLI templates

Self-hosted templates

Kickstart your app development with templates built on your preferred Wix developer tool. Browse templates for practical foundation and get to know the Wix ecosystem.

Wix App Templates for Developers

This example apps can be used as a starting point for building your own app, for concrete examples of how to use Wix framework, or for inspiration.

Choose a template.<0 />Build an app.

Browse by:

How to build it step by step:

This template is built with:

Read how this template was built, step by step.

How we built this template

Deployment instructions:

Choose a package manager and run the command in your terminal.

Copy command

Before you get started, make sure you have the following:

Prerequisite steps

Get started with Wix CLI

Begin by setting up your Next.js project with your preferred hosting platform.

Select your hosting service

Start the deployment flow and set up your template repo on Netlify. After you finish set up, come back here and add your Netlify custom domain.

Copy the code from our Git repo to deploy your app on any platform that supports Next.js.

Start the deployment flow and set up your template repo on Vercel. After you finish set up, come back here and add your Vercel generated URL.

Add the base URL and give your app a name.

App details

Go to the app dashboard and test your app to ensure a smooth integration within the Wix ecosystem. <0>Learn more about app checks and testing</0>

Define your environment

Terminal

Related templates

Note

Warning

Your app name will be used as the namespace suffix.

Name your app to generate a namespace. This lets you refer to your app in code later on.

Go Headless

Build Apps

Client

API Preview

Ricos

Develop Websites

REST

Velo

GraphQL (Alpha)

# About the Booking Policy Snapshots API

A booking policy snapshot is a saved version of a service's booking policy at the time a
[booking](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/about-wix-bookings) is created.
This is important because a policy may change after a customer books the service,
and having a snapshot preserves the original terms.

The Booking Policy Snapshots API allows you to retrieve policy snapshots.

For managing cancellation fees, you may also want to explore the
[Booking Fees API](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/booking-fees/introduction).

## Before You Begin

It’s important to note the following points before starting to code:

- Every booking with corresponding [eCommerce order](fallback::https://dev.wix.com/docs/rest/business-solutions/e-commerce/orders/introduction)
  has exactly one policy snapshot. Bookings without a related eCommerce order don't have
  a policy snapshot.
- You can't create a booking policy snapshot using this service, you can only
  retrieve policy snapshots. However, you could use
  [Get Policy](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/services/booking-policy/get-booking-policy)
  to retrieve a service's booking policy just before or after creating a
  booking.

## Use Cases

- [Notify business owners of bookings under outdated policy](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/services/booking-policy-snapshots/sample-flows#notify-business-owners-of-bookings-under-outdated-policy).

## Terminology

- **Booking policy**: Rules set by the business owner regarding the booking and
  cancellation of a service. Policies may include advance booking restrictions,
  cancellation deadlines, associated fees, and the maximum number of participants
  allowed.
- **Booking policy snapshot**: The version of a service's booking policy saved
  at the time a booking is created. Snapshots preserve the original terms, which
  is useful if policies change after a booking is made.

For a comprehensive glossary of Wix Bookings terms, see
[Terminology](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/terminology).

# Booking Policy Snapshots API: Sample Use Cases and Flows

This article shares some possible use cases your app could support,
as well as a sample flow that could support each use case.
This can be a helpful jumping off point as you plan your app's implementation.

## Notify business owners of bookings under outdated policy

Your app could give business owners an overview of all bookings made under an
older version of a service policy.

To display a list of bookings with outdated booking policy:

1. Listen to [Booking Policy Updated](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/services/booking-policy/booking-policy-updated).
1. Retrieve all services that are using the affected policy with
   [Query Services](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/services/services-v2/query-services).
   Make sure to pass the relevant policy ID from the previous step as filter.
1. Use [Query Extended Bookings](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/bookings-and-time-slots/bookings-v2/bookings-reader-v2/query-extended-bookings).
   For appointment-based service include `bookedEntity.item.slot.serviceId` in
   the filter. For classes or courses include `bookedEntity.item.schedule.serviceId`
   in the filter. You may use a conditional `or` for both filter options in a
   single call.
1. Retrieve the policy snapshots for the affected bookings with
   [List Policy Snapshots By Booking Ids](fallback::https://dev.wix.com/docs/rest/business-solutions/bookings/services/booking-policy-snapshots/booking-policy-snapshot-object).
1. Create a summary of these bookings, highlighting the policy changes for each booking.
1. Send the summary to the business owners.

`BookingPolicy` is the main entity of `BookingPolicyService` and specifies a set of rules for booking a service
by visitors and members.

Each `BookingPolicy` consists of a number of sub-policies. When the Bookings App is provisioned to a meta site then a
default `BookingPolicy` will be created with defaults for each of these sub-policies. This also applies when a request
is received to create a new `BookingPolicy` and one or more of these sub-policies are not provided.

Sub-policies are defined in separate objects as specified below.
- The `CancellationPolicy` object defines the policy for canceling a booked session.
- The `ReschedulePolicy` object defines the policy for rescheduling booked session.

By default each sub-policy is disabled. A more detailed specification of the default settings of each sub-policy
can be found in the description of the corresponding object.

Partial updates are supported on the main entity level, however in order to update a sub-policy the client needs to provide the whole sub-policy object.

Date and time the booking policy was created.

createdDate

Custom description for the booking policy and whether the booking policy is displayed to the participant.

Whether the booking policy is the default.

default

name

Revision number, which increments by 1 each time the booking policy is updated. To prevent conflicting changes, the current `revision` must be passed when updating the booking policy.

revision

Date and time the booking policy was updated.

updatedDate

BookingPolicy

The `bookingPolicySnapshot` object is the version of a service's booking policy
at the time a booking is created. This allows you for example to charge
customers the correct cancellation fee even after a service's cancellation
policy has been updated.

ID of the booking that's associated with this policy snapshot.

bookingId

Date and time the booking policy snapshot was created in `YYYY-MM-DDThh:mm:ssZ` format.

Snapshot of the [booking policy](https://dev.wix.com/docs/rest/business-solutions/bookings/services/booking-policy/booking-policy-object).
at the time the corresponding booking was created.

BookingPolicySnapshot

Whether Wix automatically charges the cancellation fee from the customer once
they cancel their booking.

Default: true

autoCollectFeeEnabled

Time windows relative to the session start during which customers can cancel
their booking. Each window includes details about the fee for canceling
within it.

cancellationWindows

Whether customers must pay a cancellation fee when canceling a booking.

Default: `false`

enabled

CancellationFeePolicy

Start of the cancellation window in minutes before the session start. For
courses, this refers to the start of the first course session.

startInMinutes

CancellationWindow

Fixed amount customers must pay when canceling the booking within this window.

Percentage of the booking price customers must pay when canceling within this window.

Min: `0.01` percent
Max: `100` percent

percentage

Whether customers can cancel the booking. `true` means customers can cancel
the booking.

Default: `false`

Minimum number of minutes before the start of the session customers can cancel.
For courses, this refers to the start of the first course session.

Default: `1440` minutes (1 day)
Min: `1` minute

latestCancellationInMinutes

Whether there's a limit on the latest cancellation time. `false` means
customers can cancel the booking until the last minute before the course or
session starts.

Default: `false`

limitLatestCancellation

CancellationPolicy

List of booking IDs to retrieve policy snapshots for.

bookingIds

ListPolicySnapshotsByBookingIdsRequest

bookingPolicySnapshots

ListPolicySnapshotsByBookingIdsResponse

A description of the booking policy to display to participants.

Description of the booking policy.

Default: Empty
Max length: 2500 characters

description

Description of the translated booking policy.

Default: Empty
Max length: 2500 characters

descriptionTranslated

Whether the description is displayed to the participant. `true` means the
description is displayed.

Default: `false`

PolicyDescription

The rule for rescheduling a booked session.

Whether customers can reschedule a booking for an appointment-based service.
`true` means customers can reschedule.

Default: `false`

Minimum number of minutes before the session start session customers can
reschedule their booking.

Default: `1440` minutes (1 day)
Min: `1` minute

latestRescheduleInMinutes

Whether there's a limit on the latest supported rescheduling time. `false`
means customers can reschedule until the last minute before the session start.

Default: `false`

limitLatestReschedule

ReschedulePolicy

Whether Wix stores credit card details of the customer. Storing the details
allows Wix to prefill the checkout and thus increases the likelyhood that the
customer completes the booking process.

Default: `false`

SaveCreditCardPolicy

Money.
Default format to use. Sufficiently compliant with majority of standards: w3c, ISO 4217, ISO 20022, ISO 8583:2003.

Currency code. Must be valid ISO 4217 currency code (e.g., USD).

currency

Monetary amount. Decimal string in local format (e.g., 1 000,30). Optionally, a single (-), to indicate that the amount is negative.

formattedValue

Monetary amount. Decimal string with a period as a decimal separator (e.g., 3.99). Optionally, a single (-), to indicate that the amount is negative.

value

Money

BoolValue

Empty

Int32Value

Int64Value

values

ListValue

NullValue

StringValue

fields

Struct

nanos

seconds

Timestamp

Value

boolValue

listValue

nullValue

numberValue

stringValue

structValue

kind

bodyAsJson

ActionEvent

A sequence number defining the order of updates to the underlying entity.
For example, given that some entity was updated at 16:00 and than again at 16:01,
it is guaranteed that the sequence number of the second update is strictly higher than the first.
As the consumer, you can use this value to ensure that you handle messages in the correct order.
To do so, you will need to persist this number on your end, and compare the sequence number from the
message against the one you have stored. Given that the stored number is higher, you should ignore the message.

entityEventSequence

Assumes actions are also always typed to an entity_type
Example: wix.stores.catalog.product, wix.bookings.session, wix.payments.transaction

entityFqdn

ID of the entity associated with the event.

entityId

Event timestamp in [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) format and UTC time. For example: 2020-04-26T13:57:50.699Z

eventTime

Unique event ID.
Allows clients to ignore duplicate webhooks.

If present, indicates the action that triggered the event.

originatedFrom

This is top level to ease client code dispatching of messages (switch on entity_fqdn+slug)
This is although the created/updated/deleted notion is duplication of the oneof types
Example: created/updated/deleted/started/completed/email_opened

slug

Whether the event was triggered as a result of a privacy regulation application
(for example, GDPR).

triggeredByAnonymizeRequest

DomainEvent

body

entityAsJson

Indicates the event was triggered by a restore-from-trashbin operation for a previously deleted entity

EntityCreatedEvent

deletedEntityAsJson

EntityDeletedEvent

Since platformized APIs only expose PATCH and not PUT we can't assume that the fields sent from the client are the actual diff.
This means that to generate a list of changed fields (as opposed to sent fields) one needs to traverse both objects.
We don't want to impose this on all developers and so we leave this traversal to the notification recipients which need it.