Connection Guide

Registering to use the service
To obtain an login and password, please register here

Connecting to the service
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. 












           
          
Recommended Timeouts
The timeoutsbelow are examples / guidelines and are subject to the actual typicalresponse times seen at customer's end. 
Eachconnection to our service involves 2 steps: connection and read.These two steps have separate timeouts.

It is vital that you monitor timeouts and detect/ report any cases where a significant number of timeouts are occurring ( e.g. > 0.2%)

Connection timeouts:   (connect means establishing the initial socket connection)
In normal circumstances, it should be very fast to establish an initial connection. So we recommend starting with a timeout of 0.5s. However it is vital to retry at least once, with a longer timeout in case there are random/ networking/ system delays or hangs during the first connection. We would suggest 1s. If that also times out, it is suggested to retry again with a longer timeout of 2s. You should consider other possible cases where even longer timeouts may be needed - for example if there is a major temporary networking problem that could cause connections to be delayed by a few seconds. Also, if your system is running in a location where connectivity is known to be slow to the UK, there may be no point starting with a low timeout like 500ms. If you cannot implement any retries at all, then you will need to choose an appropriate 'catchall' connection timeout such as 2s. However retries are highly recommended (not more than 3 ideally)

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:150s read timeout, no retry
ProcessTerms:150s read timeout, no retry


It is important that you monitor timeouts and detect/ report any cases where a significant number of timeouts are occurring ( e.g. > 0.2%)

We recommendcareful logging of the number and type of timeouts in all cases and aregular check of this data to ensure that timeout rates are low. Eachretry should be logged separately so that you can see how manytimeouts occur on the first attempt and how many on each of thesubsequent retries.