Travelfusion Direct Connect XML API > Guidelines >

Multi-bound and Open-jaw itineraries

Multi-bound

The Travelfusion API generally only supports itineraries with one or two bounds. A one-way itinerary has one bound (the outward bound), and a round-trip itinerary has two bounds (the outward bound and the inward bound).

However, some airlines support itineraries with as many as six bounds, making it possible to search, price, and book a journey which visits several different destinations across several different dates. Support is being added to selected Travelfusion integrations to allow searches which involve more than two bounds, and this page describes the AdditionalTripList feature which enables this.

Open-jaw

Some airlines permit open-jaw itineraries, where the airport or city the traveller departs from may not be the same as the arrival airport of the previous bound, or where the final airport or city the traveller arrives at may not be the same as the airport they originally departed from.

For example, an airline which does not permit open-jaw would only allow a round-trip from AAA-BBB and then BBB-AAA. But an airline which supports open-jaw itineraries might allow AAA-BBB followed by BBB-CCC, or AAA-BBB followed by CCC-AAA, or even AAA-BBB followed by CCC-DDD. Support is being added to selected Travelfusion integrations to allow open-jaw searches, and this page describes the AdditionalTripList feature which enables this.

StartRouting request with AdditionalTripList

The standard Travelfusion StartRouting request cannot represent a multi-bound itinerary or an open-jaw itinerary, so a new, optional XML structure has been defined to allow you to request such searches where the supplier and our integration support this. See below for our list of integrations which currently support these features.

The new structure is contained within an element named AdditionalTripList which must appear immediately after the OutwardDates element within your StartRouting request, and which replaces the ReturnDates element completely.

Open-jaw example

As an example, suppose we want to search for an open-jaw itinerary so that we travel LHR-CDG on 1st November and then travel CDG-EDI on 3rd November. The relevant section of the StartRouting request would look like this:

Open-jaw StartRouting request

<Type>airportcode</Type>

</Origin>

<Type>airportcode</Type>

</Destination>

</OutwardDates>

<Type>airportcode</Type>

</Origin>

<Type>airportcode</Type>

</Destination>

</OutwardDates>

</AdditionalTrip>

</AdditionalTripList>

The standard StartRouting elements Origin and Destination are used to describe the start and end points of the first bound, and the OutwardDates element describes the date of travel for that first bound. Then an AdditionalTrip element is used to describe the start and end points for the second bound, and the OutwardDates element within that AdditionalTrip describes the date of travel for this second bound.

Note that when using AdditionalTripList, the values for MaxChanges and MaxHops apply to the entire itinerary, so their values must be increased to avoid results being filtered out.

Multi-bound example

Suppose a traveller wants to gather all of the following trips under a single booking:

1. LHR-ARN departing 4th January,
2. GOT-PRG departing 12th January,
3. PRG-BCN departing 14th January,
4. MAD-FRA departing 20th January,
5. MUC-LAX departing 26th January,
6. LAX-LHR departing 12th April.

The relevant section of the StartRouting request would look like this:

Multi-bound StartRouting request

<Type>airportcode</Type>

</Origin>

<Type>airportcode</Type>

</Destination>

</OutwardDates>

<Type>airportcode</Type>

</Origin>

<Type>airportcode</Type>

</Destination>

</OutwardDates>

</AdditionalTrip>

<Type>airportcode</Type>

</Origin>

<Type>airportcode</Type>

</Destination>

</OutwardDates>

</AdditionalTrip>

<Type>airportcode</Type>

</Origin>

<Type>airportcode</Type>

</Destination>

</OutwardDates>

</AdditionalTrip>

<Type>airportcode</Type>

</Origin>

<Type>airportcode</Type>

</Destination>

</OutwardDates>

</AdditionalTrip>

<Type>airportcode</Type>

</Origin>

<Type>airportcode</Type>

</Destination>

</OutwardDates>

</AdditionalTrip>

</AdditionalTripList>

And if the airline supports open-jaw itineraries then the final destination would not need to be LHR, but could be any other airport.

Note that in AdditionalTripList mode the MaxChanges and MaxHops values represent the entire itinerary. These values must be set to a value high enough to reflect the fact that the combined itinerary will involve many different flight segments. Using values which are too low will mean that you’ll receive an error to say that all results have been filtered out. If this happens then increase the values of MaxChanges and MaxHops until you see results being returned.

Important notes about AdditionalTripList

It is valid to include a Radius element, but currently the value of the Radius element is ignored when using AdditionalTripList mode.

The value of Type cannot be “airportgroup” when AdditionalTripList mode is used. The value must be “airportcode” or “citycode” or “trainstationcode” and must be appropriate to the supplier being requested. Location groups cannot be used because of the exponential number of combinations that are produced by increasing the number of bounds.

