Idempotency Support

The Prio API supports idempotency, which ensures that repeated requests do not result in duplicate actions. This is especially useful when you need to retry a request due to failures or errors, such as a timeout.

For example, if you encounter a timeout error while making a Create Order request, you can safely retry the request multiple times. The API will ensure that the order is only created once, regardless of how many times the request is retried.

Idempotency is supported for POST requests. Other HTTP methods like GET, DELETE, and PUT are idempotent by definition, so retries on those requests will also not result in unintended duplicate actions.

Fair-Use Policy & Rate Limiting

Currently, we do not implement active rate limiting measures on the API. Instead, we follow a fair-use policy, evaluating whether the API is being used appropriately based on usage patterns.

We analyze API calls to identify any excessive usage, such as:

• Incorrect caching practices

• Improper chaining of requests

• Unnecessary API calls

In addition to this, we have strong DDoS prevention mechanisms to protect against malicious attacks and ensure the availability and reliability of our services.

The guidelines for acceptable usage are outlined during the API certification process. If we identify any integration issues or patterns of misuse, we will proactively communicate with our partners via email, providing recommendations to improve the integration and optimize the connection.

This document describes the Prioticket API, powered by a platform through which products can be distributed for services and venues. This API allows to obtain information about our inventory, check real-time availability and make bookings. Every booking will result in valid tickets with which users have access to the services and venues. Access is allowed when a valid passcode gets scanned and redeemed by the supplier.

Our API is designed to help manufacturers, wholesalers, and suppliers seamlessly connect with their distribution partners, enabling faster transactions, real-time data exchange, and complete process automation. Built with flexibility in mind, it integrates effortlessly into existing systems, ensuring minimal disruption and maximum value.

Built on Research. Designed for Real-World Needs.

We developed our Distributor API based on extensive market research and a detailed analysis of competing solutions. The result? An API that offers one of the most extensive feature sets available today, tailored specifically to the needs of modern distribution networks.

"As CTO of Prioticket, I can confidently say our API isn’t just a tool, it’s a testament to what’s possible when technology meets innovation. We designed our system to be limitless, adaptable, and built for the future." - Raoul van Woerkom

Key Features & Benefits

• Comprehensive Product Data Access Distributors can pull up-to-date product information, including pricing, availability, and specifications, directly into their own systems.

• Real-Time Inventory Visibility Give your partners instant access to your latest stock levels, minimizing backorders and improving order accuracy.

• Streamlined Ordering Process From order placement to confirmation, the entire order lifecycle is automated, reducing manual touchpoints and human error.

• Flexible Pricing Models Support for custom pricing agreements, volume discounts, and contract-specific pricing ensures every distributor gets accurate, personalized data.

• Secure, Scalable, and Reliable Engineered for high performance, our API handles large volumes of requests without compromising on speed or reliability.

• Built for Developers Comprehensive documentation, intuitive endpoints, and clear examples make onboarding fast and painless, for both your internal teams and your external partners.

Jump right in

This guide explains how to manage product availability and capacity for booking experiences such as tours, events, and activities.

Understanding availability and capacity is essential to ensuring your customers can book products at the right time without overbooking. This documentation covers:

To ensure no spooky stuff happens.

Cancellation Policy

Our API allows you to cancel bookings based on a predefined cancellation policy. As the merchant of record, you have the flexibility to either adopt the default cancellation terms provided or create your own customized terms.

For example, you can:

• Label all products as non-refundable.

• Extend the full-refund period to 72 hours, instead of the standard 24-hour window.

However, it’s important to note that regardless of the cancellation policy you set, you will still be invoiced according to the original cancellation terms defined via the API.

Can a cancellation request return a pending status instead of an immediate confirmation?

Yes, while cancellations are typically processed instantly, there are edge cases where the cancellation may not be confirmed immediately.

For example, if a third-party supplier system experiences a timeout or takes longer than expected to process the cancellation, the initial API response will indicate that the cancellation is still being processed.

In such cases, the booking_statusreturned in the cancellation response will be:

To ensure you always receive the final status of the booking, we recommend implementing the "Cancel Order" webhook, which will notify you once the cancellation has been fully processed and confirmed.

Merchandise stock.

Introduction

Prioticket offers a powerful and flexible pricing engine designed to support a wide range of business models, from simple fixed pricing to advanced real-time dynamic pricing. This documentation will guide you through all pricing concepts, configuration methods, and integration patterns supported within the platform.

Whether you're a distributor, reseller, or working with both roles in a hybrid setup, Prioticket helps you optimize your pricing structure to align with your sales strategy.

Core Concepts

Prioticket supports multiple pricing strategies, allowing businesses to set rules and respond to market changes. These are the three pillars:

Base Pricing

The starting price defined for a product. Often based on ticket type (adult, child, etc.) and season.

Variable Pricing

Predefined price variations based on criteria like date, time, quantity, or booking window. It’s structured and rule-based, not reactive.

Dynamic Pricing

Real-time price adjustments based on external factors like demand, inventory, or competitor prices—applied via seamless third-party integrations.

What You'll Learn

This documentation is divided into the following sections:

1. Who Are You? Identify your role in the sales chain (distributor or reseller) and how pricing applies to your model.

2. Pricing Configurations Understand how base prices, age groups, quantity rules, and seasonal logic are combined and calculated within the API responses.

3. Variable Pricing Learn how to set up rule-based price variations (e.g., by time slot, day of the week, quantity, or advance booking period).

4. Dynamic Pricing Explore how Prioticket enables real-time pricing through third-party integrations for responsive, demand-based pricing strategies.

5. How It All Comes Together

   See how each component, from configuration to real-time calculation, works together in a unified pricing flow across all stages of the customer journey.

Variable Pricing in Prioticket

Variable pricing is a flexible strategy where product prices are adjusted based on predefined rules. This model is particularly useful for applying strategic price differentiation without requiring real-time updates.

What is Variable Pricing?

Variable pricing refers to changes in pricing based on structured, rule-based conditions. These changes are not calculated dynamically but follow logic that has been set in advance. This allows for transparent and predictable pricing strategies.

Types of Variable Pricing

Prioticket supports a wide range of variable pricing options:

• Day of the Week (DOW): Different prices can be applied depending on the day (e.g., higher prices on weekends).

• Date-Based Pricing: Unique prices set for specific dates.

• Time Period Pricing: Applies different rates during defined hours (e.g., 4 PM – 5 PM).

• Time Slot Pricing: Specific pricing for certain time slots.

• Quantity-Based Pricing: Pricing changes based on the number of tickets or products selected.

• Advance Booking Period: Adjust prices based on how far in advance the booking is made.

Pricing Variations

• Increase or Decrease: Prices can be raised or discounted.

• Types of Adjustments: Adjustments may be a fixed monetary amount or a percentage.

• Targeted Scope: Variations may apply to all tickets or only specific ticket types (e.g., adult or child).

• Season Duration: Price rules typically apply to entire seasons and are not changed frequently (usually not more than once per month).

Use Cases

• Offering discounts for early bookings.

• Charging premium rates on weekends.

• Encouraging bulk purchases with tiered pricing.

• Lowering prices for low-demand time slots.

Best Practices

• Clearly define seasonal windows before setting variable rules.

• Apply different pricing rules gradually to avoid over-complication.

• Test and monitor API results to confirm that pricing logic behaves as expected.

Who Are You?

Prioticket supports a variety of pricing strategies depending on your business role and sales channels. Understanding your role is key to configuring and managing pricing effectively.

Your pricing approach may vary based on your business role:

• Distributor on a Commission/Net Model Work with fixed commissions or negotiated net pricing.

• Distributor or Reseller on a Revenue Share Model Collaborate with suppliers to share revenues transparently.

• Reseller on a Cost-Plus Model Operate using cost-based calculations with clear markup strategies.

Distributor on a Commission / Net Model

Perfect for B2B setups with clear commission or fixed net pricing.

How it works:

• You receive a cost price from the reseller admin.

• You can configure your own agent fee or discounts.

• The guest pays the final price, which includes any applied fees.

Distributor on a Revenue Share Model

Best for partnerships where revenue is shared between parties.

How it works:

• A revenue share percentage is agreed between distributor and reseller (e.g., 30/70).

• The margin between cost and selling price is split accordingly.

Reseller on a Cost-Plus Model

