Route Lists, Routing, Airports and Cities
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)
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'). The response may contain airports of different cities that are relevant to the user search e.g. VIE will return BTS airport since it may result in a cheaper option for the traveller.
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.
The response will contain XML of the following format:
Please see the detailed specification for a full explanation of the GetAirportsData request and response.
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.
The response will contain XML of the following format:
Please see the detailed specification for a full explanation of the GetCitiesData request and response.
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 (email@example.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:
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:
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 -------------------
This command is deprecated. Please use ListSupplierRoutes above.
The response will be of the following format:
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 Descriptor 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)
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.
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
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.