About Policies v2
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.
Before you begin
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.
Use cases
Terminology
- 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.
Policies v2: Supported Filters and Sorting
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
Policies v2: Sample Use Cases & Flows
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.
Sync event policies with external ticketing system
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:
-
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.
-
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.
-
Query Policies by
eventIdand send the relevant information to the external ticketing system. -
On an ongoing basis, listen for changes to site policies with these webhooks:
-
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.bodyand/orupdatedEvent.currentEntityAsJson.namevalues. -
For created policies retrieve the relevant info from the
createdEvent.currentEntityAsJsonobject. -
For deleted policies retrieve the
createdEvent.currentEntityAsJson.idvalue.
-
Creates a policy. You can create up to 3 policies per event. If you try to create more than 3, you'll get the "Maximum number of policies for the event has been reached" error.
Permission Scopes
For app development, you must have one of the following permission scopes:Updates a policy.
Each time the policy is updated, revision increments by 1. The existing revision must be included when updating the policy. This ensures you're working with the latest policy and prevents unintended overwrites.
Permission Scopes
For app development, you must have one of the following permission scopes:Retrieves a policy.
Permission Scopes
For app development, you must have one of the following permission scopes:Permanently deletes a policy.
Permission Scopes
For app development, you must have one of the following permission scopes:Retrieves a list of policies according to the provided filters and paging.
Permission Scopes
For app development, you must have one of the following permission scopes:Changes policy order in an event dashboard and agreement checkbox on the checkout form. By default, the policies are arranged by the created date in descending order.
Note: It is possible to use both beforePolicyId and afterPolicyId at the same time but only the last one defined will be executed.
Permission Scopes
For app development, you must have one of the following permission scopes:Triggered when a policy is created.
Triggered when a policy is updated.
Triggered when a policy is deleted.