Ideal for centralized pricing with reseller flexibility.

How it works:

• The supplier provides a net cost.

• The market admin applies a markup to set the resale price.

• Resellers use this resale price as their cost and can set guest prices independently, increase or descreasing their margin.

Sales & Booking Flows

1. INDIRECT SALES → Distributor Channel Example: Rubens Hotel (Distributor) sells Evan Evans tickets.

2. DIRECT SALES → Direct Channel Example: Guest books directly via web POS or app.

3. INDIRECT SALES → Reseller Channel Example: Booking via platforms like Viator.

The Cart functionality allows you to group multiple bookings (from one or more suppliers) under a single order, enabling flexible checkout, centralized payment, and promotional logic. The key to managing a shared cart is the order_reference, which is created once and reused across all related operations.

Typical Workflow

Benefits

• Group bookings from multiple suppliers into a single order.

• Apply promotions and cart-level discounts.

• Centralize payment under one transaction.

• Fully compatible with real-time availability and POS/web workflows.

Core Concepts

• Order Reference: A unique identifier representing the cart. All bookings associated with this order_referenceare grouped together.

• Booking Aggregation: Multiple bookings can be added to the same cart by referencing the existing order_reference.

• Real-time Cart Management: Bookings can be added or removed dynamically, with the cart reflecting the current state.

• Promotions and Discounts: Apply various promotional codes or discounts, which can affect individual items or the entire cart.

• Payment Integration: Once all desired bookings are in the cart, a single payment transaction can be initiated for the entire order.

Multilingual Content Support

Our API fully supports multilingual content, allowing you to provide content in multiple languages for your products.

Product Content

The translatable content for each product is stored within the product_content object. By default, the API returns content in the default language of the product, which is typically English.

Supported Languages

If you'd like to retrieve the content in a different language, you can find the available languages for a specific product within the product_content_languages array. This array contains the language codes for all supported languages for that product.

How to Request a Different Language

To request content in a specific language, simply include one of the language codes from the product_content_languages array in your request. Add the language code to the URL as follows:

&product_content_language={language_code}

This will allow you to retrieve product content in the desired language.

API Versioning Strategy

We’ve established a versioning strategy to manage updates to our API, ensuring smooth transitions and backward compatibility for our partners. When a new version is released, you can continue using the current version or migrate to the updated version at your convenience.

Deprecation and Upcoming Changes

• Deprecated Methods: Some methods are marked as deprecated due to limitations in our interactive documentation. These methods are not actually deprecated but are planned for future release. You can ignore these parameters as they relate to features outside the scope of your current integration.

• Continuous Updates: We are constantly improving and adding new functionalities to the API. As long as updates are backward-compatible and non-breaking, they will be incorporated into the current version. If any breaking changes are needed, a new version will be released. Please note that syntax for upcoming features may change before release.

Release and Deprecation Process

• New Versions: New API versions are released as needed. Any breaking changes will trigger a version increment. All endpoints will be updated to the latest version when a new release occurs.

• Notifications: Partners will be notified of version releases, including new features and any breaking changes.

• Deprecation Period: Once an API version is deprecated, partners will have a minimum of 18 months to update their systems. After this period, requests to deprecated versions may result in a 400 Bad Request response.

Release Criteria

• Backward-Compatible Changes: Some changes do not require a version increment and are fully backward-compatible. These include:

  • Introduction of new API endpoints.

  • Addition of non-required properties to request/response schemas.

  • Addition of new HTTP methods (POST, GET, PUT, PATCH, DELETE).

  • Addition of new key values in existing fields (without changing operational logic).

  • Unexpected HTTP redirects (301, 302) may be handled as part of normal operations.

• Breaking Changes: Any changes that break compatibility with existing implementations will result in a version increment. These include:

  • Addition or removal of required properties in request/response schemas.

  • Change in data type or format of fields (e.g., changing date formats).

  • Alteration or removal of HTTP status codes in responses.

  • Modifying the Content-Type on existing endpoints.

  • Modification or removal of field key values in a set.

  • Changes to the operationId of an endpoint.

Data Volume and Pagination

Please be aware that some datasets can be larger than others, as the size of your inventory depends on the specific configuration of your catalogue. For endpoints where potentially thousands of records are expected, pagination is available to manage the volume of data efficiently.

To ensure optimal performance and avoid timeouts or excessive data loads, we highly recommend implementing pagination when retrieving large datasets. This is particularly important for partners who are processing considerable volumes of data, as it helps ensure smoother and more manageable requests. By following the pagination rules, you can easily retrieve the full dataset without overloading your system or encountering errors.

When booking certain products, guests may be required to choose a specific day or time for their booking. Depending on the type of admission, the calendar or date-time picker may have different restrictions. Below, we outline the most common types of admission and how each one functions during the booking process.

TIME_PERIOD

With this admission type, customers can arrive anytime between the start and end time of the availability slot. There can be multiple time periods within a single day, so both a date picker and a time picker will be necessary for this selection.

Examples:

• Amusement Park with Multiple Shifts: Guests can choose between a morning shift (e.g., 09:00 - 12:00) or an afternoon shift (e.g., 14:00 - 22:00).

• Afternoon Admission: A ticket valid from 1pm to 9pm at an amusement park.

TIME_DATE

This is a variation of the TIME_PERIOD type, but in this case, there’s only one period per day. The guest only needs to select a date (no need to choose a time). If the availability spans across midnight (over two days), the start date is used to determine the valid day.

Examples:

• Museum Ticket: Valid for any time during the chosen day.

• Public Transport Ticket: Can be used anytime during the whole day.

TIME_POINT

For TIME_POINT admission, customers must arrive at the start time of the availability slot but are free to leave whenever they wish. The start time is critical, as it defines the time the customer needs to be present.

Examples:

• Museum Timed Entry: A ticket with a 10am entry time. The guest must arrive by 10am but can leave any time afterward.

TIME_OPEN

This type of admission allows customers to arrive at any time within a valid period, there are no time restrictions or availability checks.

Examples:

• Museum Entry Voucher: Valid for entry at any time during the year.

TIME_SLOT

With this type, customers must be present at the start time and are expected to stay until the end time. This is typically used for events or services that have a specific duration, such as a tour, class, or appointment.

Examples:

• Tour Reservation: A tour starting at 9am and ending around 12pm.

• Haircut Appointment: A reserved time at 3pm for a 30-minute session.

• Fitness Class: A class from 6pm to 8pm.

Dynamic Pricing in Prioticket

Dynamic pricing enables real-time price adjustments based on live variables such as demand, supply, time, customer behavior, or external market conditions. This strategy empowers businesses to respond to market fluctuations and maximize revenue.

What is Dynamic Pricing?

Dynamic pricing adjusts prices on the fly using data inputs and intelligent algorithms. It’s commonly used in industries where supply and demand fluctuate frequently.

Examples from Other Industries

• Airlines & Hotels: Prices vary with seat or room availability.

• E-commerce: Rates shift based on inventory or competitor pricing.

• Ride-Sharing: Peak hours result in higher prices due to demand.

Dynamic Pricing in Prioticket

Prioticket integrates with third-party pricing engines to ingest real-time pricing data. This allows the platform to reflect dynamic prices across:

• Web POS

• Agent Portal

• APIs (Reservation and Order)

These integrations ensure that pricing stays competitive and optimized without manual intervention.

Configuration & Workflow

• Configure products to accept external pricing input.

• Connect third-party pricing providers via API.

• Prioticket will use the incoming pricing data during the booking process.

Benefits

• Maximizes revenue during high-demand periods.

• Enables promotional pricing in response to market events.

• Reduces manual pricing management.

Considerations

• Price transparency for users must be maintained.

• Thorough testing is recommended to validate real-time updates.

Product Definitions and Classes

Each product in our system contains product types, which can vary in their configuration. These types can include age-based ticketing (such as Adult and Child), as well as other flexible variations like group pricing, business vs. economy seating, or different car configurations. Since different products may behave differently, each product type is grouped into a product class, a category that defines how the product behaves.

Class Standard

Products in the Standard class are the most common and are supported by almost all systems. These product types are typically age-restricted, allowing for variations in pricing based on the customer’s age. For example, adults may pay full price, while children or seniors might receive discounts. Some products may also have special rules, such as requiring at least one adult for every group of children.

