This guide is designed to give a quick start to your integration with the Travelfusion API. In the XML examples below, various XML elements and attributes have been omitted for simplicity. There are also many more details, features and functions available that you can read about in our XML Request and Reponse Specifications. These specifications also set out specific guidelines concerning how the API should be used and gives various other information that should be read before your integration is completed and released to end users.

The first step in the integration process is to create a connection to the Travelfusion servers and submit the Login request. This is fully described in the Connection Guide. The purpose of this is to receive your LoginId which you will submit with every XML request in future as authentication and identification. In each XML request there are 2 login fields that must be submitted - the XmlLoginId and the LoginId. You should initially insert your LoginId into both of these fields.

By default your LoginId will not change so you will never need to submit the Login request again. However if you would like to make use of more enhanced security options or you would like more details of the significance of the XmlLoginId and LoginId, please see our Login Handling Guide. 

The StartRouting request tells Travelfusion what you are looking for. Once this is submitted, the Travelfusion servers will evaluate which suppliers (e.g. easyjet, ryanair etc) and which routes (e.g. LHR to MAD) are relevant to your requirements. For each supplier-route, a Router is created which is responsible for connecting to the related supplier. 

Please see the Routing Guide for details and rules related to how you should specify the locations you wish to search and also for information about our city lists, airport lists, and supplier route lists which may be useful if you wish to calculate whether the user's journey can be covered by any of Travelfusion's suppliers, or for various other uses. 

The example below represents a request for a single (one-way) journey. If a return is required, the ReturnDates element should be included after the OutwardDates element. It's structure should be similar to that of OutwardDates. 

There are many features not demonstrated in the example below (for example the ability to resolve place names like 'London', or to request specifically the airports related to a city instead of using a search radius). For full details of all fields shown in the example, and all other XML functions, see the XML Request/Response Specifications. It is recommended that the Type is set to airportgroup (see the Routing guide for more info). 

The response to the StartRouting request will not contain any flight data. Instead it will just contain a list of all the Routers that have been launched in relation to your search. The example below shows that two Routers have been launched in response to the search request. One of these routers is searching Air Berlin for the route STN to MAD, and the other is searching British Airways from LHR to MAD. Also, a RoutingId is returned that must be submitted in later requests to identify this search. 

The CheckRouting request is used to fetch the latest results in relation to a previous StartRouting request. To do this, only the RoutingId obtained in the previous StartRouting response needs to be submitted as shown in the example below. 

The response will be very similar to the StartRouting response, except that any results received from the related suppliers will now be included within the Router elements as shown in the example below. There will always be the same number of Router elements as were returned in the StartRouting response. Note that in the example below, the Air Berlin Router still has not received any results from the supplier and so it still has it's Complete status set to false. However the British Airways Router has received results and those results are included in a GroupList element. In the case of a return journey, each Group will contain a list of Outward options (as below), and a list of Return options. The round trip journey can only be made of outward and return options that appear within the same group. 

For full details of all fields shown in the example, see the Detailed XML Specification. 

While there are Routers with Complete set to false, further CheckRouting requests should be submitted with a suitable delay between each (at least 5 seconds). Note that in order to save bandwidth and processing, the contents of the GroupList for a completed Router will only be returned in full detail once. So, for example if the CheckRouting request above is submitted again, the British Airways Router will look like this: 

Note that the CheckRouting response may contain cached data. This means that prices may not be completely up to date. Prices may also be updated at a later stage for a number of other reasons. Please see the guide to Caching and Price Changes. 

Once the end user has decided which flight they would like to book, a ProcessDetails XML request can be made to obtain the Handoff URL. The user can then be directed to this URL in a browser in order to complete their booking. In the following example, notice the HandoffParametersOnly element must be included and set to true, and note that the OutwardId corresponds to the id of the first British Airways outward result in the example CheckRouting response above. In the case of a return journey, a ReturnId must also be submitted after the OutwardId which will identify the chosen return flight (which must be in the same Group as the outward selection). 

The response will contain a SupplierHandoffData element. The data contained in this element should be used to build an HTML form with the specified ACTION (Url), submission method (GET/ POST), and the specified parameters and values. The submission of this form will take the user to the supplier's website to complete the booking. For more details, see the Detailed XML Specification. 

The following HTML shows how the parameters in the example response above can be used to construct a form that will forward the user to the appropriate stage of supplier's website. Note that this is not a working example. It is just supplied to demonstrate how the form should be constructed for a given SupplierHandoffData.

<html>
<body onLoad="testform.submit();">
<form name="testform" action="http://www.easyjet.com/en/book/step2.asp" method="POST">
	<input type="hidden" name="txtorigID" value="LGW"></input>
	<input type="hidden" name="txtdestID" value="MAD"></input>
	<input type="hidden" name="txtdorig" value="27"></input>
	<input type="hidden" name="txtddest" value="00"></input>
	<input type="hidden" name="outFlightVal" value="segment117095170"></input>
	<input type="hidden" name="orig" value="LGW"></input>
	<input type="hidden" name="dest" value="MAD"></input>
	<input type="hidden" name="oDay" value="27"></input>
	<input type="hidden" name="oMonYear" value="062006"></input>
</form>
</body>
</html>