> 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-octo.md).

# Implementation Guide - OCTO

### Overview

Below, you’ll find a **complete overview** of the functionalities available through the OCTO 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 

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;

The OCTO 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.&#x20;

{% hint style="warning" %}

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

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

| Name                                                            | Product ID    |
| --------------------------------------------------------------- | ------------- |
| Third-Party Connected Product                                   | 62564 & 62551 |
| Third-Party Connected Product with delayed booking confirmation | 25852         |
| All Ages Ticket Type (Person)                                   | 62522         |
| Custom Ticket Type                                              | 70316         |
| Booking Quantity Limit                                          | 62525         |
| Pick-Up Points                                                  | 62523         |
| {% endtab %}                                                    |               |

{% tab title="🔥 Recommended" %}

| Name                                      | Product ID |
| ----------------------------------------- | ---------- |
| Cluster Product - All subproducts enabled | 62535      |
| {% endtab %}                              |            |

{% tab title="📌 Optional" %}

| Name                                                  | Product ID |
| ----------------------------------------------------- | ---------- |
| Cluster Product - 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

The OCTO 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**: 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**: 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.

<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

The OCTO API only offers the following cancellation method:

* **Full Order Cancellation:** Cancel the entire order and all associated tickets.

{% hint style="warning" %}

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

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

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

***

### Email & Vouchers

The OCTO 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.
* **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 %}                                                      |                |
| {% endtabs %}                                                     |                |
| {% endhint %}                                                     |                |

***

### Notifications

The OCTO 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.

#### 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 on both **Prioticket** and the **supplier’s** side:\
    → **No webhook notification is sent** as per OCTO's standard.
  * If the order is successfully cancelled on both **Prioticket** and the **supplier’s** side:\
    → You will receive a <mark style="color:purple;">**`BOOKING_UPDATE`**</mark>**&#x20;webhook notification,** with the status \`**CANCELLED**'.

</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**:

* **Order Placement Flow -** When an order is successfully placed at PRIO’s end:
  * If the booking is successfully confirmed at the supplier’s end, you will receive a <mark style="color:purple;">**`BOOKING_UPDATE`**</mark>**&#x20;webhook notification**, with the status \`**CONFIRMED**'.
  * If the booking is **NOT** successfully confirmed at the supplier’s end due to any error or processing issue, you will receive a <mark style="color:purple;">**`BOOKING_UPDATE`**</mark>**&#x20;webhook notification**, informing you that the booking has failed.
* **Order Cancellation Flow -** When an order cancellation request is submitted to PRIO:
  * You will initially receive a <mark style="color:purple;">**`BOOKING_UPDATE`**</mark>**&#x20;webhook notification** with the status \`**PENDING**'.
  * If the cancellation is successfully processed at the supplier’s end, you will receive another <mark style="color:purple;">**`BOOKING_UPDATE`**</mark>**&#x20;webhook notification** with the status \`**CANCELLED**'.
  * If the cancellation is **NOT** successfully processed at the supplier’s end due to any error or issue, you will receive a <mark style="color:purple;">**`BOOKING_UPDATE`**</mark>**&#x20;webhook notification** with the status \`**CONFIRMED**'.

> <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>

</details>

#### Product Update

Whenever a product is updated by the supplier (for example, when a new season is introduced or pricing is updated for an existing season), the <mark style="color:purple;">**`PRODUCT_UPDATE`**</mark>**&#x20;webhook notification** containing the updated product details will be triggered and sent to the configured webhook URL.

#### Availability Update

Whenever there is any availability-related change from the supplier’s end, the <mark style="color:purple;">**`AVAILABILITY_UPDATE`**</mark>**&#x20;webhook notification** will be triggered with the latest availability details.

{% hint style="warning" %}

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

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

| Name                                                           | Product ID |
| -------------------------------------------------------------- | ---------- |
| Order processing & confirmation - OFFLINE Process              | 62536      |
| 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-octo.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.