When customers proceed through the checkout process, they will be asked to select the number of individuals from each age group. The common age categories are:

• ADULT – Adult

• CHILD – Child

• SENIOR – Senior

• YOUTH – Youth

• INFANT – Infant

Class Individual

Products in the Individual class are less common and usually have fewer supported systems. These product types are not age-restricted. Instead, they are typically focused on specific individual categories such as:

• PERSON – Person

• STUDENT – Student

• RESIDENT – Resident

• MILITARY – Military

• IMPAIRED – Impaired

Class Item

The Item class includes product types that do not refer to people, but rather other items or packages. These could include things like:

• A specific item or package (e.g., Regular, Silver, Diamond)

• Merchandise (e.g., souvenirs)

• Private tours or event types

• Class identifiers (e.g., Economy, Business)

Class Group

Products in the Group class are designed for multiple people. These types are useful for bookings where several individuals are included in a single transaction. For example:

• GROUP – A group of people

• FAMILY – A family (e.g., 2 adults, 2 children)

Class Custom

Custom class products are dynamic and fully configurable. They are used when a product requires specific integration with external systems. These products don’t have a fixed product type but instead can take any form based on the external system's needs.

• CUSTOM – A custom product (e.g., a special package that requires explicit mapping with an external system)

By categorizing products into these classes, we provide flexibility and precision in how products and their types are structured, ensuring a smooth and intuitive experience for both customers and integration partners.

Authorization

To allow secure data transmission between Suppliers and Distributors all API requests require HTTPS.

The API Key Token information for the staging and production environment will be sent in a separate mail.

If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an unsupported authentication method), the resource server should not include an error code or other error information.

Authorization: Bearer JWT Token

Content-Type

The Content-Type should be application/json.

Accept-Encoding

This API is equipped to support gzip compression. By including "gzip" in the Accept-Encoding header parameter of your request, the API will reply with a compressed response using gzip format.

Application Info

Application info consists of data elements that identify the software that you use for making requests to the Prio platform. When you include application info in your requests, we can analyze and troubleshoot more efficiently, and provide a better support experience.

Application info includes:

• App-Name - Name of your application.

• App-Version - Version of your application.

• App-Flavor - Flavor of your application.

• App-Package-Name - Package name of your application.

• App-Build-Number - Build number of your application.

• App-Platform - Platform of your application (e.g Web, iOS, Android).

• App-Flavor - Flavor of your application.

• App-Reference - Unique request reference from your application.

• App-Machine-ID - Identifier of your machine.

Above values can be sent in the headers of any request and we recommend sending them if you have multiple applications directly interacting with this API. Custom headers can be sent as well, as long as they have the "App-" prefix attached.

At Prioticket, we are proud supporters of OCTO, one of the most recognized and widely adopted API standards in the travel industry. In fact, if you’re already an OCTO-compliant supplier, connecting to Prioticket is effortless, no additional development required.

We’re also actively working on supporting OCTO for resellers, so stay tuned for updates on that front.

Prioticket API or OCTO — Which One Should You Use?

It’s a great question, and the answer is simple: we believe in flexibility. Whether you choose to work with OCTO or leverage the Prioticket API, the choice is entirely yours. Every partner is different, so we leave it up to you to decide what fits your needs best.

To make your decision easier, we’ve created a detailed comparison of the Prioticket API vs OCTO, highlighting the key differences, capabilities, and benefits of each option.

The Distributor API V3.8 allows authorized distributors to:

• Access product inventory

• Check real-time availability

• Create bookings

• Generate valid tickets for services and venues

Each successful booking returns a ticket containing a valid passcode. This passcode can be scanned and redeemed by the supplier at the venue to grant access to the service.

Versioning

Version: 3.8 - Latest

This version is currently in Beta.

Beta products and features are stable and supported for production use and are covered by our SLAs and technical support commitments.

However, some capabilities might not yet be fully documented or consistently available across the platform.

Feedback is highly encouraged to help us refine the final GA release.

To view previous version please visit our specifications page.

Change Policy

If you're viewing the latest version, continuous amendments to both the documentation and the API can be expected.

We are constantly adding new functionalities and parameters to the same API version, as long as these are non-breaking and backwards compatible.

If any breaking changes are required, a new version will be introduced.

Note: The syntax of upcoming (not yet released) functionalities might be subject to change.

Prioticket Confidential This documentation is protected by law from any form of duplication unless prior permission is obtained from the officers of Prioticket.

View and Manage Contacts.

Please note that this API does not amend order contacts. To amend order details, please call the Update Order API instead.

Only applicable for partners using the Contacts Module (Returning guests). For regular transactions these endpoints can be safely ignored.

Asynchronous notifications of events.

Supported Events:

• Product creation, amendment or removal.

• Order creation, amendment or cancellation.

• Payment creation, refund or amendment.

• Voucher release or revocation.

• Redemption.

Manage and retrieve all your products.

• View your inventory.

• Get tax information.

• Extensive search and filter.

• Retrieve availability and capacity.

• Get product ratings and reviews.

In most cases, this content is periodically cached on the partner end, but these API endpoints are also optimized for direct front-end use.

Manage and settle payments using the API.

Not applicable to B2B resellers / purchases (Indirect sales / SettlementType:EXTERNAL).

Reserving a product is only mandatory in case the product has managed capacity. Although we also recommend to implement it in the following cases:

• When holding customer products inside a shoppingcart.

• Lock a slot while waiting for a confirmed payment.

• High demand / low availability tickets (concert/events).

• Adding promocodes to an order.

• Managing combi- and cart-discounts.

• Cross-client order process.

Reservations can be confirmed by passing the reservation_reference to the Create Order API. One or more products can be reserved at once. We highly recommend implementing the Cart flow for maximum functionality.

Get realtime availability & pricing.

Prioticket provides two distinct endpoints to support accurate availability and pricing:

• Availability & Pricing Variations API – Returns detailed pricing rules and logic, ideal for advanced UI behavior or transparency in pricing explanations.

• Availability & Calculated Pricing API – Returns real-time availability and final calculated pricing, optimized for booking flows and calendar rendering.

Each serves a different purpose in the booking journey. To implement them correctly and avoid common pitfalls (e.g. mismatched prices, missing availability, performance issues), please refer to the full documentation on GitBook.

What is Availability?

Availability defines the specific time slots or periods during which a product can be booked or accessed. It is essential for scheduling reservations for products with fixed sessions or operating hours.

Types of Availability

• Open Products These products are available during general opening hours without specific time slots. Customers can visit at any point during the open window.

• Reservation Products These require selection of a defined time slot. Often used for tours, events, or activities with limited capacity per session.

• Seasonal or Date-Based Availability Products may only be available during specific seasons, date ranges, or recurring patterns (e.g., only on weekends or public holidays).

• Sub-Product Availability (Combi Products) Each sub-product in a combi product must have its own independent availability settings. For example, a museum visit and a dinner may have different available times.

Availability in Booking Flow

• When booking combi products, the system must gather and validate availability for each sub-product.

• If one sub-product is unavailable, the overall product may be considered unbookable unless alternative configurations are in place.

• Some configurations support selecting the number of participants first, which then loads availability based on seasonal or capacity rules. This enhances usability but can introduce errors if not carefully managed.

Dependencies Between Sub-Products

• Sequential Dependencies You can configure the order in which products are used (e.g., you must complete a tour before you can attend the dinner).

• Time Constraints The time between sub-products can be fixed (e.g., 30-minute buffer after activity A before activity B).

• Optional vs. Mandatory Dependencies Some sub-products may be optional and have flexible availability, while others must be booked in sequence.

Availability Scenarios

Best Practices for Availability

• Define availability per sub-product first before linking in combi logic.

• Use the system’s dependency configuration tools to control flow and prevent conflicting schedules.

• Audit availability regularly, especially after importing or duplicating product configurations.

• Offer fallback options (e.g., suggest alternative time slots) when preferred availability is not found.

• Use consistent naming and descriptions for time slots (e.g., "Morning Tour", "Evening Cruise").

Manage the complete order lifecycle:

• Confirm reservations.

• Make direct bookings.

• Amend existing orders.

• List all orders and bookings.

• (Partial) cancel orders.

• Get pre-generated vouchers.