CheckRouting response based on AdditionalTripList

When a search has been requested using a StartRouting request which uses AdditionalTripList, the CheckRouting response will come back with the structure of a one-way itinerary. All of the segments will be found within a single Result element, and the departure dates of the different segments may be separated by days, weeks, or months depending on the travel dates you specified within the AdditionalTripList.

Here is an example of how a result would appear, held entirely within an Outward element within the CheckRouting response, if the search requested an itinerary with three bounds: MAD-LGW, followed by MAN-LIN, followed by FCO-EDI.

CheckRouting response example

<Id>M46AF44NHQRXV1JY</Id>

</CacheInfo>

<Price>

<Name>Total tax</Name>

</TaxItem>

</TaxItemList>

</PassengerPrice>

</PassengerPriceList>

</Price>

<Type>airport</Type>

</Origin>

<Type>airport</Type>

</Destination>

<Name>Iberia Express</Name>

</TfOperator>

<Name>British Airways</Name>

</TfVendingOperator>

<Name>Iberia Express</Name>

</Operator>

<Name>British Airways</Name>

</VendingOperator>

</FlightId>

<TfClass>Economy With Restrictions</TfClass>

<SupplierClass>Economy Economy</SupplierClass>

</TravelClass>

<AircraftName>Airbus A320 jet</AircraftName>

</AircraftType>

<SegmentMayEndWithAStop>false</SegmentMayEndWithAStop>

</Segment>

<Type>airport</Type>

</Origin>

<Type>airport</Type>

</Destination>

<Name>British Airways</Name>

</TfOperator>

<Name>British Airways</Name>

</TfVendingOperator>

<Name>British Airways</Name>

</Operator>

<Name>British Airways</Name>

</VendingOperator>

</FlightId>

<TfClass>Economy With Restrictions</TfClass>

<SupplierClass>Economy Plus</SupplierClass>

</TravelClass>

<AircraftName>Airbus A319 jet</AircraftName>

</AircraftType>

<SegmentMayEndWithAStop>false</SegmentMayEndWithAStop>

</Segment>

<Type>airport</Type>

</Origin>

<Type>airport</Type>

</Destination>

<Name>British Airways</Name>

</TfOperator>

<Name>British Airways</Name>

</TfVendingOperator>

<Name>British Airways</Name>

</Operator>

<Name>British Airways</Name>

</VendingOperator>

</FlightId>

<TfClass>Economy With Restrictions</TfClass>

<SupplierClass>Economy Plus</SupplierClass>

</TravelClass>

<AircraftName>Airbus A321 jet</AircraftName>

</AircraftType>

<SegmentMayEndWithAStop>false</SegmentMayEndWithAStop>

</Segment>

<Type>airport</Type>

</Origin>

<Type>airport</Type>

</Destination>

<Name>BA Cityflyer</Name>

</TfOperator>

<Name>British Airways</Name>

</TfVendingOperator>

<Name>BA Cityflyer</Name>

</Operator>

<Name>British Airways</Name>

</VendingOperator>

</FlightId>

<TfClass>Economy With Restrictions</TfClass>

<SupplierClass>Economy Plus</SupplierClass>

</TravelClass>

<AircraftName>Embraer E190SR</AircraftName>

</AircraftType>

<SegmentMayEndWithAStop>false</SegmentMayEndWithAStop>

</Segment>

<Type>airport</Type>

</Origin>

<Type>airport</Type>

</Destination>

<Name>BA Cityflyer</Name>

</TfOperator>

<Name>British Airways</Name>

</TfVendingOperator>

<Name>BA Cityflyer</Name>

</Operator>

<Name>British Airways</Name>

</VendingOperator>

</FlightId>

<TfClass>Economy With Restrictions</TfClass>

<SupplierClass>Economy Plus</SupplierClass>

<SupplierFareBasisCode>OADDV2YO/Y</SupplierFareBasisCode>

</TravelClass>

<AircraftName>Embraer E190SR</AircraftName>

</AircraftType>

<SegmentMayEndWithAStop>false</SegmentMayEndWithAStop>

</Segment>

</SegmentList>

</Outward>

Note that the segments from all three bounds are found within the one Outward/SegmentList element.

If your software is already able to handle a Travelfusion CheckRouting response which contains one-way results having any number of segments, then your software ought to be able to handle a multi-bound or open-jaw result in this form.

In later stages (Details, Terms, Booking), the usual Travelfusion flow is used, and no special handling should be required on your side.

Integrations currently supporting AdditionalTripList

Currently only our British Airways (“britishairways”) integration supports the AdditionalTripList mode, and can handle both multi-bound and open-jaw itineraries.