Rules and Guidelines


  • In the search request, the 'IncrementalResults' element must be submitted, with value 'true'.

  • TRAVELfusion can not guarantee to supply information that can't be obtained from the supplier at the equivalent stage within their data interface. e.g. if a supplier does not display flight numbers at the search results stage, then the related fields will be omitted or empty in the TRAVELfusion results response XML.

  • XML should be constructed/ parsed using an XML package that maintains the order of XML items which appear at the same level of nesting within the same surrounding block.

  • Any XML elements listed in the detailed specification for each request/ response should be assumed as mandatory unless stated otherwise

  • There may be extra data fields or attributes in the XML or schema that are not mentioned in the spec. Such fields or attributes could occur at any position in the XML and should be ignored.

  • TRAVELfusion may insert new XML elements or attributes to the XML/ spec/ schema at any time without notice.

  • TRAVELfusion may make a change to the spec/ schema/ XML API without notice wherever an error or inconsistency is found.

  • No changes will be made to the XML API or specification such that it becomes incompatible with any previous version of the spec/ schema, without prior notice of 1 week for minor changes and 1 month for major changes.

  • Any changes to the API spec or behaviour will be notified via email. The email address used will be that in the registration profile. Changes will also be logged in the Change Record and customers are requested to check this frequently.

  • If schemas are utilised by the customer in any way, the customer's application must be configured to ignore any XML elements in an XML response, that do not appear in the schema. If this is not possible, the application must be configured to reload the schemas from their online location in such cases.

  • When using https (SSL), care should be taken regarding certificates. TRAVELfusion, as all web-based services, has to occasionally update the SSL certificates related to the travelfusion.com domain, and this can sometimes affect the customer's application. Such certificate updates are normal and TRAVELfusion cannot give advance warnings. Customers are requested to ensure that connections are made in such a way that certificates are not validated or that validation failures do not prevent the customer's application from functioning.

  • The IP of TRAVELfusion's service may change at any time without warning. Any related firewall settings should take this into account. This may also impact application code which may sometimes cache DNS results. The code and error handling should be designed to account for possible IP changes. A fixed IP may only be used with special permission from TRAVELfusion, and even then, the customer is responsible for detecting changes to the DNS based IP of the TRAVElfusion service and must consult with TRAVELfusion each time this happens. The following 4 IPs are likely to be the only ones ever used: 85.13.195.226, 85.13.195.80, 85.13.194.198, 84.45.69.133, however your system should be able support any IP change. Also, TRAVELfusion may change the URL of the service at any time. Since this would always require a configuration change to the client system, 1 week's notice will always be given. Please make sure your system is easily configurable so that this change can be made in under a week.

  • TRAVELfusion reserves the right to block access to the service without notice, if any security, load or misuse related issues are detected

  • In general, TRAVELfusion does not always filter the results returned by data suppliers. So if a supplier returns some results that do not correspond to the parameters of the request, these results may still be returned by TRAVELfusion.

  • Please use a recent version of Internet Explorer to view this XML specification since the content displayed may vary across browser types.

  • Currency conversion rates should not be requested more that once per day (using the GetCurrencies request)

  • Login requests must not be sent more often than necessary. By default the Login request never needs to be submitted at runtime as the LoginId does not change. However if you wish to configure your account to have a changing LoginId, you must discuss this with TRAVELfusion and make sure you only submit the Login request when necessary - no more often than every 5 minutes.

  • Since our data suppliers can vary in response times, you must implement a user interface that is able to update the user with the latest results, and informs them of the fact that more results will be available soon. If your interface can only display the results once and cannot update them, then you may find the user has to wait an excessive amount of time just because of one slow supplier, or results may be lost when a supplier does not respond within the time that your system waits before displaying results. Please see www.travelfusion.com for an example of an updating results page


Travel Terminology

Throughout the spec, a 'leg' refers to a single journey from origin to final destination (or the corresponding return journey). A 'trip' refers to an entire booking which will consist of either 1 leg (a one-way trip) or 2 legs (a return trip). A 'leg' may include 0 or more changes and 0 or more stops. A 'segment' refers to part of a 'leg' that is made on the same airplane. A 'segment' may contain 'stops', but not 'changes'. Segments within the same leg are separated by changes. A change involves landing at an airport other than the destination of the leg, disembarking, boarding a different plane and taking off again. A 'stop' is a landing and take-off without changing planes. A 'hop' is any airborne part of a journey. A 'hop' cannot include stops or changes.

About TRAVELfusion | Contact Our API Support Team | Latest API Change - 2nd January