> For the complete documentation index, see [llms.txt](https://docs.prioticket.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prioticket.com/getting-started/integration-process/implementation-guide.md).

# Implementation Guide

### Overview

Below, you’ll find a **complete overview** of the functionalities available through our API, starting with **essential mandatory features** for a basic integration, followed by **optional (recommended) advanced functionalities** for partners who want to unlock even more flexibility and customization.

{% hint style="success" %}

#### Certification Cases and Test Products&#x20;

Under each section in this guide, you will find a detailed list of the **certification cases** designed to guide your integration testing in our staging environment. These cases help ensure your implementation meets all requirements.

The certification cases are categorized as follows:

* **Mandatory** – Required for successful certification and go-live
* **Recommended** – Strongly encouraged for a smooth user experience
* **Optional** – Additional tests that apply to specific scenarios or features

Alongside these cases, we provide test products that you can use to validate each configuration and workflow.

<sub>***Important Note:***</sub> <sub>***Mandatory cases may vary***</sub><sub>*&#x20;*</sub><sub>*depending on the suppliers or clients you plan to work with.*</sub>
{% endhint %}

***

### Product&#x20;

Our API supports a wide range of **product configuration types** used by different suppliers, covering everything from simple date-based tickets to complex time-slotted or bundled offerings. These configurations ensure a flexible and accurate booking experience ([reference](/key-concepts/product-structure.md)).

{% hint style="warning" %}

#### Certification Cases and Test Products&#x20;

{% tabs %}
{% tab title="⭐ Mandatory" %}

| Name                                                               | Product ID    |
| ------------------------------------------------------------------ | ------------- |
| Third-Party Connected Product                                      | 62564 & 62551 |
| Seasonal Product                                                   | 62526         |
| All Ages Ticket Type (Person)                                      | 62522         |
| Custom Ticket Type                                                 | 70316         |
| Group Ticket Type                                                  | 62545         |
| Booking Quantity Limit                                             | 62525         |
| [Pick-Up Points](/key-concepts/product-structure/pickup-points.md) | 62523         |
| {% endtab %}                                                       |               |

{% tab title="🔥 Recommended" %}

| Name                                                                                                                       | Product ID |
| -------------------------------------------------------------------------------------------------------------------------- | ---------- |
| [Bundle Product](https://docs.prioticket.com/key-concepts/product-structure/combi-clusters-bundles-and-addons/bundle)      | 92573      |
| [Combi Product](/key-concepts/product-structure/combi-clusters-bundles-and-addons/combi.md) - with reservation subproducts | 62532      |
| [Combi Product](/key-concepts/product-structure/combi-clusters-bundles-and-addons/combi.md) - with open subproducts        | 62533      |
| [Cluster Product](/key-concepts/product-structure/combi-clusters-bundles-and-addons/cluster.md) - all subproducts enabled  | 62535      |
| [Cluster Product](/key-concepts/product-structure/combi-clusters-bundles-and-addons/cluster.md) - some subproducts enabled | 89873      |
| [Extra Options](/key-concepts/product-structure/extra-options.md)                                                          | 62524      |
| {% endtab %}                                                                                                               |            |

{% tab title="📌 Optional" %}

| Name                                                                                                                                  | Product ID |
| ------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| [Booking Questions](/key-concepts/booking-logic/booking-questions.md) - Optional                                                      | 62701      |
| [Booking Questions](/key-concepts/booking-logic/booking-questions.md) - Mandatory                                                     | 85140      |
| [Booking Questions](/key-concepts/booking-logic/booking-questions.md) - Mix Optional & Mandatory                                      | 62653      |
| [Cluster Product](/key-concepts/product-structure/combi-clusters-bundles-and-addons/cluster.md) - with best available seat allocation | 76042      |
| {% endtab %}                                                                                                                          |            |
| {% endtabs %}                                                                                                                         |            |
| {% endhint %}                                                                                                                         |            |

***

### Admission Types

When booking a product, guests may be required to select a specific date, time, or time slot. This behavior is determined by the **admission type** and the **availability settings** configured for the product. Together, these define how the booking calendar or time picker behaves—whether it’s open-ended, limited to specific days, or tied to scheduled time slots ([reference](/key-concepts/product-structure/admission-types.md)).

<details>

<summary>⚠️ <strong>Important Note for Third-Party Products</strong></summary>

> For third-party system connected products, you may encounter a mismatch in the <mark style="color:purple;">`admission_type`</mark> between the **Product Details API** and the **Availability API** responses, example below:
>
> * The **Product Details API** shows <mark style="color:purple;">`admission_type: TIME_DATE`</mark>, as this reflects how the ticket was initially configured in the Prioticket system.
> * The **Availability API** may return <mark style="color:purple;">`admission_type: TIME_PERIOD`</mark>, which reflects the current configuration from the third-party supplier’s system.
>
> This difference occurs because **third-party systems can update their availability structure at any time**, and these changes are reflected live in the Availability API.
>
> In these cases, **you should ignore the admission type shown in the Product Details API and rely on the value returned in the Availability API**, as it represents the most accurate and up-to-date setup from the supplier.
>
> Failing to do so may lead to booking mismatches or errors.

</details>

{% hint style="warning" %}

#### Certification Cases and Test Products&#x20;

{% tabs %}
{% tab title="⭐ Mandatory" %}

| Name          | Product ID |
| ------------- | ---------- |
| Freesale      | 62519      |
| Time Point    | 62520      |
| Time Period   | 62521      |
| Time Slot     | 76038      |
| Time Date     | 76039      |
| {% endtab %}  |            |
| {% endtabs %} |            |
| {% endhint %} |            |

***

### Pricing

Our API supports flexible pricing models to accommodate different product and supplier needs:

* **Base Pricing**: The standard price per ticket. It can vary based on **quantity**, **season**, **day of the week**, or **age category**.
* [**Variable Pricing**](/key-concepts/pricing-guide/variable-pricing.md): Fixed price variations are applied to the base price depending on **specific days, dates, or time ranges**. Useful for weekend surcharges, peak days, or evening time slots.
* [**Dynamic Pricing**](/key-concepts/pricing-guide/dynamic-pricing.md): Prices are adjusted in **real time** by the supplier based on factors like **demand, availability, or timing**. This ensures optimized pricing and inventory management.

These pricing types can be combined to create highly customizable and responsive pricing strategies ([reference](/key-concepts/pricing-guide.md)).

<details>

<summary>Booking Process Flow</summary>

Whether a product uses **base pricing**, **variable pricing**, or **dynamic pricing**, the booking process flow remains consistent:

1. **Request Single-Date Availability**\
   Always start by calling the **single-date availability endpoint**. This ensures you receive **up-to-date availability and accurate pricing** for the selected date and time.

   > <mark style="color:green;">Even for products with only a base price, this step is strongly recommended to confirm availability and minimize booking errors—especially when working with third-party supplier systems.</mark>
2. **Proceed with Booking**\
   Based on your integration, you can then:
   * Use **instant booking** (direct Create Order), or
   * Use the **reservation + confirm order flow** if you support the Reservation API.

For products with **dynamic pricing**, it’s recommended to **compare the price returned in the reservation and/or order confirmation response with the price received in the availability API**. This ensures price consistency and helps prevent issues caused by real-time price updates or outdated data.

</details>

{% hint style="warning" %}

#### Certification Cases and Test Products&#x20;

{% tabs %}
{% tab title="⭐ Mandatory" %}

| Name                    | Product ID |
| ----------------------- | ---------- |
| Flex pricing per ticket | 62542      |
| Flex pricing per group  | 62544      |
| {% endtab %}            |            |

{% tab title="🔥 Recommended" %}

| Name                                   | Product ID |
| -------------------------------------- | ---------- |
| Variable Pricing - based on day        | 62548      |
| Variable Pricing - based on date       | 74998      |
| Variable Pricing - based on time range | 74999      |
| Dynamic (Runtime) Pricing              | 78268      |
| {% endtab %}                           |            |
| {% endtabs %}                          |            |
| {% endhint %}                          |            |

***

### Reservations & Amendments

The Reservation API is designed to **hold availability** while a customer completes their booking. This prevents overbooking and ensures the selected time slot or ticket remains available during checkout. It's especially useful when:

* Waiting for payment confirmation
* Holding items in a shopping cart
* Booking high-demand or limited-availability tickets

For maximum flexibility, including support for cart-based bookings and amendments, we recommend using the Cart flow ([reference](/endpoints/reservations-cart.md)).

To finalise the reservation, proceed with creating an order.&#x20;

{% hint style="warning" %}

#### Certification Cases and Test Products&#x20;

{% tabs %}
{% tab title="🔥 Recommended" %}

| Name                                                                                  | Product ID     |
| ------------------------------------------------------------------------------------- | -------------- |
| Create a reservation                                                                  | Pick by choice |
| Update a reservation (e.g. add another product, update the booking travel date, etc.) | Pick by choice |
| Cancel a reservation                                                                  | Pick by choice |
| Amend an order (e.g. product type count, contact information)                         | Pick by choice |
| {% endtab %}                                                                          |                |
| {% endtabs %}                                                                         |                |
| {% endhint %}                                                                         |                |

***

### Cancellation

Our API provides flexible cancellation options to suit different booking scenarios:

* **Full Order Cancellation:** Cancel the entire order and all associated tickets.
* **Partial Order Cancellation:** Cancel specific guests or bookings within the order.
* **Extra Options Cancellation:** Cancel only the selected add-ons/extra options without affecting the main tickets.

These options help ensure a smooth post-booking experience for both partners and customers ([reference](/key-concepts/booking-logic/cancellation-and-refunds.md)).

{% hint style="warning" %}

#### Certification Cases and Test Products&#x20;

{% tabs %}
{% tab title="⭐ Mandatory" %}

| Name                    | Product ID     |
| ----------------------- | -------------- |
| Full Order Cancellation | Pick by choice |
| {% endtab %}            |                |

{% tab title="🔥 Recommended" %}

| Name                       | Product ID     |
| -------------------------- | -------------- |
| Partial Order Cancellation | Pick by choice |
| {% endtab %}               |                |

{% tab title="📌 Optional" %}

| Name                                 | Product ID |
| ------------------------------------ | ---------- |
| Partial Cancellation - Extra Options | 62524      |
| {% endtab %}                         |            |
| {% endtabs %}                        |            |
| {% endhint %}                        |            |

***

### Email & Vouchers

Our API supports flexible voucher setups to match supplier requirements:

* **Voucher Code Allocation**: You can configure vouchers to be issued **per order** (one code for the whole order) or **per person** (a unique code for each individual).
* **Supplier PDF Vouchers**: Some suppliers require the use of their own branded PDF vouchers. These can be retrieved using the **Get Voucher API**, which returns the URL to download the supplier-provided PDF ([reference](/endpoints/orders/email-and-vouchers.md)).
* **Customer Email Delivery**: Prioticket can send the **confirmation email and voucher directly to the customer** using our standard branding. Custom branding is also available upon request for an additional fee.

{% hint style="warning" %}

#### Certification Cases and Test Products&#x20;

{% tabs %}
{% tab title="⭐ Mandatory" %}

| Name                                                              | Product ID     |
| ----------------------------------------------------------------- | -------------- |
| Voucher code allocation level - one per order                     | 62528          |
| Voucher code allocation level - one per person                    | 62529          |
| Confirmation email & voucher sent from Prioticket to the customer | Pick by choice |
| {% endtab %}                                                      |                |

{% tab title="📌 Optional" %}

| Name                                                                                 | Product ID     |
| ------------------------------------------------------------------------------------ | -------------- |
| PDF Voucher URL                                                                      | Pick by choice |
| PDF Voucher in different languages URL - *Tiqets products (FR, IT, ES, DE, NL only)* | 62531          |
| Customer name required on every voucher - *selected suppliers*                       | 62551 & 74998  |
| {% endtab %}                                                                         |                |
| {% endtabs %}                                                                        |                |
| {% endhint %}                                                                        |                |

***

### Notifications

Our API supports webhook-based notifications to keep you updated on key events such as **order status changes** and **product updates**. These notifications help you stay in sync with order processing, booking confirmations, and product changes in real time ([reference](#notifications)).

#### Order Status&#x20;

Our system supports two main types of order processing flows: **ONLINE** and **OFFLINE**, depending on the capabilities of the supplier's third-party reservation system.

<details>

<summary>ONLINE Process</summary>

*(Voucher code is released instantly at the time of booking from the supplier’s system)*

* When an order is placed or cancelled:
  * If the order is successfully confirmed or cancelled on both **Prioticket** and the **supplier’s** side:\
    → A **webhook notification** is sent, along with an **email confirmation**.
  * If there is an error on either side (Prioticket or supplier):\
    → **No webhook notification** is sent, as no valid order or cancellation was completed.

</details>

<details>

<summary>OFFLINE Process</summary>

*(Voucher code is not provided in real time — common with certain third-party systems like Fareharbor, Galaxy Connect, and Universal Orlando)*

Some third-party supplier reservation systems have **longer response times**, particularly during the stage when **voucher codes** are to be issued. To provide the end customer with a smooth and reliable experience despite these delays, Prioticket uses a **two-stage booking notification system**:

* **Stage 1: Booking Confirmation**
  * Once the order is **successfully placed on Prioticket’s side**, a webhook with event type <mark style="color:purple;">**`BOOKING_PROCESSING_CONFIRMATION`**</mark> is sent.
  * If the booking is then **confirmed by the supplier**, another webhook with event type <mark style="color:purple;">**`BOOKING_CONFIRMED`**</mark> is sent.
  * If the supplier **fails to confirm** the order, you will receive an **email notification** indicating that the booking has failed.
* **Stage 2: Voucher Code Delivery**
  * Once Prioticket receives the voucher code/PDF URL from the supplier system, we trigger a second webhook to notify you that the voucher is now ready.
  * You can choose when and how to communicate this to your customers. Many partners opt to:
    * Send an **initial confirmation email** right after the booking is placed, informing the customer that their tickets are on the way.
    * Send a **second email** with the actual voucher once it’s available (usually within **15 minutes**).

> <mark style="color:green;">This two-step approach helps reduce timeout errors and enables integration with suppliers whose products cannot otherwise be reliably distributed due to latency in ticket delivery.</mark>

* **Cancellation Flow:**
  * When a cancellation request is received, a webhook with <mark style="color:purple;">**`BOOKING_PROCESSING_CANCELLATION`**</mark> is sent.
  * If the supplier confirms the cancellation, a follow-up webhook with <mark style="color:purple;">**`BOOKING_CANCELLED`**</mark> is sent.
  * If the cancellation fails, you will receive an **email** instead, typically with the <mark style="color:purple;">**`BOOKING_CONFIRMED`**</mark> status still in place.

</details>

#### Product Update

When a product is updated by a supplier *(e.g., price change, new season, availability update)*, a **webhook notification** is automatically triggered and sent to your configured webhook URL with the updated product details.

{% hint style="warning" %}

#### Certification Cases and Test Products&#x20;

{% tabs %}
{% tab title="🔥 Recommended" %}

| Name                                                           | Product ID     |
| -------------------------------------------------------------- | -------------- |
| Order confirmation - ONLINE Process                            | Pick by choice |
| Order processing & confirmation - OFFLINE Process              | 62536          |
| Order cancellation - ONLINE Process                            | Pick by choice |
| Order cancellation processing & confirmation - OFFLINE Process | 62536          |
| {% endtab %}                                                   |                |
| {% endtabs %}                                                  |                |
| {% endhint %}                                                  |                |

***

{% hint style="danger" %}
**Need Help?**

If you have questions while preparing your scope, reviewing advanced functionalities, or during development, please raise a [**support ticket**](https://customer.support.prioticket.com/servicedesk/customer/portal/5/group/10/create/134) to our **API Support Team**.

* **Response Time**: Within **4 business days**
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.prioticket.com/getting-started/integration-process/implementation-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