To interact with the Prio API, you must authenticate using OAuth 2.0. Upon onboarding, you will receive a client_id and client_secret, which you will use to obtain an access token.

Getting an Access Token

Use the client_credentials grant type to request an access token. Once obtained, the token must be included in the Authorization HTTP header for all subsequent API requests:

If the Authorization header is missing or the token is invalid, the request will be rejected with an appropriate error message. A 400 Bad Request or 403 Forbidden response will be returned depending on the scenario.

We strongly recommend using a reputable OAuth 2.0 library for your programming language to handle token management and HTTP header injection automatically. Avoid implementing this logic manually.

Security Guidelines

• HTTPS Required: All API requests must be made over HTTPS. Requests over plain HTTP will be rejected.

• Authentication Required: All API requests must include a valid access token. Requests without authentication will fail.

• Token Revocation: If a token is deactivated or otherwise invalidated, the API will return a 403 Forbidden response.

• Key Management: Your API credentials (client_id and client_secret) must be kept confidential. You are fully responsible for all activity conducted using your credentials.

• Compromised Keys: If you suspect your credentials have been exposed or misused, immediately contact us to revoke access and regenerate credentials.

Many tours and attractions rely on pickup logistics, whether you’re offering hotel transfers, bus pickups, or a meeting point at a central location. Our Pickup Points system makes it easy to define, display, and manage pickup options for your products.

Pickup Points can be mandatory, optional, or not used at all. They're linked to locations and times, and can even restrict availability depending on the booked time slot.

Concepts

• Multiple Pickup Points: Products may offer several pickup points, each with its own location, available times, and duration.

• Time Selection: Guests choose a pickup time from pickup_point_times. The selected time must respect availability constraints.

• Availability Dependency: When pickup_point_availability_dependency is true, the available pickup times are dynamically filtered to ensure the pickup fits within the overall booking slot.

Quick Overview

Pickup Points are returned on the product level. A product can:

• Require the guest to choose a pickup (MANDATORY)

• Offer pickup optionally (OPTIONAL)

• Not offer pickup at all (NOT_SET)

"product_pickup_point": "MANDATORY"

If pickup is available (MANDATORY or OPTIONAL), the actual pickup points are listed under product_pickup_point_details.

Pickup Point Structure

Each pickup point provides all the relevant information for display and processing during checkout.

{
  "pickup_point_id": "PICKUP_POINT_ID_123",
  "pickup_point_name": "Walkingtour at the Wyndham Apollo Hotel",
  "pickup_point_description": "Meet at the Wyndham Apollo hotel.",
  "pickup_point_type": "MEETING_POINT",
  "pickup_point_location": "LOCATION_ID_123",
  "pickup_point_time": "10:00",
  "pickup_point_times": ["10:00", "10:30", "11:00"],
  "pickup_point_duration": 30,
  "pickup_point_availability_dependency": true
}

Time Dependency Logic

If pickup_point_availability_dependency = true, only pickup times that fit within the booked availability slot will be shown.

This ensures a consistent and logical experience for guests and avoids overlaps.

Real-World Use Cases

• Hotel Pickup A guest must choose one of 5 listed hotels. Pickup is at 10:00, takes 30 mins. The tour starts at 11:00.

• Meeting Point Only Set pickup_point_type: MEETING_POINT, and provide a clear location and description, e.g., “Look for the red umbrella.”

• Dynamic Availability Based on the tour’s availability, pickup times adjust automatically to ensure guests arrive on time.

Best Practices

• Validate Locations: Ensure pickup_point_location maps to a valid entry in product_locations.

• Avoid Conflicts: Respect availability dependency when rendering selectable times.

• Pre-fill Times: If there’s only one time per point, pre-fill to simplify UX.

• Localize: Pickup names and descriptions should be translatable for better guest experience.

This section explains advanced capacity control mechanisms within the Prioticket platform that allow precise management across products and distribution channels.

Shared Capacity

Definition:

Shared capacity allows multiple products to draw from the same capacity pool, preventing overbooking when they rely on a common resource (e.g., tour bus, room, guide).

Use Cases

• Multiple tours using the same vehicle

• Language variants of the same experience

• Combi products reusing sub-product time slots

How It Works

• Products reference a shared capacity_id.

• Each product has its own availability calendar, pricing, and logic.

• Booking any product deducts from the same shared capacity pool.

• Capacity is updated in real time across all linked products.

Best Practices

• Only use shared capacity when there's an operational overlap.

• Ensure all linked products operate on the same time logic (start time, duration).

• Use descriptive capacity_ids (e.g., bus_30_seats_morning).

Allocated Capacity

Definition:

Allocated capacity reserves a portion of available capacity for a specific reseller, channel, or distributor. This ensures availability for priority partners or campaigns.

Configuration

• Managed via the Allocations Manager in the control panel.

• Set by:

  • Distributor/Reseller ID

  • Time range (specific dates or recurring days)

  • Product or capacity ID

• Allocation rules may optionally:

  • Exclude existing bookings

  • Block dates fully

  • Reclaim canceled capacity

Behavior & Sync

• Allocated capacity is enforced at booking time.

• Cancellations or modifications restore capacity to the correct allocation.

• Fully auditable; all changes logged.

• Real-time syncing ensures distributors don’t see outdated capacity.

Tips for Managing Allocations

• Allocate based on historical demand or sales targets.

• Combine with combined capacity rules to allow soft fallbacks.

• Monitor capacity leakage (e.g., allocations going unused).

• Name allocation rules clearly (alloc_OTA_may2025_peak, etc.)

Comparison: Shared vs Allocated

Overview

Building great customer journeys starts with helping users find exactly what they’re looking for, quickly, intuitively, and with minimal friction. That’s why we provide a suite of powerful content discovery endpoints to help you deliver personalized and well-organized travel experiences across any platform.

Whether you're creating a travel booking app, a city tourism portal, or a B2B reseller platform, our Destinations, Locations, and Categories APIs help structure and filter content so your users can explore effortlessly.

Explore by Destination

GET /products/destinations

What It Does

Returns a list of destinations where your connected products are available. A destination typically refers to a high-level geographic area, a city, region, or tourist hub.

Common Use Cases

• A homepage travel search where users start by choosing a city like “Paris” or “Amsterdam”.

• Building a landing page like www.mytravelapp.com/rome/ that shows all activities in that city.

• Displaying destination filters in a search form or sidebar.

Real-World Scenario

A reseller platform wants to offer "Travel by City" navigation. By calling this endpoint, the platform dynamically populates a list of available cities tied to products in their portfolio, without any hardcoding. Once a guest selects a city, they’re instantly shown relevant offers within that region.

Zoom into Specific Places

GET /products/locations

What It Does

Returns a list of more granular locations where experiences take place. Think individual attractions, museums, venues, or parks.

Common Use Cases

• Displaying exact location info on product detail pages.

• Enabling “near me” searches for mobile users using GPS-based filtering.

• Showing products on a map view or geo-based clustering feature.

Real-World Scenario

Imagine a mobile travel app where a user enables geolocation. You can use /locations to fetch all venues within a certain radius of the user's current coordinates, allowing spontaneous bookings like “Skip-the-Line at the Van Gogh Museum – 100m away”.

Group by Theme

GET /products/categories

What It Does

Returns a structured list of categories that group your product offerings into themes like “Museums”, “Boat Tours”, or “Day Trips”.

Common Use Cases

• Adding category filters to product listings or search UIs.

• Organizing catalog pages, such as /categories/tours.

• Letting users browse products by interest.

Real-World Scenario

Let’s say a user visits your app and filters by “Outdoor Activities”. Behind the scenes, you’re using the categories endpoint to populate these options dynamically, making your UI easier to maintain and future-proof as more experiences are added.

Full Discovery Flow: From Idea to Booking

Let’s say a user lands on your travel website looking for things to do in Barcelona. Here’s how you can help them:

1. List Destinations Fetch and display destinations so they can select "Barcelona".

2. Filter by Location After choosing Barcelona, show popular places, museums, parks, attractions, using /products/locations.

3. Refine by Category The user is interested in history and museums. Use /products/categories to let them drill down to relevant products like "Barcelona City History Tour" or "Skip-the-Line Sagrada Familia".

Use in Dynamic UIs

These endpoints are ideal for:

• Faceted search interfaces (Destination + Category + Price Range)

