Launching Searches to Travelfusion
It is required that these guidelines are closely followed in order to use the system as efficiently as possible. For the Origin
and Destination
locations, the location should be submitted as follows:
- If the user selected a specific airport: search for only that specific airport by submitting the airport code (a three letter abbreviation such as
LHR
) as the Descriptor
, and airportcode
as the Type
, with a small radius (e.g. less than 1000m)
Example XML
<Origin>
<Descriptor>LHR</Descriptor>
<Type>airportcode</Type>
<Radius>1000</Radius>
</Origin>
- If the user selected a specific city: Submit the city code (a three letter abbreviation such as
LON
) as the Descriptor
and airportgroup
as the Type
(Radius is not necessary as it is ignored for type 'airportgroup').
Example XML
<Origin>
<Descriptor>LON</Descriptor>
<Type>airportgroup</Type>
</Origin>
In any of the following cases, you must discuss and obtain permission from Travelfusion for your solution before implementing it:
- If you do not know whether the user selected an airport or a city (e.g. if you allow them to type in codes like
BCN
as freetext)
- If you wish to submit any
Type
of location other than airportcode
or airportgroup
- If you wish to use a radius greater than 1000m
- If you wish to deviate from the above guidelines in any other way
Airports and Cities
A full list of airports covered by Travelfusion can be accessed using the following request. This request must only be used once per day, and in general this should be during off-peak hours (00:00 to 07:00 UK time). This data must not be sold, redistributed or used for commercial gain in any way without written permission from Travelfusion.
GetAirportsData request
<CommandList>
<GetAirportsData>
<XmlLoginId>***</XmlLoginId>
<LoginId>***</LoginId>
</GetAirportsData>
</CommandList>
The response will contain XML of the following format:
GetAirportsData Response
<AirportList>
<Airport>
<IataCode>LHR</IataCode>
<Country>
<CountryName>United Kingdom</CountryName>
<CountryCode>GB</CountryCode>
</Country>
<City>
<CityName>London</CityName>
<CityCode>LON</CityCode>
</City>
<AirportNameList>
<AirportName>
<Language>English</Language>
<LanguageCode>en</LanguageCode>
<Name>Heathrow Airport</Name>
</AirportName>
</AirportNameList>
</Airport>
</AirportList>
Since a city is specified for each airport, this data can be used to build a mapping of city to airport and vice versa. e.g. it can be determined that LHR airport is related to LON city and that LON city has 5 airports - LCY, LHR, LTN, STN and LGW.
A full list of cities covered by Travelfusion can be accessed using the following request. This request must only be used once per day, and in general this should be during off-peak hours (00:00 to 07:00 UK time). This data must not be sold, redistributed or used for commercial gain in any way without written permission from Travelfusion.
GetCitiesData Request
<CommandList>
<GetCitiesData>
<XmlLoginId>***</XmlLoginId>
<LoginId>***</LoginId>
</GetCitiesData>
</CommandList>
The response will contain XML of the following format:
GetCitiesData Response
<CityList>
<City>
<IataCode>LON</IataCode>
<Country>
<CountryName>United Kingdom</CountryName>
<CountryCode>GB</CountryCode>
</Country>
<CityNameList>
<CityName>
<Language>English</Language>
<LanguageCode>EN</LanguageCode>
<Name>London</Name>
</CityName>
</CityNameList>
</City>
</CityList>
Accessing Supplier Route Lists
Travelfusion can supply information regarding the exact routes covered by each supplier.
This request should not be performed more often than once per day for each supplier. It should be accessed during off-peak hours wherever possible (00:00 to 07:00 UK time).
The GetSupplierRoutes returns large responses on many suppliers. The ListSupplierRoutes returns a much reduced response size data, in a different format.
In general, it is recommended that the new ListSupplierRoutes request is executed and not the deprecated GetSupplierRoutes request. Please get in touch with APISUPPORT (apisupport@travelfusion.com) if you use the latter.
Please note, airports and cities can be mixed within the same request, as long as the airport map contains the relevant entry. For example, if you want to request LHR-airport to BCN-city, you would need to check that the airport map contains LON->BCN cities or LHR->any Barcelona airport.
The routes covered by a particular supplier can be retrieved with a simple XML command of the format:
ListSupplierRoutes
ListSupplierRoutes Request
<CommandList>
<ListSupplierRoutes>
<XmlLoginId>***</XmlLoginId>
<LoginId>***</LoginId>
<Supplier>americanairlines</Supplier>
<OneWayOnlyAirportRoutes>false</OneWayOnlyAirportRoutes>
</ListSupplierRoutes>
</CommandList>
- OneWayOnlyAirportRoutes: is an optional parameter and by default, if the parameter is not present, its value is true. If this parameter is false we return the list of routes separating outbound and inbound (outward and return). When the parameter is true we merge both routes and we only show one of them, please see further details below.
The response will be of the following format:
ListSupplierRoutes Response
<ListSupplierRoutes millis="2063">
<LoginId>***</LoginId>
<RouteList>
<AirportRoutes>
LUXYYT
AEPGIB
BROGGT
NEVYXE
OPOWAS
NUENRT
NTENRT
MTJNUE
....
....
....
</AirportRoutes>
<CityRoutes>
TYOPAR
NYCPAR
CHIWAS
TYOCHI
....
....
....
</CityRoutes>
</RouteList>
</ListSupplierRoutes>
- If OneWayOnlyAirportRoutes is not present in the request or if it is true, the RouteList element does not include the reverse of any routes. i.e. to reduce the size of the airport map, all routes are specified in one direction only and the customer must assume that the reverse direction is also supported by the airline. So if MADJFK is returned, JFKMAD will not be, even though the supplier may support both.
- As an example, if the airline flies both MAD to JFK and JFK to MAD
- If OneWayOnlyAirportRoutes is set to false, the route list will contain MAD to JFK and JFK to MAD.
- If OneWayOnlyAirportRoutes is set to true (or omitted), the route list will contain MAD to JFK and not JFK to MAD.
- The only reason to submit the value as false, is in special cases where the airline is known to fly some routes in one direction only. This case is not covered correctly when the flag is set to true, since the user must assume the reverse direction is supported.
- AirportRoutes is supported searches from airports to airports.
- CityRoutes is supported searches from city to city.
----------- DEPRECATED -------------------
GetSupplierRoutes-----DEPRECATED
This command is deprecated. Please use ListSupplierRoutes above.
GetSupplierRoutes Request
<CommandList>
<GetSupplierRoutes>
<XmlLoginId>***</XmlLoginId>
<LoginId>***</LoginId>
<Supplier>easyjet</Supplier>
</GetSupplierRoutes>
</CommandList>
The response will be of the following format:
GetSupplierRoutes Response
<RouteList>
<Route>
<From>
<Type>airportcode</Type>
<Descriptor>LPL</Descriptor>
</From>
<To>
<Type>airportcode</Type>
<Descriptor>PMI</Descriptor>
</To>
</Route>
<Route>
<From>
<Type>citycode</Type>
<Descriptor>MIL</Descriptor>
</From>
<To>
<Type>airportcode</Type>
<Descriptor>ATH</Descriptor>
</To>
</Route>
<Route>
<From>
<Type>citycode</Type>
<Descriptor>MIL</Descriptor>
</From>
<To>
<Type>citycode</Type>
<Descriptor>LON</Descriptor>
</To>
</Route>
.......
</RouteList>
<LocationList>
<Location>
<IATACode>LPL</IATACode>
<Type>airportcode</Type>
<CountryCode>GB</CountryCode>
</Location>
<Location>
<IATACode>MIL</IATACode>
<Type>citycode</Type>
<CountryCode>IT</CountryCode>
</Location>
......
</LocationList>
<AllowedCountryRoutes>
<Route>
<From>GB</From>
<To>ES</To>
</Route>
<Route>
<From>GB</From>
<To>FR</To>
</Route>
..........
</AllowedCountryRoutes>
RouteList element ------DEPRECATED
This element contains a list of the routes covered by the supplier. If this element is missing, you should assume all routes are covered.
The Type
element will have value either 'airportcode' or 'citycode'.
The Descripto
r will be one of the following:
- A TLA (three letter IATA code for the city or airport)
- '*' indicating that all possible codes are supported (all airport codes if Type is
airportcode
and all citycodes if Type is citycode
)
- '?' indicating that this code can be any of the TLAs appearing in the same placeholder within the rest of the routes list (i.e. if the '?' appears within the
Descriptor
of the From
element, then it can have any of the values of the Descriptors in any of the other From elements in the list. Similarly for the To
element)
LocationList element----DEPRECATED
The LocationList
gives a list of all the TLAs included in the response and the related country codes. In some cases this list will not be relevant and so will be omitted.
AllowedCountryRoutes element----DEPRECATED
The AllowedCountryRoutes
element gives a list of country pairs that the supplier covers. So in the example, the supplier only covers routes From GB to Spain and GB to France. The value of From
and To
may also be '*' or '?' with similar significance as in the RouteList
.
Using Supplier Route Lists-----DEPRECATED
The main purposes of using the route lists are:
- To determine which user searches are relevant to Travelfusion's suppliers, and therefore whether a Travelfusion search should be launched (and for which suppliers).
- To help build dynamic search forms where the origins offered to the user are only the origins supported by the Travelfusion suppliers. (And once an origin location is chosen, the possible destinations offered to the user can be dynamically adjusted to those supported by Travelfusion's suppliers for the specific origin selected.)
In order to check whether a supplier covers a particular route, that route can simply be looked up in the Route List for that supplier. When performing the lookup in the Route List, the location Type
must be considered. For example if the user requests BCN
city to GRO
airport, then the Route List must contain exactly the following XML for the lookup to be positive:
Route + Type Request
<Route>
<From>
<Type>citycode</Type>
<Descriptor>BCN</Descriptor>
</From>
<To>
<Type>airportcode</Type>
<Descriptor>GRO</Descriptor>
</To>
</Route>
The exception to this is in cases where it is not known whether the user selected a city or airport (e.g. if they are allowed to hand- type codes such as BCN
). In this case, both types should be looked up and if both are found, then the citycode should be favoured. Note that if both the user's origin and destination are of unknown type, 4 lookups are needed to cover all the possible type combinations. Please contact Travelfusion if this is unclear in any way.
Route Lists - Details-----DEPRECATED
In principle, the route list for a particular supplier represents all the possible origin and destination location pairs that can be requested from the supplier's system. So it would seem to be a trivial task to look up the user's request in the route list to see if the supplier covers that route. However, the difficulties relate to the fact that a supplier may allow city codes to be submitted, and also may or may not allow the related airport codes to be submitted. Consider the following example:
The supplier 'EasyFly' allows only searches for the following routes:
LON
city (London) to BGY
airport (Milan Bergamo)
STN
airport (London Stansted) to BGY
airport
BCN
city (Barcelona) to MAD
city (Madrid)
REU
airport (Barcelona Reus) to MAD
city (Madrid)
If the user wants to travel from LON
city to BGY
airport, a simple lookup in the route list will correctly indicate that the route is covered by the supplier. However, if the user wants to travel from LON
city to MIL
city (Milan), then the lookup will fail even though the route is effectively covered by flying to BGY
. To solve this problem, Travelfusion could simply expand the route list to include all the city codes related to each airport code. In this case, LON
to MIL
would appear in the route list and so the lookup would succeed.
Now consider a case where the user wants to travel from GRO
airport (Barcelona Girona) to MAD
city. The lookup will fail because GRO
does not appear in the route list - only the related city code BCN
appears. So to solve this problem, Travelfusion could again expand the route list to include all airport codes related to any city codes. However, this would not quite be accurate because in the above example, the supplier does list some of the airports related to Barcelona city, and so we can infer that any other Barcelona airports (such as GRO
) are not covered. So, city codes are only expanded in this way if the route list does not contain any of the airports related to the city.