Qodex.ai

Prio Distributor API V3.5

Number of APIs: 35

Interface Specification

Uptime Uptime Robot ratio (30 days) Maintenance Security Headers

Run in Qodex

Warning

This product is in Beta.

Beta features are ready for testing and production use, but there are no SLAs or technical support commitments provided for these.

Description

This document describes the Prio Distributor 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.

The Prio Distributor API can be divided into four parts: * Content APIs: Exposes our product inventory such as Destinations, Categories and Products. * Availability API: Most products have have limited capacity or require you to select a certain time. The availability API returns those slots. * Reservation APIs: The reservation APIs allow you to block / reserve a ticket for a limited time so that you are able to obtain the payment from the guest. Furthermore it allows for managing a shoppingcart if needed. * Booking APIs: The booking APIs allow to confirm reservations, make direct bookings and retrieve your tickets / barcodes.

Additional APIs are: * Authentication APIs: Most API requests require valid credentials, these credentials can be obtained using the Auth endpoints. * Payment APIs: Most B2B resellers manage payments themselves and are afterwards invoiced for their purchases. In case you want to make use of the existing Payment Service Provider integrations of Prio you can use the Payment APIs. * Contact APIs: Advanced APIs to handle guest information, only applicable for recurring guests. * Notification APIs: Configure webhooks to support asynchronous bookings and get notified of external changes.

* System APIs: Monitor API Health and Uptime.

Functionalities

Below you can find a complete list of API supported features. Short List

Full List

Getting Started

Integration Process

To facilitate our partners in the best possible way we recommend to follow our integration steps and the process as described below.

Integration Stages

Qodex

Qodex is a very popular tool for API development. Luckily Qodex now has support for OpenAPI, which means you can import this whole API as a collection in a few steps. For more information check: Working with OpenAPI. Our API definition can be found here.

Download below a fully prepared example with environment variables:

Run in Qodex

Formats

### General

  • All data should be in the UTF-8 character set.

  • Currency codes are sent in the ISO-4217 format.

  • Language is defined in the ISO-639-1 format.

  • Amounts and values should follow the international standard. Rounding might be required.

  • All data fields are case-sensitive.

  • Optional parameters that are not set or left empty will not be returned in the response. All optional parameters are nullable to support serialization.

### Date / Time

Points in time are expressed as strings using the RFC 3339 datetime format. We always expect the local time with its UTC offset.

Examples

Headers

#### Authorization

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

The API Key Token information for the sandbox 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

#### Idempotency

The Prio API supports idempotency, allowing you to retry a request multiple times while only performing the action once. This helps avoid unwanted duplication in case of failures and retries. For example, in the case of a timeout error, it is possible to safely retry sending the same API Create Order call multiple times with the guarantee that the order will only be created once.

This API supports idempotency on POST requests (other request types such as GET, DELETE and PUT are idempotent by definition).

#### Content-Type

The Content-Type should be application/json.

#### 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-Machine-ID - Identifier of your machine.
  • App-Flavor - Flavor of your application.
  • App-Reference - Reference of your application.

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.

Product Configuration

### Product types and classes

Each product contains product types. These product types can offer aged based ticketing (such as Adult and Child), but also provide a variety of other flexible product variations such as group pricing, business and economy seating or different car configurations.

Because some products might behave different from others, each product type is categorized within a product class; a group of products that behaves similarly.

Product Definitions

Product admission types

Some products require the guest to select a day or time during the booking process. Depending on the type of admission this calendar / datetime picker can have several restrictions.

Below you will find the most common types of admission.

Admission Types

Pricing

Different pricing configurations can be set depending on the product type (product_type), age group (product_type_age), booking quantity (product_quantity_pricing), season (product_seasonal_pricing), daily pricing (product_daily_pricing) and custom / time-based pricing (product_dynamic_pricing).

All prices are given per product_type, per season (product_seasonal_pricing:true). Every possible variation to this price is given as either a discount or surcharge. The newly calculated price is returned in both the Reservation and Order API.

TIP: To check whether you have implemented all logic correctly, it is advised that you cross-check the returned prices in the API with your own.

### Translations

This API supports multilingual content.

All translatable fields can be found inside the product_content object.

Normally the returned content would default to the product_default_language, which is commonly English. Would you wish to retrieve more languages, those supported for that specific product can be found inside product_content_languages.