• Autocomplete search suggestions

• Map-based exploration

• Custom itinerary builders

• Localized or themed landing pages

The Promocode module allows customers to apply promotional codes to their reservations, unlocking discounts and special offers seamlessly.

Overview

This module supports adding and removing promocodes on existing reservations via API calls.

• Add a promocode to apply a discount to the reservation/cart.

• Remove a promocode to revoke the discount.

• Validation ensures promocodes are valid, active, and applicable.

• Detailed error messages guide the front-end UX for failed promocode attempts.

How Does It Work?

• Add a Promocode: When a customer enters a promocode (like "SUMMER20"), it’s checked and applied to their reservation if valid.

• Update Prices: Once added, the reservation’s price updates immediately to show the discount.

• Remove a Promocode: If a customer changes their mind or enters the wrong code, they can easily remove it.

• Clear Messages: If a promocode can’t be used (expired, already used, or not applicable), a friendly message explains why.

When Should You Use It?

• To run special promotions like holiday sales, seasonal discounts, or exclusive offers.

• To reward loyal customers with personalized discount codes.

• To encourage larger bookings by offering percentage or fixed amount discounts.

What Customers Will See

• The name and description of the promotion (e.g., “Christmas Sale: 20% off”).

• The updated price after the discount is applied.

• Helpful messages if the promocode can’t be accepted, like “This code has expired” or “You’ve already used this promocode.”

Adding a Promocode

1. The customer enters their promocode during or after making a reservation.

2. The system checks if the code is valid and can be used.

3. If everything is good, the discount is applied, and prices update immediately.

4. If the code isn’t valid, the customer gets an easy-to-understand message explaining why.

Removing a Promocode

If needed, the customer can remove a promocode anytime, and the price will update to reflect the change. Also, if the promocode was used and then cancelled, it will become available for future use again.

Why Is This Important?

• It gives your customers control over applying discounts.

• Promocodes help increase sales by encouraging customers to buy.

• Clear, friendly messages improve customer satisfaction and reduce confusion.

• Ensures your pricing stays accurate and transparent.

We recommend implementing a timeout duration of 60 seconds due to dependencies on external supplier systems that are beyond our direct control. While most booking requests are processed promptly, there are rare instances where response times may exceed this duration.

It is important to note that even if the Confirm Booking endpoint encounters a timeout or returns an HTTP 500 error, the booking may still be successfully created. To ensure system resilience and maintain consistency, we strongly recommend implementing the following methods.

Idempotency

• The Prio API supports idempotency, allowing multiple retries of the same request while ensuring the action is performed only once.

• This mechanism prevents duplicate bookings in case of failures or retries.

• Idempotency is supported for POST requests, whereas GET, DELETE, and PUT requests are inherently idempotent.

Webhooks for Asynchronous Order Confirmation

• The Distributor API supports webhooks to track state changes efficiently.

• Subscribers receive notifications whenever there is a change in order status.

• While the booking status remains uncertain, the order is marked as "PROCESSING."

• Webhooks serve as a reliable means of reconciling the booking state. In the event of a timeout, they provide updates once the order has been successfully processed or failed.

• If no webhook notification is received, it is likely that the request was not received or processed successfully. In such cases, we recommend contacting our API support team for further investigation.

Alternative Poll-Based Solution

If webhooks or idempotency cannot be implemented, an alternative poll-based approach can be used to reconcile the booking state. This involves making periodic requests to the GET Order Details endpoint at fixed intervals until a final order state (such as confirmed or failed) is received.

Recommended Polling Strategy:

• Perform 1 call per minute for the first 5 minutes (5 calls in total).

• If no response is received, continue polling once every 15 minutes for the next hour (4 additional calls).

• If no final status is received after this period, abandon further attempts.

Ensuring Booking Consistency

To fully prevent duplicate bookings, we recommend implementing a combination of these methods. The use of idempotency tokens, webhooks, and polling mechanisms will significantly enhance the reliability and consistency of the booking process.

For further assistance or troubleshooting, please reach out to our API support team.

At Prioticket, technology isn’t just a tool, it’s our playground. We push the boundaries of what’s possible, embracing the latest advancements and pioneering industry-leading solutions. Our cloud-native architecture ensures high availability, unmatched speed, and resilience, making our platform the backbone of seamless integrations worldwide.

Innovation Without Limits

We never settle for conventional solutions. Instead of rigid constraints, we build dynamic, tailor-made architectures that adapt to real-world demands. Unlike platforms that impose arbitrary limits, we believe in pushing performance to its limits and beyond. If a tool enhances efficiency, security, or scalability, we master it and make it part of our ecosystem.

Our high-performance API thrives on cutting-edge technologies like:

• Cloud-Native Scaling – Kubernetes, Cloud Run, Dockerized Microservices

• Ultra-Fast Data Processing – Redis, ElasticSearch, Firebase

• Resilient Infrastructure – Load Balancing, Auto-Scaling, Failover Nodes, Sharding, Replication

• Asynchronous Processing – Message Queues, Event-Driven Architecture

• Optimized Network Performance – Multi-Region Hosting, Content Delivery Networks (CDN), Shielded VPN Access

Unmatched Reliability & Speed

We operate on millisecond response times because speed is everything. Our caching infrastructure handles tens of millions of requests per day with a 99.6% cache hit ratio and a staggering 99.995% uptime, numbers that outperform industry leaders.

But raw performance is just one piece of the puzzle. True scalability requires architectural resilience, and that’s why we:

• Implement hot and cold data storage strategies for instant data retrieval

• Ensure zero downtime deployments with rolling updates and blue-green deployment strategies

• Use intelligent traffic routing to dynamically distribute workloads across optimal regions

• Leverage predictive analytics to auto-scale resources based on demand

Security at Every Layer

Security is not just a checkbox, it’s the foundation of everything we build. We enforce:

• Zero Trust Architecture – Strict authentication & authorization using IAM, RBAC, and MFA

• End-to-End Encryption – AES-256 at rest, TLS 1.3 in transit, OAuth2, OpenID Connect

• Defense-in-Depth – IDS, WAF, VPNs, firewalls, network segmentation

• Immutable Data Storage – Write-once, read-many (WORM) storage, cryptographic logging

• Advanced Threat Detection – AI-powered monitoring, intrusion detection, anomaly detection

• 24/7 Automated Security Audits – SOC 2, GDPR, ISO 27001 compliance

We undergo continuous penetration testing and collaborate with external security experts like NCC Group and Accenture to ensure our platform remains unbreakable.

Resilience, Redundancy & Disaster Recovery

Our infrastructure is built to withstand any failure scenario. We employ:

• Multi-Region Failover – Automatic rerouting in case of regional downtime

• Geo-Redundant Data Storage – Ensuring data sovereignty and regulatory compliance

• Automated Disaster Recovery – Instant failover to backup environments with near-zero RTO

• Layered Redundancy – Active-active database clusters, high-availability load balancers

• Real-Time Monitoring & Self-Healing – Cloud-native remediation mechanisms

We don’t just mitigate risk, we eliminate it before it ever becomes a problem.

Compliance & Enterprise-Grade Standards

Our platform follows:

• GDPR, ISO 27001, PCI-DSS, SOC 2 – Ensuring the highest level of data protection

• Strict Data Residency Policies – Supporting region-specific storage regulations

• Advanced Role-Based Access Controls – Over 200+ granular permissions with IAM governance

We collaborate with government institutions and multinational enterprises, proving that security, performance, and flexibility can coexist at the highest levels.

Why Prioticket?

Because we don’t just build APIs, we engineer ecosystems that power global-scale businesses. From handling millions of transactions to integrating with leading payment providers like Adyen, Payfort, and Hyperpay, our platform is built to outperform, outscale, and outlast.

But what truly sets us apart is adaptability. Every business has unique needs, and we don’t force a one-size-fits-all approach. Instead, we work hand-in-hand with our customers to craft bespoke API solutions that fit their exact operational demands, whether it’s:

• Custom data exports & integrations for BI tools like Tableau & Google Data Studio

• Role-based access control with 200+ granular permissions

• Tailored multi-tenancy options for optimized data sovereignty & compliance

• Automated workflows, webhooks, and real-time event triggers

We design our API to be future-proof, meaning as your business grows, so does your system—without limits.

We set the gold standard for modern API ecosystems.

