Travelfusion Direct Connect XML API > Guidelines >

Rules, Guidelines and Travel Terminology

Rules and Guidelines

  • Your application should connect to Travelfusion's XML API using the domain 'api.travelfusion.com' (not using a fixed IP). However, Travelfusion operates a second system at 'apialt.travelfusion.com'. In rare cases of severe disruption, a DNS change will be made to direct api.travelfusion.com to the second system.

  • In some cases a dns change may not be made or it may be slow to propagate, so it is important that all customers are able to immediately switch their application to use the secondary URL (or to switch back to the primary) when required. This change of URL should be a manual process and should not be automated in any way, and it should never be done unless requested by Travelfusion.

  • Travelfusion's XML API service will be considered formally 'available' if the XML service is available at either site.

  • The primary system will have a fixed URL of 'api.pri.travelfusion.com'. If a DNS change is made as described above, there may be situations in which you may need to continue using the primary system so your application should also support this URL configuration.

    • The IP addresses of Travelfusion's services may change at any time without warning. Any related firewall settings need to be able to take this into account. The connection code of your application should be designed to obey the DNS TTL (Time to Live) record in the Travelfusion DNS entries and refresh accordingly, as well as have the ability to refresh the DNS resolution at the request at Travelfusion. Failure to do so may result in a loss of connectivity in the event a routine change occurs. For a list of IP addresses that Travelfusion uses for ingress, please contact support.

  • Travelfusion may change the URL of the service at any time. Since this would always require a configuration change to the client system, at least 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.

  • It is a mandatory requirement to capture and submit the end-user's IP address and various other data. Please see the 'EndUserIPAddress', 'EndUserBrowserAgent', 'EndUserDeviceMACAddress' and 'UserData' parameters here.

  • It is a mandatory requirement to identify and submit the original source (website) of each request. Please see the 'RequestOrigin' parameter here.

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

  • HTTP GZip compression must be utilised. See the connection guide or contact Travelfusion for more information.

  • 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.

  • 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.

  • 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 your browser 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).

"Disclaimer: Travelfusion takes no responsibility for the accuracy of any prices that are converted to other currencies than the one originally quoted by the supplier.

Travelfusion recommends that all currency conversion is handled by the agent's system. However if you choose to use Travelfusion's currency data, or if you use/ receive/ request converted prices via the API, Travelfusion takes no responsibility for the accuracy of those conversions."

  • All times/ dates are local unless stated otherwise - i.e. the time at the relevant airport

  • 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 travelfusion.com for an example of an updating results page.

  • Some suppliers' systems cannot support accented characters (such as ä) in fields such as passenger name and contact addresses. In these cases, Travelfusion maps these characters to a plain 26-character alphabet using appropriate mappings. Please contact Travelfusion if you would like more information about this or you would like to opt out of these mappings.

  • All flight details must be checked, at each stage, by the client system and by the end traveller. TF does not take responsibility for any changes in details that are not noticed, since this can sometimes be caused by the supplier.

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.