Platform Overview

Guestlogix provides a platform for airlines to optimize ancillary revenues and increase traveler loyalty throughout the entire journey. The Travel Commerce Platform leverages machine learning and AI to provide travelers with highly personalized offers from within an airline’s existing mobile app. The company’s approach to the travel experience transforms how airlines provide value to their passengers and empowers them to become better retailers. Guestlogix’s roots are in onboard retail and payments, this new platform streamlines the management of offers for ancillary revenue teams and enables them to provide travelers with the products and services they are looking for at every phase of their journey, from planning through to the end of their trip. The platform is offered via API, iOS and Android SDKs  A web-based Management Console supports all 3 giving configuration, support, reporting, and analytic insights to your business.


NOTE: A pre-requisite to interacting with the Guestlogix SDK or API is that you are a Guestlogix Partner and have obtained a Sandbox or Production API key. Please contact your Customer Success Manager, or Contact Us if you have questions regarding this.


Stakeholders

The documentation is grouped by the stakeholders for which Guestlogix has developed tooling. All stakeholders are serviced from a common backend, however, the resources and actions vary between them. This tooling is predominately comprised of RESTful APIs and Mobile SDKs. The stakeholders outlined are:

  1. Partner - See Overview

  2. Traveler (Client) - See Overview

Development Environments

The Guestlogix's platform is multi-tenanted, and therefore no separate provisioning of environments are required. The platform is ultimately separated into two main environments for both initial integration and testing, and full rollout:

  • Sandbox - Contains a subset of the Guestlogix catalog data that enables implementing developers to get a feel for the types of content available and the technical workflow that will be experienced in the production environment. Payment made through the Sandbox instance will not result in legitimate bookings or billing charges.
  • Production - The production environment is intended for use when deploying the Guestlogix-augmented app to real users looking to utilize the breadth of content the platform has to offers. Purchases made through the Production system will result in legitimate bookings and full credit card charges.

For more information, please see the full Development Environments article.


Authentication Methods


As a Guestlogix partner, you are supplied with the following keys:

  • Publishable Key - Used in relation to the Traveller stakeholder listed above, and can be included in client-side source code, and is used to both uniquely identity, as well as authorize access to Guestlogix resources.
  • Secret Key - Used in relation to the Partner stakeholder outlined above, and is strongly recommended to not be included in any client-side source code. It is only to be sent to Guestlogix servers in a server-side pattern.



When utilizing the Mobile SDK, authentication is handled automatically through the use of your Publishable Key and requires no further configuration. Alternatively, the Client API and Partner API utilize JSON Web Token (JWT) based authentication to facilitate Create, Read, Update and Delete (CRUD) operations. 


An example utilizing the "/auth/token" endpoint to obtain a JWT based Bearer token:

curl -X GET "https://traveler.guestlogix.io/v1/auth/token" \
-H "accept: application/json" \
-H "x-device-id: 123456" \
-H "x-os-version: iOS12.1" \
-H "x-language: en" \
-H "x-locale: en-US" \
-H "x-region: CA" \
-H "x-application-id: com.guestlogix.Passenger" \
-H "x-timezone: UTC" \
-H "x-sandbox-mode: true" \
-H "x-api-key: [YOUR-PUBLISHABLE-KEY-HERE]"


Mobile SDKs

Guestlogix's offerings are made available by implementing native iOS and Android SDKs and come in three tiers, to allow maximum customization.



Core (TravelerKit)

This layer is the main API layer that is used to fetch catalogs, item details, all the way to placing an order and making a booking.

The core layer uses a facade object serving as a front-facing interface masking a more complex underlying codebase. This makes it easy and consistent to integrate on multiple platforms.


UI (TravelerKitUI)

This layer will contain helpful UI components as well as entire flows for your convenience and ease of integration. We highly recommend using as much of these flows and UI elements as possible for the best user experience.


Stripe Payment Provider

In order to facilitate collection of payments, we currently only support Stripe, and as such have bundled all our Stripe integration components into one SDK to alleviate the developer from having to go through that process. 

For class-level developer documentation, see Android Reference, and iOS Reference.


iOS SDK Implementation Walkthrough Video Examples:

  • Part 1 - Setting up the Guestlogix SDK, and implementing the Catalog UI component.
  • Part 2 - Implementing the catalog carousel into an existing view by making it a reusable module.


RESTful APIs

Should tooling for an application need to be built outside of the scope of the native mobile SDKs, requests directly to the RESTful API may be made. 


There are two distinct APIs

  • Traveler API - This represents all resources and actions that an end-user of the SDK would need. Functionality such as browsing a catalog, making orders or viewing flights.

  • Partner API - This represents the global company level tooling that an administrator of an SDK implementation may need. The Management Console provides a user interface for this, however, sometimes it's useful to be able to programmatically administer the tool via the API directly.


Payments

Every payment accepted through the Guestlogix platform is associated with an Order. This can be thought of as a container or 'cart' for all products, tangible and physical, that are part of a single purchase. Multiple payment types for a single order at this time are not supported. Only a single credit card may be used for the entirety of the order.


See the full Payments article for more information on this topic.


Rate Limiting

Each customer application is limited to 10,000 API calls per minute. From our experience, this number of calls is sufficient for the vast majority of airlines. Caching strategies are recommended to both ensure that your application stays within the limit but also to improve the user experience of the app.


More information


Error Codes

Error codes are important to deal with in your deployment. The SDK handles errors gracefully when utilizing the UI Kit, but if you are utilizing Core or accessing the platform directly through the API, please review the list of Error Codes here.