Travel Web API – intelligent XX1

Travel Microservice Middleware for your travel application

Travel Web API incl. business logic

Intelligent middleware that filters travel content according to individual criteria, aggregates them, applies rules and makes it available via a web interface.

Our Travel Web API iXX1 provides the appropriate, flexible business logic for your user interface and presents travel content according to company-specific criteria using an integrated rules engine. Afterwards, relevant offers are aggregated and again provided with rules, e.g. travel policies, traveler preferences, company specifications, preferred providers, etc. The travel offers are then made available to a user application, such as a graphical user interface (GUI), via a Web interface (Web API). Our intelligent Travel Web API thus already represents a first microservice approach for the aggregation of multi-source travel content, which will be developed into a representative state transfer (REST) interface (e.g. JavaScript Object Notation – JSON) in the future.
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.

Target groups

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.

Simplifying the complexity of travel booking systems in practice

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)

Our travel interfaces and schemas typically provide a stability of five years and more before an update is necessary. Some third-party systems require updates several times a year.

Communication between booking application and reservation system

Complexity and data volumes can be significantly simplified from the standard API via the XX1 API to the iXX1 API

 

 

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.

 

Practical example

Example of a simple travel booking

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.

Range of services from iXX1

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:

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.

Highlights of the Travel Web API

Fast integration

Fast integration

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

Further additional data

Integrated PASS or external data platform, profile database, rules engine (e.g. policies, compliance PNR etc.)

 

High transaction speed

High transaction speed

Selected data caching, ID management, performance

Worldwide access

Worldwide access

Travel service provider: Global Distribution Systems, Low Cost Carrier, Direct-Connect (e.g. NDC, car rental, hotel)

Benefits

Users

Users

  • 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")
Business side

Business side

  • 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
IT managers

IT managers

  • 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

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)

 

 

Usage models of the Travel Web API

  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
Licenses SaaS SaaS
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

*Both usage models require a basic monthly fee of $15,000.

**Average look-to-book ratio per any given calendar month not exceeding 100:1.

Frequently asked questions concerning iXX1

Michael Strauss

PASS Consulting Group

+1 305 269 6975