One of the language codes in the above array can then be sent within the original request in the URL as &product_content_language={language_code}.

### Pagination

Please be aware that some datasets can be bigger than others. The size of your inventory varies depending on your catalogue setup. Pagination is supported on endpoints for which potentially thousands of records can be expected. To retrieve the full dataset we recommend implementing the paging rules.

This only applies to partners which process considerable volume.

Errors

The API will return the appropriate HTTP status code for every request and this could therefore be used to categorize most common types of errors (e.g 400/401/402/403/404/405/406/409/418/422/429/500/501/502/503/504 are supported).

Additionally, the error, error_description and errors field can be consulted for more detailed information on the problem. * Generally in case of a HTTP 400 status the request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed.

Most HTTP 400 errors are returned with the same error code (INVALID_REQUEST) and include more detailed messages within the errors array.

  • A HTTP 422 (Unprocessable Entity) is most likely caused by a semantic (logical) error and indicates a problem within your integration. > Please note that in the future more specific error- and HTTP status codes might be added. Therefore consider all status codes between HTTP 200 and HTTP 300 as successfull responses, and every HTTP 400+/500+ as errors.

As our API has over 1000+ unique error codes (grouped by HTTP status). We discourage implementing individual errors on your customer front-end interface and suggest a catch-all clause for each HTTP status code instead.

Using the interactive documentation

This is an interactive documentation which allows you to experience the API first hand without writing any code. To start calling Endpoints, first Authorize yourself by using the button below. Fill in the default sandbox credentials or the credentials received by your Account Manager.

Default Sandbox Credentials: * API Key: Currently the API Key is only enforced on the Production Environment. * clientid: demo-distributor@prioticket.com * clientsecret: NpEZ&x4QBQV6#L&v * distributor_id: 501

After the authorization is successful, all subsequent calls will automatically contain the Bearer token.

OpenAPI Specification

Read-Only and Write-Only Properties

Please note that some schemas are being reused multiple times, across endpoints but also between requests and responses. readOnly properties are included in responses but not in requests, and writeOnly properties may be sent in requests but not in responses. Furthermore because all response types are JSON, the order in which the parameters are sent is not relevant and for documentation purposes might change over time.

More info on this topic can be found in the Open API Specification

Deprecation and upcoming changes

Due to limitations on our interactive documentation we list current unavailable methods as deprecated. Note that these are not actually deprecated, instead they will be added in the future. You can safely ignore these parameters as they affect either new or obsolete functionality for services that do not apply nor are within the scope for your current integration.

Furthermore, in case you are viewing the latest version available, continuous amendments to both the documentation and the API can be expected. This means we are constantly adding new functionalities and parameters to the same API version, as long as these are deemed non-breaking and backwards compatible. In case any breaking changes need to be made, a new version will be introduced. Please note that the syntax of upcoming (not yet released) functionalities might be subject to change.

Advanced functionality

Across the documentation Advanced Functionality can be found. This type of functionality requires a deep understanding of our system and implementation is not required to fully integrate on our API. Contact your account manager in case you would like to implement advanced functionality.

Libraries

Because our API definition is publicly available you can use several open-source tools to generate client libraries. Please note that these libraries are auto-generated and should be considered Alpha releases. Backwards compatibility is not guaranteed and as this is a third-party tool we can not offer any assistance. In case you find using a SDK helpful we recommend to use the Open API Generator.

PrioTicket Confidential

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

Contact Support: Name: API Support Email: api-support@prioticket.com

  1. orders-{order reference} - Get Voucher GET {{baseUrl}}/orders/:order_reference/voucher

  2. system - Get System Ping GET {{baseUrl}}/system/ping

  3. system - Get System Status GET {{baseUrl}}/system/status

  4. products-{product id} - List Product Details GET {{baseUrl}}/products/:product_id

  5. notifications - Create Notification (Example only) POST {{baseUrl}}/notifications

  6. reservations - Create Reservation / Create Cart POST {{baseUrl}}/reservations

  7. orders-{order reference} - Order Details GET {{baseUrl}}/orders/:order_reference?cache=false

  8. products-{product id} - List Product Availabilities GET {{baseUrl}}/products/:product_id/availability?from_date=2021-06-28

  9. products - List Products GET {{baseUrl}}/products?distributor_id={{distributorID}}&product_id={{ProductID}}

  10. products - List Product Locations GET {{baseUrl}}/products/locations