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
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.
Important Note: Mandatory cases may vary depending on the suppliers or clients you plan to work with.
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
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
62523
Combi Product - with reservation subproducts
62532
Combi Product - with open subproducts
62533
62535
62524
Booking Questions - Optional
62701
Booking Questions - Mandatory
62702
Booking Questions - Mix Optional & Mandatory
62653
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_typebetween 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
Freesale
62519
Time Point
62520
Time Period
62521
Time Slot
76038
Time Date
76039
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:
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.
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
Flex pricing per ticket
62542
Flex pricing per group
62544
Variable Pricing - based on day
62548
Variable Pricing - based on date
74998
Variable Pricing - based on time range
74999
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
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)
Pick by choice
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
Full Order Cancellation
Pick by choice
Partial Order Cancellation
Pick by choice
Partial Cancellation - Extra Options
62524
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
Voucher code allocation level - one per order
62528
Voucher code allocation level - one per person
62529
PDF Voucher URL
Pick by choice
PDF Voucher in different languages URL - Tiqets products (FR, IT, ES, DE, NL only)
62531
Confirmation email & voucher sent from Prioticket to the customer
Pick by choice
Customer name required on every voucher - selected suppliers
62551
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_CONFIRMATIONis sent.If the booking is then confirmed by the supplier, another webhook with event type
BOOKING_CONFIRMEDis 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_CANCELLATIONis sent.If the supplier confirms the cancellation, a follow-up webhook with
BOOKING_CANCELLEDis sent.If the cancellation fails, you will receive an email instead, typically with the
BOOKING_CONFIRMEDstatus 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
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
Need Help?
If you have questions while preparing your scope, reviewing advanced functionalities, or during development, please raise a support ticket to our API Support Team.
Response Time: Within 4 business days
Last updated
Was this helpful?