Would you like to push boundaries with us? Let’s build something extraordinary together.

What is Capacity?

Capacity limits how many participants can book a product within a time slot, preventing overbooking and managing resource allocation.

Capacity Types

1. Unlimited Capacity

   • No maximum limit; bookings are always accepted.

   • Common for virtual experiences or events without physical constraints.

2. Fixed (Limited) Capacity

   • A hard limit on how many participants can book a slot.

   • Once full, no additional bookings can be made.

3. Product-Dependent Capacity

   • Specific to an individual product.

   • Even if multiple products are similar, each has its own separate capacity pool.

4. Shared Capacity

   • Several products draw from the same capacity pool.

   • Example: A tour and a museum ticket share the same 30-seat bus.

5. Combined Capacity

   • A hybrid setup where multiple capacities (shared, fixed, or new) are merged for a product.

   • Used for custom reseller rules or group packages.

6. Allocated Capacity

   • Reserved capacity segments for specific distributors or channels.

   • Ensures availability for high-priority partners even when general capacity is exhausted.

Configuration Strategies

Per Sub-Product

• Each sub-product in a combi setup must have its own capacity setting.

• Bookings fail if one sub-product lacks capacity, even if others have availability.

Combi-Level Capacity

• Can reflect the lowest capacity among sub-products or be configured independently.

• Example: A "Tour + Meal" product can have its own 20-person limit, even if the meal supports 50.

Capacity IDs

• Unique identifiers used to track capacity pools.

• Helpful for linking shared and allocated capacities across APIs and systems.

Booking Validation

• Capacity checks are enforced during the booking request.

• Must ensure the requested number of people or tickets doesn’t exceed the limit.

Capacity Visuals

• Often displayed as color-coded slots:

  • 🟢 Green: High availability

  • 🟡 Yellow: Limited slots remaining

  • 🔴 Red: Fully booked or blocked

• Be aware of UI discrepancies across systems or resellers.

Capacity Best Practices

• Use shared capacity only where operationally justified (e.g., same room, guide, or equipment).

• Regularly audit capacity usage to spot bottlenecks or over-allocations.

• Configure fallback logic (e.g., alternate time slots) to improve booking success rates.

• Keep capacity ID naming clear and consistent.

• Simulate edge cases (e.g., near-full or last-minute bookings) in staging environments.

With access to over 400,000+ products across the globe, our platform is built to support every reseller's needs, whether you're looking for iconic attractions, immersive experiences, or local hidden gems.

Below is just a small selection of our top-selling suppliers, giving you a glimpse of the high-quality, high-demand inventory available through our system.

Need help choosing the right supply?

We offer free supply advice to all resellers considering integration, providing tailored guidance and building a well-rounded supply strategy to ensure your success from day one.

With connections to top supply aggregators worldwide, our platform gives you access to diverse inventory. Whether you are seeking global attractions, destination-specific experiences or niche local offerings, these aggregators help streamline your access to high-demand products through a single integration with Prioticket.

Below is just a small selection of our featured aggregators, giving you a glimpse of the breadth and flexibility available when sourcing supply through our system.

Need help selecting the right aggregator? We offer free supply advice to all resellers considering aggregation partners. Our team helps you identify the best fit based on your business model, target markets and sales goals.

Hosting & Infrastructure

Disaster Recovery

Security & Prevention

This page will serve as a central hub, explaining the various aspects of a product within our system and linking to detailed subpages that explore each feature in-depth. From product types to pricing options, and everything in between, this guide will help you navigate the core structure of our API.

What is a Product?

A product in the Prioticket system represents an individual tour, activity, or experience that you can sell. Products are the foundation of the system, and understanding how they are structured is essential for successful integration. A product's structure encompasses various attributes that define its pricing, availability, product types, and other key features.

Key Components

Below are the main features and components that make up a product in the Prioticket API. Each of these elements plays a role in defining what a product is, how it’s priced, how availability is handled, and how it’s presented to the user.

Product Types

Product types define the nature of the product (e.g., tickets, tours, events). This category helps determine what kind of product is being booked and its associated features.

Admission Types

Admission types define the way users gain entry to an event or experience (e.g., standard, VIP, child ticket). These can impact pricing and availability.

Pricing

Pricing includes the base price of a product as well as any dynamic pricing or seasonal pricing adjustments. This feature is essential for calculating the total cost of a product.

Pickup Points

Some products, like tours or activities, may have pickup points for the guests. These are predefined locations where guests can meet the service provider.

Availability

Availability determines whether a product is available for booking on a given date and time. This feature helps ensure that you only offer products that are actually available for sale.

Capacity

Many products have a limited capacity, and this component tracks how many spots are available for a given date, time, or product instance.

Product Options

Product options are additional customizable elements that can be offered with a product, such as extra services or add-ons.

Currency

Currency defines the local currency for each product, which is essential for proper pricing and display.

How Products are Organized

Products in the Prioticket API are organized into categories and destinations. This structure ensures that each product is appropriately categorized and easy to find.

• Categories: Products are grouped into various categories based on type, location, or experience (e.g., Adventure Tours, Sightseeing, etc.).

• Destinations: Products are also associated with destinations to help users search and filter by location.

How to Work with Products in the API

When working with the Prioticket API, understanding how to retrieve, manage, and integrate products is essential. Below are some high-level actions that you can perform using the API:

• Get Product Information: Retrieve the details of any product, including its type, price, availability, and other components.

• Check Availability: Ensure that a product is available for a given date and time.

• Book Products: Once availability is confirmed, proceed to book the product and complete the transaction.

• Reserve Products: Temporarily hold inventory while completing payment.

Additional Resources

Throughout this section, you’ll find detailed documentation on each aspect of product structuring, as well as how these features are used in our API. Make sure to explore the subpages to get more in-depth knowledge of each feature and how it fits into the larger product structure.

With the Prio Distributor API, connecting to our platform and processing bookings couldn’t be easier. Whether you’re looking to browse product content, check live availability, or confirm bookings in real-time, our API offers a streamlined process designed for travel resellers, marketplaces, and OTAs.

This page explains the end-to-end booking flow, giving you a clear roadmap to building your integration, from retrieving content to issuing tickets.

The Four Pillars of the Prio Distributor API

The Distributor API is divided into four core areas, each designed to handle a key part of the booking journey:

Additional APIs for Full Flexibility

Create a booking

To book a product through this API, you generally need to follow these steps:

1. Check availability and pricing: Use the Get Products and Get Availabilities endpoints to verify if tickets for the desired tour or activity are available for a specific date, time, and quantity.

2. Request a booking hold: If tickets are available, request a pricing / availability hold for the booking using the Create Reservation endpoint.

3. Collect payment: Once a booking hold is requested, collect payment either through the provided payment endpoints or via your own payment service provider.

4. Confirm the booking: Finalize the booking by confirming it using the confirm order endpoint.

Overview

The Prioticket platform provides two key APIs that deliver true real-time availability and pricing data for products and services, ensuring the most accurate and up-to-date booking experience:

• Availability & Calculated Pricing API — provides real-time availability and final calculated pricing for booking flows. It is recommended for all products and mandatory for products with managed capacity.

• Pricing Variations & Rules API — returns detailed pricing rules, variations, and conditions that explain how prices change in real time, enabling transparent and dynamic pricing presentations.

Depending on the product_availability parameter defined in the product feed, availability must be requested via these APIs before making a booking to guarantee accuracy and prevent overbooking or pricing errors.

Together, these APIs ensure efficient, reliable, and user-friendly booking and pricing experiences with up-to-the-second data.

Common Considerations for Both APIs

• Timezone & DST: Dates and times are relative to the supplier’s timezone and automatically adjusted for Daylight Saving Time.

• Date Range Limits: Maximum 90 days per query. For longer periods, split requests into smaller date ranges.

• Performance:

  • Response times depend on product source: Prioticket-sourced products generally respond faster than third-party systems.

  • Avoid requesting availability/pricing for multiple products across very long date ranges in a single call to maintain performance.

• Caching:

  • Avoid long-term caching of availability and pricing data as they are dynamic and change in real time.

  • For detailed caching guidelines and best practices, see the full in our technical documentation.

• Booking Logic: Both APIs reflect the system’s managed capacity, partial availability, and grouped availability rules.

Response Structure

