Implementation Guide

A step-by-step guide to help you connect and start using the Prioticket API effectively.

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.

Certification Cases and Test Products


Product

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

Certification Cases and Test Products


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

⚠️ Important Note for Third-Party Products

For third-party system connected products, you may encounter a mismatch in the admission_type between the Product Details API and the Availability API responses, example below:

  • The Product Details API shows admission_type: TIME_DATE, as this reflects how the ticket was initially configured in the Prioticket system.

  • The Availability API may return admission_type: TIME_PERIOD, 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.

Certification Cases and Test Products


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: 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 (reference).

Booking Process Flow

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.

    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.

  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.

Certification Cases and Test Products


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

To finalise the reservation, proceed with creating an order.

Certification Cases and Test Products


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

Certification Cases and Test Products


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

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

Certification Cases and Test Products


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

Order Status

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.

ONLINE Process

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

OFFLINE Process

(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 BOOKING_PROCESSING_CONFIRMATION is sent.

    • If the booking is then confirmed by the supplier, another webhook with event type BOOKING_CONFIRMED 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).

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.

  • Cancellation Flow:

    • When a cancellation request is received, a webhook with BOOKING_PROCESSING_CANCELLATION is sent.

    • If the supplier confirms the cancellation, a follow-up webhook with BOOKING_CANCELLED is sent.

    • If the cancellation fails, you will receive an email instead, typically with the BOOKING_CONFIRMED status still in place.

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.

Certification Cases and Test Products


Last updated

Was this helpful?