XML Search with Booking Completion on Supplier Website
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 Detailed Specification. The detailed specification also sets 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.
Step 1: Connection
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
never 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.
Step 2: Submitting the search request
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.
Supplier route lists are available via the XML API.
These 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 Detailed XML Specification. It is recommended that the Type is
set to 'airportgroup' (see detailed spec for more info).
| |
StartRouting request XML example:
|
|
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.
| |
StartRouting response XML example
|
|
Step 3: Submitting the results request
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.
| |
CheckRouting request XML example:
|
|
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.
| |
CheckRouting response XML example:
|
|
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:
| |
Example of a complete Router that has already returned it's results in a previous CheckRouting response:
|
|
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
Step 4: Selecting a flight and forwarding the user to the supplier's website
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 example, notice the HandoffParametersOnly element must be included and set to 'true' and note that the
OutwardId corresponds ot 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).
| |
ProcessDetails request XML example:
|
|
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.
| |
ProcessDetails response XML example:
|
|
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>
About TRAVELfusion | Contact Our API Support Team
| Latest API Change - 2nd January
