Enrich your booking flow with personalized travel rules.
Sherpa provides personalized travel rules to travellers based on their itinerary and traveller profile. Let's see how to display this information with a single API call.
This new improved Trips v3 API will help to simplify the process of displaying travel requirements data for a single trip. In the new API, we introduce a new concept which is Travel Nodes.
Display personalized travel rules for a traveller going on a round trip from A to B. This information can be displayed during a search or after a booking is made.
We strive to provide a simple, convenient and understandable experience for travellers. Complex scenarios depend on two factors: who you are as an individual traveller and your itinerary. Our v3/trips endpoint takes that information as an input and provides you with a structured way to create custom user interfaces.
In this tutorial, we are taking a one-way trip as a fully vaccinated traveller with a Canadian passport, going from Toronto, Canada (YYZ) to Vietnam (SGN).
Both data points are highly relevant as they provide a personalized experience.
In case you might not know the passport a traveller is travelling with, we recommend assuming the nationality of the origin. In our example, it would be "Canadian" for travellers starting their journey in Canada.
We recommend that you provide your travellers with the ability to specify their passport, as well as their vaccination status, as these can drastically change the travel requirements that apply.
The following example shows the JSON payload that has to be formalized as an API request.
Looking at the API response returned from the v3/trips
endpoint, we can find all relevant information required to show the Summary banner.
To find the Trip Summary, we'll be leveraging the attribute data.attributes.headline
.
Each individual segment provides you with a summary of travel rules, which are grouped under various categories. Restrictions and Procedures might find their way into multiple groupings.
For the user interface on our WebApp solution, we opted to group multiple groupings together to further simplify the flexible API response.
The new Trips v3 provides simplified groupings that you can retrieve data and display directly on the front end. All of the groupings are organized by location name under "informationGroups". Under this group, you will find data for each segment such as Travel Restrictions
, Visa Requirements
, Quarantine
, COVID-19 Testing
, Vaccination / Immunization
, Other Documents
, Additional Information
, and Upcoming
with their tooltip if it exists. The naming & tooltip are already translated into different languages.
For displaying restrictions for procedures for each segment, we can find that information under data.attributes.informationGroups[x].groupings
.
An object of type grouping may include a list of the same type (grouping[]) as
the value for the optional parameter groupings.
This means that to get the first restrictionId in a particular information
grouping, you might need to look at
informationGrouping[x].groupings[0].data[0] or you might need to look at
informationGrouping[x].groupings[0].groupings[0].groupings[0].data[0]. While
there are no technical limits on the number of allowed nesting layers, we will
keep this structure limited to a maximum of 5.
This nested structure allows us to be flexible in delivering the hierarchy of
information without changing the API response format. While this example
currently looks at data sorted only based on grouping, it is vital to make
sure that your application can handle the nested structure of groupings. For
more information, look at this
In this example, data is also grouped by location, so it'll easier to show the restrictions that belong to a specific location without further transformation.
Displaying an all-in-one checklist for all the required documents can be seen by looking at the groupings with the type DOC_REQUIRED
.
This grouping list will include all documents related to visa requirements, COVID-19 testing, as well as various other types of documents.
In the new API, Round trips can be retrieved by sending another request to v3/trips
endpoint. It will be entirely new travel nodes and be treated as a separate trip.
The API response will be the as the departure trip. We can apply the same strategy of mapping the response to a user interface to the return segment as well.
Trips v3 supports up to 3 transit nodes.
Below is an example payload of a trip with two transit nodes (Seattle & Seoul).
The full itinerary is: Washington (IAD) -> Seattle (SEA) -> Seoul (ICN) -> Da Nang (DAD).
The response of /v3/trips
includes procedures and restrictions that apply to a particular trip, organized in data.attributes.informationGroups
as a list. Each InformationGroup
object has a property called groupings
that is a list of the type Grouping
.
It is important to note that each grouping again may have a property named groupings of type array Grouping
, so it is essential to navigate this object recursively to not lose any data in case the API response part that contains procedures & restrictions are nested for multiple level.
Here is a sample code that can render the information in a particular Group
on a frontend component
A working example of such a function is used here to display all visa requirements.