You’ll receive:

• Availability & Pricing per time slot

• Total capacity

• Remaining inventory

Refer to the response schema for full details.

Purpose

Returns real-time availability and calculated final pricing based on the product configuration and party size.

Benefits of This Endpoint

• Simplified Pricing: Returns the exact final price for a booking without requiring client-side price calculations.

• UI Friendly: Combines availability and pricing in a single call, making it ideal for rendering calendars and booking flows.

• Efficient Booking Flow: Reduces client-side complexity and minimizes errors during booking validation.

Recommended Usage Pattern

To get both availability and pricing with minimal overhead, we suggest calling this endpoint twice in your flow:

1. Initial Call (No Request Body)

Make a call without a request body to fetch:

• All time slots

• Default pricing per ticket type (usually for quantity = 1)

• Day or time-based pricing if applicable

Use this response to render your calendar and timeslot UI with pricing.

2. Final Price Calculation (With Body)

Make a second call including:

• Party size

• Ticket selections or quantities

This returns the final calculated price for the configured booking.

Purpose

Returns detailed pricing rules, variations, and conditions explaining how prices change for a product.

Benefits of This Endpoint

• Detailed Pricing Insights: Provides granular breakdowns of pricing rules and conditions.

• Transparency: Enables you to explain complex pricing logic clearly to end users.

• Advanced UI Support: Supports building interfaces that dynamically respond to pricing rules (e.g., discounts, time-based pricing).

• Business Logic Integration: Allows triggering custom behaviors based on pricing conditions, improving flexibility.

Summary Table

Overview

Booking Questions (also known as Custom Checkout Fields) empower businesses in Prioticket to collect precise, product-specific guest information during the booking process. This enables personalized experiences, streamlined operations, and improved data accuracy across all sales channels.

What Are Booking Questions?

Booking Questions are customizable fields displayed during the checkout process. They allow you to ask guests for specific information related to a product or experience, such as:

• Dietary preferences

• Group names or participant info

• Pickup details

• Custom inquiries

These fields are essential for operational readiness and personalization.

Key Features

Setup and Configuration

Step-by-Step Setup

1. Navigate to Marketing → Booking Fields

   • Create a new template or edit an existing one

2. Add Fields

   • From the Custom Fields tab, define:

     • Field Name

     • Input Type (text, dropdown, etc.)

     • Placeholder Text

     • Help Text

     • Required toggle

3. Apply the Template

   • Go to Product Overview

   • Assign the template to one or multiple products

This setup allows the same set of questions to be reused, adapted, and maintained across different products or experiences.

Benefits

Strategic Importance

This feature supports Prioticket’s mission to provide flexible and dynamic booking flows for a wide range of use cases:

• Tour Operators needing participant names or age groups

• Experience Providers managing hotel pickups

• Resellers requiring unique partner-specific info

It also aligns with partner expectations for external API compatibility, especially as integrations like Viator and others evolve.

Ongoing Development

• Enhanced support for third-party API syncing

• Future plans for conditional logic, multi-language support, and field grouping

Summary

The Booking Questions and Custom Checkout Fields feature is a cornerstone of customized, efficient checkout experiences in Prioticket. It provides businesses with powerful tools to collect the right information at the right time, ensuring operational readiness, reducing manual effort, and improving the guest experience.

Use Recommendations to highlight themed, seasonal, or top-selling products in a curated way. Whether you're boosting "Winter Favorites", promoting a "Local's Pick", or featuring a "Family Bundle", this module helps you deliver smarter suggestions to your users.

What Is a Recommendation?

A Recommendation groups together one or more products under a shared label and time window. This allows you to:

• Promote specific products on your landing pages.

• Guide users to relevant content.

• Schedule featured products based on seasons or campaigns.

Sample Output

Time Windows

Use recommendation_start_date and recommendation_end_date to schedule when a recommendation should be shown.

• Omit both to show the recommendation always.

• Set future dates to preload campaigns.

• Expired recommendations will automatically stop showing.

All dates follow the ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ) and are in UTC.

Example: Seasonal Campaign

Let’s say you want to create a recommendation titled “Amsterdam Winter Picks”, showing three products from December through January.

Use Cases

Best Practices

• Localize Titles & Descriptions for international audiences.

• Avoid Clutter: Limit each recommendation to 3–8 products for visual clarity.

• Use Descriptions to hint at urgency, value, or context (e.g., “Popular with families”).

• Respect Date Logic: Don’t forget to end expired campaigns.

Overview

Combi Products are bundled offerings that combine two or more activities or items into a single package. They are ideal for businesses offering multi-part experiences, such as tours, attraction combos, or event packages. While they provide significant value to customers, they require careful setup and management to function correctly across all systems and sales channels.

Structure and Definition

What Is a Combi Product?

A Combi Product:

• Contains at least two sub-products or activities

• Requires separate tickets for each sub-product

• May allow or require different booking dates for each component

Sub-Product Configuration

Each sub-product in a combi:

• Has its own quantity, availability, and ticket type

• Can have individual booking rules, such as allowed date ranges or time slots

Configuration & Management

Reservations

• Reservations are generated for:

  • The main combi product

  • Each sub-product

• This ensures accurate tracking of availability, revenue, and booking dates

Capacity Management

• Combi products have independent capacity settings

• Care must be taken to avoid overlapping or double-booking

• Dependencies (e.g., shared start times or mutual exclusivity) must be managed at both the combi and sub-product level

Dependencies

• Dependencies can include:

  • Shared start times

  • Linked ticket types

  • Mandatory booking of certain sub-products with others

UI & UX Considerations

User Interface

The booking interface for combi products should:

• Allow users to select quantities for each sub-product

• Dynamically update available time slots based on selection and dependencies

Validation

The system must:

• Validate input quantities against allowed minimums and maximums

• Ensure selections are consistent with product rules and availability

Cascading Behavior

• Combi products must support cascading logic across all sales channels:

  • Direct (e.g., website, POS)

  • Agent portals

  • Reseller tiles

Integration & Mapping

Third-Party Integration

• Combi products can be integrated with platforms like Fareharbor or Global Ticket

• Proper mapping is required to:

  • Pull real-time availability

  • Push booking data and updates

Mapping Considerations

When mapping a combi product:

• Ensure each sub-product is correctly linked to its external counterpart

• Verify that pricing, capacity, and timing align across systems

Reporting & Financials

Sales Reporting

• In reports, combi products count as a single unit

• However, the total number of tickets is higher, reflecting each sub-product

Invoicing

• Invoices must reflect:

  • Each sub-product’s price and tax

  • Currency conversion if applicable

  • Allocation to the correct supplier or channel

Sales & Distribution

Sales Channels

Combi products can be distributed through:

• Direct sales: Webshops, POS, mobile apps

• Distributors: OTAs (e.g., GetYourGuide, Viator), agent portals

Reseller Activation

• Once configured, combi products can be activated for resellers

• Ensure mapping and pricing align before enabling

Use Cases

City Tours

• Combine transport (e.g., bus, bike, canal cruise) with multiple attractions

Event Packages

• Bundle entry tickets, activities, and dining for a complete experience

Summary

Combi products enable flexible, high-value offerings by bundling multiple experiences into a single package. They are ideal for both tourism and events but require detailed configuration in the following areas:

• Reservations and capacities

• Sub-product dependencies

• Third-party integrations

• Financial and sales reporting

With the right setup, combi products can significantly enhance customer satisfaction while driving more complex, higher-value sales.

The introduction of API version 3.8 marks a significant step forward in pricing transparency and granularity across the Prioticket ecosystem. This page brings everything together, describing how prices flow across the full booking lifecycle, what each parameter means, and how pricing logic adapts based on distribution scenarios.

Key Pricing Parameters

Price Field Descriptions

• product_type_list_price: Supplier's public price, used as the "From Price" in displays. Unaffected by discounts or fees.

• product_type_sales_price: Final price seen by the end-customer. It includes applied discounts.

• product_type_distributor_price: Price paid by distributor to the reseller. Formerly resale_price.

• product_type_reseller_price: Price the reseller pays to the market administrator. New in v3.8.

• product_type_market_price: Price paid by the market admin to the supplier. New in v3.8.

• product_type_supplier_price: Optional internal benchmark cost defined by supplier. Present in all versions.

API V3.8+: Major Improvements

