Xml requests are submitted to api.travelfusion.com/Xml as the body of an HTTP 1.1 POST request. You must connect using https (secure). Please see the general guidelines for information about our secondary system and correct handling of IPs, URLs and DNS.

In general, UTF-8 encoding should be used. The 'Content-Type' and 'Host' header must be submitted in the HTTP headers. GZip compression must be requested in all HTTP requests. (But please note that Travelfusion's servers may not always return gzip compressed results)

Example java and PHP code is supplied below which can be used to submit the login request to the Travelfusion service and obtain a response. You should insert your login and password into the appropriate place (highlighted in red) before executing this code. This code is supplied as guidance only and it is not necessarily functional or correct and is not recommended for use in any application. It is recommended that you consider connection problems very carefully. There are many reasons that a connection to our system may timeout or fail completely. You should detect these cases and implement retries wherever applicable/ safe to do so. 

           

          

Connection timeouts:   (connect means opening the initial socket connection)
For all connections at any part of the search/ booking flow, we recommend 2 seconds for the first attempt, retrying if the connection fails, with increasing timeouts. Retry twice with timeouts of 4 seconds and then 8 seconds respectively.

Data read timeouts:   ('Data read' means the time from the successful socket opening, to the last byte of the response being read)
StartRouting: 4s read timeout, retry once with a 15 seconds timeout
CheckRouting: 7s read timeout (and continue with the standard polling process in case of a time out)
StartBooking: 20s read timeout, do NOT retry, instead proceed to CheckBooking
CheckBooking: 10s read timeout (and continue with the standard polling process in case of a time out)
ProcessDetails: 120s read timeout, no retry
ProcessTerms: 120s read timeout, no retry

We recommend careful logging of the number and type of timeouts in all cases and a regular check of this data to ensure that timeout rates are low. Each retry should be logged separately so that you can see how many timeouts occur on the first attempt and how many on each of the subsequent retries.