With Policies APIs, you can manage the policies for a particular event. For example, you can create, update, and delete policies. You can also reorder policies in the Event Dashboard and checkout form.

Policies define terms & conditions for the events, such as terms for canceling attendance, transferring a ticket to another person, and so on. For example: "Participants are entitled to a 100% refund if canceling attendance 1 week prior to the event. After this date, participants will be refunded 50% of the ticket price."

A policy agreement checkbox will be added to the RSVP or checkout form. The policy text can be read in a pop-up window if you click the policy name. By default, there are no policies when you first create an event.

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

• Install the Wix Events & Tickets app from Wix App Market.
• You can create up to 3 policies per event.

• Sync event policies with external ticketing system

• Policy: text that defines terms & conditions, as relevant.
• Event Dashboard: control center, which allows you to manage their site events settings and features.
• Checkout form: the final step in the ticket purchasing process where the customer fills in personal info, reads policies, and pays.

The following table shows field support for filters and sorting for the Policy object:

Field	Query Filter Operators	Sortable
id	$eq, $ne, $lt, $lte, $gt, $gte, $in, $nin, $hasSome, $exists	Sortable
eventId	$eq, $ne, $lt, $lte, $gt, $gte, $in, $nin, $hasSome, $exists	Sortable
name	$eq, $ne, $lt, $lte, $gt, $gte, $in, $nin, $hasSome, $exists	Sortable
body	$eq, $ne, $lt, $lte, $gt, $gte, $in, $nin, $hasSome, $exists	Sortable
revision	$eq, $ne, $lt, $lte, $gt, $gte, $in, $nin, $hasSome, $exists	Sortable
updatedDate	$eq, $ne, $lt, $lte, $gt, $gte, $in, $nin, $hasSome, $exists	Sortable
createdDate	$eq, $ne, $lt, $lte, $gt, $gte, $in, $nin, $hasSome, $exists	Sortable

Related content: API Query Language, Policy Query endpoint

This article presents possible use cases and corresponding sample flows that your app can support. It provides a useful starting point as you plan your app's implementation.

If you're using a Wix site to manage events and another system to handle ticketing, you can synchronize policies between them whenever a policy is updated on the site. For instance, if the refund policies on the Wix site change, and now the policies guarantee a full refund up to only 5 days before the event, this change also needs to be reflected on your ticketing system for checkout purposes.

To upload and update all event policies defined on the Wix site to your external system for the first time, follow these steps:

1. Create a custom field in your system that stores the policy ID for a particular event to ensure a 1-to-1 relationship with the external ticketing system. Craft your code so that this ID won't be overwritten by future updates from your app.

2. Create a mapping from the site policies fields to the system fields that will be used whenever site policies and the external system are synchronized.

3. Query Policies by eventId and send the relevant information to the external ticketing system.

4. On an ongoing basis, listen for changes to site policies with these webhooks:

   • Policy Created Webhook
   • Policy Updated Webhook
   • Policy Deleted Webhook

5. When one of the above webhooks is triggered, you'll receive the policy in the payload. You can bring those changes to the ticketing system by retrieving the relevant info from the payload, and use mapping to take action on the external system:

   • For updated policies retrieve the updatedEvent.currentEntityAsJson.id, updatedEvent.currentEntityAsJson.body and/or updatedEvent.currentEntityAsJson.name values.

   • For created policies retrieve the relevant info from the createdEvent.currentEntityAsJson object.

   • For deleted policies retrieve the createdEvent.currentEntityAsJson.id value.