After our Travel XML API XX1 has been a uniform, stable and high-performance XML interface for all Global Distribution Systems (GDS) and other multi-source providers since the year 2000, the intelligent XX1 (iXX1) thus goes one step further.
Why use the PASS Travel Web API iXX1?
The process of shopping is simplified and trip proposals offers are provided with travel policies and personal preferences from the outset and reduced or narrowed down to the essentials based on predefined criteria to simplify choice. The travel booking (also: Passenger Name Record, PNR) is done via the shopping cart management. All this, including downstream processes such as file finishing and reporting, is centrally defined and managed. All booking tools that use messages from the PASS Travel Web API receive uniform guidelines and data labels - in other words, the content is identical for everyone. The travel booking is supplemented within the remarks according to the specifications of a booking reference typical for the company. In this way, subsequent processes such as middle office, back office, travel risk management or accounting can be carried out without challenges (file finishing). This facilitates and simplifies, among other things, the development of your own booking tool or approval procedure considerably.
In addition to shop, book, exchange and refund processes to all content provider, iXX1 also offers the opportunity of intelligent data retrieval from the GDS and other content provider such as low cost carrier. This no longer takes into account all PNR changes, but only those that are relevant. In the context of “duty of care”, it is important for a travel risk management company to know which travelers should be where and when. A change of seat, for example, is less important than a transfer to another flight or a change of destination, as these entail new risks. The schedule change caused by the airline can also represent an improvement following certain rules, but can also cause a deterioration if, for example, a passenger can no longer reach his sailing cruise or a traveler will miss his connecting flight.
PASS Travel Web API is interesting for all user groups who want to create user interfaces for themselves or their customers, and take advantage to access a simple micro service interface for the complex travel booking world.
- Agency / business travel management: Standardized provision of compressed data or travel policies / file finishing / reporting across all UI applications.
- Technology providers / client applications: Reduction of complexity by eliminating the need to implement travel policy / file finshing / fare detection / marketing messages / reporting fields in the client application. The pure display of the data compressed by iXX1 from the messages is sufficient for the developer to create a sophisticated client application.
- Corporates: All client applications (desktop, mobile, chat bots etc.) only need to implement the iXX1 messages and immediately receive (centrally controlled) identical content with the necessary flags, such as preferred rates or preferred service providers. This centralizes, standardizes and simplifies the control of the booking.
The strict separation of user interface (UI) and business logic provides the advantage that, on the one hand, business logic does not have to be developed again and again and, on the other hand, the UI layer can be flexibly adapted over time. Thanks to a stable travel interface over the years, it is no longer necessary for our customers to constantly revise, replace or adapt their supplier systems.
The integrated state-of-the-art Open Source Rules Engine (Drools) enables our customers to intervene in any process themselves, regardless of the manufacturer (us). The customer thus concentrates on his attractive communication interface with the traveler, while PASS stands for the modern and smoothly running travel technology.
We make sure that the business logic of the complex travel industry works smoothly and that the connection to the travel booking systems for hotels, rental cars, flights and trains is constantly guaranteed. In addition, we offer connection to the following backend systems:
- Multi-GDS: Amadeus, Sabre, Travelport's system Worldspan, Galileo/Apollo, uAPI
- IATA's New Distribution Capability (NDC), e.g. via Farelogix, but also own developments of airlines or Travelfusion
- Cheap airlines – also known as low-cost carriers (LCC), e.g. via Newsskies directly or aggregators such as Travelfusion, Amadeus's Extended Air Choice (EAC) and Pyton direct or Travelport's Airline Content Hub (ACH)
For communication between UI applications (including all possible forms of communication with the end user) and the standard web service APIs of GDS and other travel service providers, a typical booking with a search/book ratio of 5:1 requires at least 23 messages (request/response messages), some of which have a significant number of attributes. In the case of multi-source providers, the number multiplies accordingly.
With our SOAP interface (XML) XX1, the number of messages is already reduced to 18: One message each to receive the traveler's profile – both the personal profile and that of the department. Five flight enquiries each incl. pricing. Then the booking and about five further file finishing messages are created in order to provide middle-office-, back-office- and company-relevant information. However, the messages themselves still have a significant number of attributes and combinations. The result is therefore still very comprehensive.
With our iXX1 web interface, services are provide, where only 7 to 11 messages are required, some of which no longer have any attributes, since communication between the UI application and the iXX1 API takes place via identification codes only, making the messages considerably leaner. Of course, you will still need the full range of the shopping engine (the Sabre Bargain Finder Max returns up to 200 flight combinations, for example), but these can be pre-probed with rules. As soon as the client application has received an offer for which the traveler decides, only UUID (universally unique identifier) similar unique identifications are communicated with the web interface of PASS. For example only the following is communicated: "Book flight number 3" instead of "Book flight number LH 462 from Frankfurt to Miami at TT.MM.YYYY etc. “. This is an example for microservices. The complex services, such as search, book, shopping cart, exchange and refund processes etc., consist of a varying number of microservices. Each microservice groups together a certain amount of complexity and thus simplifies the programming of a UI enormously.
The user searches for flights from A to B using an online booking tool. Through iXX1's integrated rules engine, the Travel API tool recognizes which person is traveling and can retrieve the company's profile data, policies and preferences. This information is used to optimize the request to each content source in a way that best results will be retrieved to meet company goals as well as personal preferences. Afterwards the appropriate travel results are filtered to improve the results even further. The rules engine processes all specific "if-then" relationships. The simplified result is then made available to the shopping engine and displayed to the user. As soon as the user places a flight in the shopping cart, the shopping engine only has to provide the specific, unique ID. The transmission of large amounts of data is therefore no longer necessary. The Travel API tool then performs the entire file finishing according to the previously defined rules.
In addition to the XX1 services, such as
- Shop, book, exchange and refund workflows,
- Profile management,
- Airline, hotel and car rental management as well as
- PNR or offer and order management
iXX1 provides the following services:
- Offer service: allows the user to select separate offers from the results and compare them (mix & match)
- Enrichment of data via additional content providers
- Dynamic selection of travel source providers and offers based on the specific needs of the customer (corporation, unit and traveler)
- Reference system for airports including geodata, airport size, world region via Cirium (formerly Flightstats) and railway stations (incl. EuroStar)
- Overview of the in-flight amenities with data from Routehappy
- Additional services for low cost carriers, NDC direct connect, Newsky (e.g. Eurowings etc.), optional payment fee (OPC), exchange rates
- Multi-source shopping and booking service incl. Super-PNR management
- Combined one-way flights2
- Integrated business logic for complex third-party systems3
- Destination management4
- Simplified and cached communication between travel provider and application
- ID management: simplified data handling with UUIDs
- Background services: itinerary, booking confirmation, appointment data
- Class Mapper: Assignment of Class of Service (CoS) to cabin based on airline and route planning
- Ready-to-use shopping cart management: request offers, add an offer to the shopping cart, order shopping cart
- Profile rules (agency, company, traveler)
- General sales and marketing rules
- In/out policy flags: Notice to supervisor if booking is outside travel policy
- Automated PNR quality inspection/file finishing (PNR compliant)
- Automated ticketing including quality control via the rules engine
- Data classification: sorting and filtering of results
- Dynamic addition of contractually agreed tariffs and other request data based on the source
Special iXX1 services:
1Error related services
Error normalization and translation:
The partly non-transparent error messages of the third-party systems are normalized and mapped to predefined error codes in iXX1. If desired, the additional error texts can be "translated" into layman’s terms and/or customer-specific recommendations for action for the end user.
No empty result service:
This service avoids empty results from 3rd parties. Errors are not only cleaned up, it is also automatically reacted to certain errors. For example, a function can be configured that attenuates a too restrictive query and automatically resends it if the first result is empty. Example: Flight enquiry Munich - Los Angeles 9.00 a.m. +/- 2 hours with Lufthansa. In this case, the result would be empty, since the LH flights do not start until 12.00 noon. If iXX1 receives the empty result, another query is sent immediately and the time limit is removed. Then the system outputs the new result with a hint that the time window has been removed, otherwise no results would have been found.
2Combined one-way flights
In addition to defined round trips, which are offered and priced by GDS, our intelligent iXX1 also includes relevant single flights (one-way) from all connected systems, combines them and compares whether you can get away cheaper. For each outbound flight, the possible return flight combinations from different systems (e.g. outbound flight via Amadeus and return flight directly via Eurowings and all cross products of all providers) and the average price range from the cheapest and most expensive flight combination are determined in order to obtain the best combination. The Travel Policy shall apply accordingly to these possible flight combinations. (Note: Due to the Point-of-Commencement problem, we do not offer combined one-way prices for two one-way GDS flights).
3Integrated business logic for complex third-party systems
In addition to message content, the behavior of third-party systems is normalized for the client application, further reducing their complexity without sacrificing performance. An example of this is 4destination management: Some content providers expect that before a connection is queried, the system checks whether the respective airline is flying to this destination at all. Only if this is the case may the source be queried. iXX1 automatically performs this preliminary check in the background. The client application does not require any knowledge about flight routes or the route network of the respective airline. Another example is the Branded Fares Test: Similar logics ensure that unnecessary queries and waiting times for the client are avoided. Certain tariffs (e.g. branded tariffs) are already checked in the background for certain workflows and the client application signals whether it makes sense to query them. The branded tariff and upsell query can be waived if iXX1 has already determined in the background that there is none for this connection.
Simplified communication and workflows (Result ID), Super PNR management, service for multi-source (incl. distribution control service), shopping cart management, offer management, multilingualism
Further additional data
Integrated PASS or external data platform, profile database, rules engine (e.g. policies, compliance PNR etc.)
High transaction speed
Selected data caching, ID management, performance
Travel service provider: Global Distribution Systems, Low Cost Carrier, Direct-Connect (e.g. NDC, car rental, hotel)
- Loading and saving profiles (traveler and company)
- Apply business rules and corporate policies
- Marketing such as a reminder “Missing hotel booking” or a remark for a special condition such as “One complementary bottle of water per day included"
- Application acceleration due to caching incl. the option to immediately react to event or display of history
- Loading, sorting and filtering shopping results
- Show all available results (e.g. "Show me later flights")
- Separate display and business logic
- Intelligent middleware for all user interfaces (including robotics)
- Applying file finishing rules
- Simplification and high performance: The customer developed user interface does not have to deal with the complex business logic of travel. The user interface only communicates with iXX1 via UUID-like IDs
- Requires significantly less travel-specific specialist knowledge
- Maintenance and servicing of travel interfaces no longer necessary
- Resource savings through ID management and microservice architecture
- No interface barriers: iXX1 can optionally be delivered with an easy-to-use client, which is integrated into your App
Decision maker / Management
- Focus on the user interface instead of content procurement and aggregation
- Fast time to market
- Cost reduction
- Independence from suppliers
- Create your own Emotional User Interface Experience (eUIx)
|per booking (PNR)*||per iXX1 transaction*|
|Suitable for||TMCs/Company/Technology provider||TMCs/Company/Technology provider|
|Type of use||Booked PNR||Transaction pair: request/response|
|Is maintenance necessary?||Yes, in order to have Service Level Agreement (SLA)||Yes, in order to have Service Level Agreement (SLA)|
|Is an installation necessary?||Yes||Yes|
|Advantages||Proven price model, direct offsetting against the PNR||No Look-to-Book necessary|
|License prices (excl. Hosting)||$0.15 - $0.50 per PNR**||$0.00x - $0.03 per iXX1 transaction|
There are three major global reservation systems (GDS) in the travel industry: Amadeus, Sabre and Travelport. Originally, these reservation systems connected together to the reservation systems of the airlines via the EDIFACT data standard. Today, New Distribution Capability (NDC) is is likely to replace or complement this EDIFACT pipeline. Since the year 2000 PASS offers a unified interface based on XML to all major global reservation systems. Today, manageable, convenient services that can be integrated easily and quickly are the preferred alternative to XML data standards for interface developers. Also with regard to trend-setting travel technology it is important for us to keep up with the times. So while the technology is evolving towards microservice architecture, the travel industry is working in the opposite direction with large cumbersome XML messages. With NDC, whose first version was even based on the PASS XML Schema, this becomes more complex. An example of this is the scope of the Air Shopping Message, which displays the cross product of all possible combinations. With our approach we want to create the technological link between the complex world of the travel industry and the fast-paced world of user interfaces. Thus, iXX1 makes front-end development easier and offers the opportunity to create innovative interfaces in a flexible and convenient way for the travel industry.
Compared to the round trip times of the GDS, the time loss of our iXX1 of some 100 milliseconds is not noticeable at all. However, this depends on the underlying rules: How are they defined, how many rules are involved (basic rule set and rules are the responsibility of the customer) and how quickly is a result played out? The meaningful application of rules for the selection of individual travel offers in multi-source operation can only take place after the options of all providers have been received. This means that the system has to wait for the slowest third party system and can only then apply its rules. However, a rapid preliminary provisioning of results can take place, which is made available to the User Interface. After that, fine sorting can be carried out in the background.
Currently we offer a SOAP interface without business logic with XML (XX1) and a web interface including business logic with XML (iXX1) to all travel providers. It is planned to extend the Travel Web API iXX1 to a REST-based API (JSON, etc.) in the future. Currently, iXX1 is based on our XX1 schema to remain backward compatible with our current XX1 customers. You will find the same procedure with all other travel service providers. For an intelligent business application it is important that almost 100% of the functionalities are integrated into a travel interface. In the backend, we often even use cryptic messages from GDS to provide functions that are only available in cryptic format in third-party systems (GDS). Thus, our customers can use this functionality as usual in a structured way.
Yes, iXX1 is used by, among others, the world's second largest TMC (according to "The Beat"). Previously, this customer had only used XX1. Furthermore, all our own GUI applications are based on iXX1 and thus on the intelligent separation of GUI and business logic. The world's largest independent agency franchise also relies on a flexible GUI from PASS and iXX1 with its agent solution. We have migrated our existing installations step by step to this microservice architecture. However, we are not a company focused on mass production, but offer our customers individual products based on reusable components.
Can the intelligent Travel Web API only be used for special business travel software or also for other booking systems?
The Travel Web API is suitable for all those who do not want to use a sublicensed "off-the-shelf white label complete solution", where only the design is changed and the solution of customer A works the same way as the solution of customer B. With iXX1 you can either completely design and create your own solution (without special travel know-how or countless business logic programming) or you can have PASS provide you with an interface.