• Granular Pricing Levels: Explicit pricing tiers reveal each stakeholder's costs.

• Improved Field Naming: Pricing keys now align with distribution roles (distributor, reseller, market admin).

• Complete Margin Visibility: Enables precise margin and commission calculation.

Business Model Scenarios

Own products

• Creator = Seller

• 100% margin goes to merchant

• Reseller/distributor fees optional

Resale products

• Creator ≠ Seller

• Prioticket routes payouts between merchant and supplier

• Reseller and distributor fees mandatory

Catalog Model Summary

Direct Catalogs

• Discount Model: Apply promotions to reduce checkout total.

• Bundle Model: Offer product combinations at lower prices.

Agent Catalogs

• Commission Model: Sales price - resale price = agent fee.

• Discount Model: Promo sales price vs list price.

• Nett Model: External sales price

Reseller Catalogs

• Cost+ Model: Resale price = supplier cost + markup.

• Margin Share: Platform splits margins between parties.

Implementation Checklist

1. Upgrade to API V3.8

2. Parse availability_pricing fields

3. Rely on system-calculated pricing (no manual markups)

4. Certify logic in staging

5. Launch dynamic pricing

Benefits Summary

This unified pricing structure ensures all stakeholders, whether supplier, reseller, distributor, or market admin, from consistent pricing, margin control, and full transparency. The 3.8 API is not just a technical update but a strategic foundation for scalable distribution and financial clarity.

Overview

Not every booking is created equal. Some travelers want sparkling wine. Others prefer a vegetarian lunch. Some want a fast-track upgrade, while others just want a printed souvenir. To serve these diverse needs, Extra Options in the Prioticket API let you configure flexible, powerful, and fully translatable enhancements to your products.

Extra Options give your users more control, and your platform more upsell opportunities.

What Are Extra Options?

Extra Options represent configurable add-ons or input fields tied to a product or product type. They can range from selectable extras like drinks or equipment, to form fields where guests provide input like dietary restrictions or preferred visit times.

Each option is configurable by:

• Selection logic (manual or auto-added)

• Input type (checkboxes, dropdowns, text fields, etc.)

• Pricing model (flat rate, per person, included)

• Applicability scope (once per product or per guest type)

• Quantity logic (flexible or restricted)

Real-World Scenarios

• VIP Package: Add a “VIP upgrade” radio button that includes perks like priority entry and a welcome drink.

• Meal Preferences: "Choose your lunch option: Chicken / Veg / Gluten-free."

• Drink Add-on: Let guests choose between wine, beer, or juice. Charge €6 for adults, €4 for children.

• Optional Merchandise: "Add a souvenir T-shirt for €10."

These are all made possible with ExtraOptions.

How It Works

Extra options are returned as part of the product data and are selectable when creating a reservation. Each option can have one or more option values (e.g., “Red wine”, “White wine”) with separate pricing, limits, and types of selection.

Count Types & Selection Logic

• FLEXIBLE: Total option quantities can vary, e.g., 1 drink for 3 guests.

• RESTRICTED: Quantities must match the product type count (e.g., 2 guests = 2 drink selections).

Selection Types:

• MANUAL: Guests choose their own options.

• AUTO: Automatically applied to the cart (advanced use case for default upsells).

Pricing Models

Display Behavior

Validation & Constraints

Option Values

Each option can have multiple values (e.g., Red Wine, White Wine, Water). These include:

These let you control availability and pricing at a granular level.

Use Case Example: Wine Tour

You're building a wine-tasting tour product. Here’s how you'd structure your options:

1. Meal Choice

   • option_type: RADIO

   • option_values: Pasta / Fish / Vegetarian

   • option_selection_type: MANUAL

   • option_count_type: RESTRICTED (1 per guest)

2. Souvenir Bottle

   • option_type: CHECKBOX

   • value_price: €12.00

   • option_count_type: FLEXIBLE

Design Patterns

Overview

Bundle Products in Prioticket allow you to group multiple existing standalone products into one cohesive offer. Unlike Combi Products, bundles maintain the individuality of each sub-product while enabling flexible packaging, pricing, and tax handling. This makes bundles ideal for marketing purposes and promotional configurations.

Definition and Purpose

A Bundle Product is a composite product consisting of two or more independent products combined into one package. Customers purchase the entire bundle as a single transaction, but each sub-product retains its own:

• Price and availability

• Voucher

• Reporting and invoicing attributes

• Tax and commission rules

Use Cases:

• Marketing products that resell combinations of tours or experiences

• Promotions or seasonal packages

• Voucher-driven product bundles

Setup & Configuration

Creating a Bundle

1. Go to the Product Overview

2. Click Create Product

3. Choose Bundle Product

4. Select the Supplier

5. Add existing products from the same supplier

Pricing Configuration

• Bundle List Price: The sum of all linked sub-products’ prices

• Sale Price: Reflects discounts applied at the bundle level (percentage or fixed)

• Seasonal Pricing: Active season on the bundle applies; price variations are defined per sub-product

Product Settings

• Settings like cancellation rules, ticket types, or code layouts must be configured at the sub-product level

• Bundles do not inherit global product settings

Features and Functionality

Dynamic Pricing

• Each sub-product supports dynamic and seasonal pricing

• Adjust pricing based on demand, seasons, or promotions

Tax Handling

• Supports multiple tax rates, applied individually at the sub-product level

• Ensures accurate financial reporting and compliance

Vouchers and Ticketing

• Each sub-product generates its own voucher

• Supports flexibility in redemption, check-in, and reporting

Discounts

• Apply bundle-level discounts in:

  • Percentage

  • Fixed amounts

Integration and Limitations

Channel Availability

• Available in: Prioticket Full Website Point of Sale

• Not available in: External resellers, Mobile POS, Self-service kiosks

Promo Codes

• Promo codes are not yet supported in bundle products

Product Type Restrictions

• Cannot include: Cluster products or Combi products

• No dependencies between sub-products (e.g., shared time slots)

Custom Ticket Types

• Can be used in bundles but must be added as standard custom by the Prioticket backend team

Reporting and Financials

• Sales & Purchase Rows: Each sub-product is recorded independently

• Tax & Commissions: Calculated per sub-product based on catalog or product-specific rules

• Exports & Reports: Show breakdowns per product, maintaining accuracy across systems

Common Challenges

Comparison: Bundle vs Combi Products

Choose Bundle Products when:

• You need flexibility in pricing, vouchers, and tax per item

• Products can be redeemed or consumed independently

• You want to create a marketing package using existing products

Choose Combi Products when:

• You need a single ticket or experience that includes multiple activities

• You want shared availability or capacity logic

• You prefer consolidated bookings and reporting

Summary

Bundle Products are a powerful tool for creating flexible, value-packed offers that combine multiple existing products while maintaining their individual identity. Ideal for promotional campaigns, gift packages, and upselling strategies, bundles provide:

• Dynamic pricing

• Voucher-level control

• Accurate financial reporting

• Independent availability and tax handling

Proper configuration is key to ensuring a seamless experience for both operators and end-customers. While bundles offer advanced flexibility, they also come with limitations in terms of dependencies and supported sales channels.

Error Handling and Status Codes

The API returns the appropriate HTTP status code for each request, which can be used to categorize the most common types of errors. Some of the supported status codes include:

• 400 (Bad Request)

• 401 (Unauthorized)

• 402 (Payment Required)

• 403 (Forbidden)

• 404 (Not Found)

• 405 (Method Not Allowed)

• 406 (Not Acceptable)

• 409 (Conflict)

• 418 (I'm a teapot – yes, really!)

• 422 (Unprocessable Entity)

• 429 (Too Many Requests)

• 500 (Internal Server Error)

• 502 (Bad Gateway)

• 503 (Service Unavailable)

• 504 (Gateway Timeout)

For additional details, you can refer to the error, error_description, and errors fields in the response for a deeper understanding of the issue.

Common Error Causes

• HTTP 400 errors: These typically occur when a request is missing a required parameter, includes an unsupported parameter or value, repeats the same parameter, or has a malformed structure. Most of these errors return the INVALID_REQUEST code, with additional details in the errors array.

• HTTP 422 (Unprocessable Entity): This error is often caused by a semantic (logical) issue, indicating a problem within your integration (e.g., a mismatch in expected values or business logic).