The time frame is early 2019, and after 20+ integrations with diverse reservation systems across the globe, we decided that a course direction and possibly a brand-new approach were necessary.
In this post, we share the technical journey of our latest API as well as insights from Livn CTO, Hans Jagla. He brings nearly 40 years of experience in software development, technology, and the travel industry to the table while overseeing the API project rollout from start to finish.
Why Release an Enhanced API?
The tours, activities and attractions sector is moving to embrace real-time availability and bookings, and as a result, product structures and pricing configurations are also becoming more dynamic.
Base products can have multiple selectable variants, such as different start times or durations, pick-up locations, and optional add-ons ranging from scuba gear hire for a dive trip to catering to diverse dietary requirements for the local pub crawl.
We are also seeing the emergence of non-linear pricing, meaning the final price will depend on variables such as group size, with discounts applied at the discretion of the tour operators. Some reservation systems provide transparency by publishing the rules behind dynamic group discounts and returning itemised price details making up the composition of the sale price total, while others return the new final amount with no information about its calculations to get to the figure.
Speaking on the reservation systems’ adaptability, Hans shared how they can impact connectivity, saying, “With tour operators demanding product features that best suit their individual business model, reservation systems increasingly opted to introduce user-defined fields in their applications. This practice resulted in a lot of free-text and unstructured blob storage of data. These text descriptions are virtually impossible to consume and interpret in a machine-readable context.
“Clearly, the ‘one rigid structure, one workflow fits all’ approach was not going to age well into the future. So, the task in front of us took on form,” he added.
The Mandate
We wanted to create a solution that accomplished three things:
1. Make Livn the API of choice
Not by claiming to be the turnkey for every business scenario but by guaranteeing that our API caters for a wide range of organisations. Livn technology is designed to keep up with the ever-changing connectivity landscape observing best practices and being compatible with common and emerging standards. We wanted to connect to a diverse array of global reservation systems driven by customer demand and provide a full-service solution from product identification/selection to a confirmed booking.
2. Flexibility
To allow complex product configurations to be added and return structured, machine-readable data in payload responses. This decision allows the business to explore other verticals like attractions, well-being, and live events.
3. Promote internal efficiency
A single source of truth thinking evolved around data duplication and data waste by not creating/storing/removing a calendar time entry for every possible product permutation.
We intended to make life easier for the procurement, content, and quality assurance teams by providing them with all reports, data insights, and sorting features required to do their job.
We also wanted to provide additional metadata for User Interface (UI) designers, enabling them to create reusable components for implementation.
“In a nutshell, we envisioned building an API that is true to its mandate and specifications. One that is well documented, easy to work with, and provides real value to our integration partners,” says Hans.
The Approach
Tackling this mandate meant providing a unified booking flow experience based on the concept of a check-out wizard and asking questions - or follow-up questions - if required until we reach a documented and confirmed booking.
Hans goes on to explain what this looks like in practice by saying, “Much like your friendly travel agent would ask you questions to pinpoint the right product for you and have all the information on hand, ready to book. If you subscribe to the concept that detailed questions and answers remove redundant information and thus improve efficiency and accuracy, welcome to the Livn bandwagon!”
A new perspective on data organisation
To make this a reality, we divide the data into three separate buckets:
- Emotional Decision-Making Data - We think of emotional decision-making data as tour descriptions, images, location information (geocoding), price and itineraries. This data is usually surfaced in front of the end customer to help them narrow down their choices based on the key features of the products. This data type is relatively stable and perfectly suited to be cached and replicated.
- Booking Flow Data - Once the customer has selected a product and is ready to book, we start the booking flow data. The objective is to create a booking in the shortest possible number of steps. The flow needs to adjust to the product, for example, to account for the differences between a fully customisable tour compared to a theme park entry.
- Ticketing/Sales Data - Upon completing a successful booking, we end up with the ticketing data. The ticketing data object contains all booking details, including start times, prices, terms & conditions at the time of sale, and cancellation rules if they exist. As well as being used for creating tickets and vouchers that are passed onto the participant (PAX), the ticketing data is also well-suited for consumption in CRMs, middleware, and accounting applications.
Tackling the dynamic booking flow
The concept of a dynamic booking flow can present some challenges for integration partners with established legacy systems that come with strictly defined booking journeys.
In our philosophy, it is too restrictive to determine upfront which bits of information (questions) are required for every product. A predetermined static design approach of customer input fields will lead to complications further down the track.
A good example is a helicopter tour, where the passenger's weight is mandatory information for the balance of the aircraft. It wouldn't make sense to ask passengers for their weight as they make bookings other than the helicopter ride. The solution is to handle the dynamic aspect of those questions and answers in the UI and aim for a reusable component approach in the UI implementation.
Our data contains all the necessary pointers UI designers can use to build responsive, validated, and interactive UIs. For example, our question object comes with "purpose" and "answerType" fields. The purpose field helps clients who capture PAX details as part of their greater application to map this data and enable pre-population of form fields, answer suggestions or auto-complete input values. The "answerType" is used to control the type or format of the answer.value expected in response to a question. Alternatively, you could handle the questions and answers on the server side and not in the UI.
You can find more details in our API documentation.
The Result? Our Enhanced API
Having gone live in December 2022, one of the biggest selling points of the enhanced API is that it caters for complex product configurations that are futureproofed as you develop.
Reservation systems evolve and change
Livn monitors its 20+ integrated reservation system’s API definitions and implements necessary code changes as required while not introducing breaking changes to the Livn API endpoints. This means that once you have received approved certified status, you can rely on the stability of your implementation and lower application maintenance costs.
Ease of use
We designed our API with "wide range useability" and "ease of" integration in mind. Providing this type of metadata not only helps UI designers but also helps with test automation which is something to consider when looking at futureproofing your application.
Livn's data guarantee
Not all reservation systems offer the same information, and that’s why the Livn content teams ensure our products provide the promised metadata, such as geolocation, at least three images, and more. This means all products will behave identically regardless of which reservation system or tour operator they originated from.
Well documented
Non-existent or incorrect documentation can be annoying and hinder productivity, which is why we set out to be different. We have published a very comprehensive developer guide that explains in detail how our API works and how best to use it.
We also documented every class and model in our API. This makes it straightforward to generate stubs and clients using Swagger Codegen or any OpenAPI code generator you prefer. So, creating an API client from scratch is easy and quick.
Speaking on the API result, Hans shared, “I’m thrilled with the result, and it’s a testament to how hard we’ve all worked to make it happen. Our enhanced API is easy to consume, implement and use. It caters for many product types and provides reports and data insights. We have created a robust, sophisticated, scalable, and enterprise-ready solution for our customers. Which is exactly what we set out to do!”
To learn more about how the Livn API can help your business to scale, get in touch today: https://livn.world/contact-us
