This API is used for changing the flight(s) by changing outward date, return date, origin, destination.

This document assumes the user is familiar with the Travelfusion Search and Book API.

The  ManageBookingAvailabilityPlane command should be executed before the user performs a Booking Change API modification. The element <ChangeOptions> in the response will indicate which change options are supported by Travelfusion, and hence, which post booking API to use.

This API is applicable to change options:

The eligible bookings for change must have one of the following statuses: Succeeded, BookingChangeSucceeded, CancelFailed. 

Making Changes to Bookings

With airline suppliers, it is possible to modify existing bookings that have been made via the Travelfusion XML API. This functionality is not currently available for all suppliers, however, for suppliers that do support it, the command syntax of the requests and responses is almost identical to those of the existing booking process. The XML commands and responses that differ from the existing booking process are:

StartRouting Request

To start a booking change request the following XML block needs to be included in a standard StartRouting request:

StartRouting - BookingChange component










All of the parameters in this XML block are mandatory and have the following values:

Any suppliers defined within a SupplierList will be ignored during a booking change request since it is assumed that the supplier must be the same as that used in the original booking.

The TravellerList is described in the standard StartRouting command. For the Booking Changes API, it is not mandatory for the TravellerList content to correspond to the traveller(s) of the airline supplier booking to be changed.

When performing a booking change, the OutwardDates, ReturnDates, Origin and Destination within the StartRouting request corresponds to the new desired dates for the journey.

[Note: If a return leg of a journey is being modified the OutwardDates block must be defined in the request even if the date is not being modified. However, the values specified within this block will be ignored since the actual value will be extracted from the original booking.]

Below is an example of a StartRouting request that includes a Booking Change block. This request will update both the outward and return dates of the booking with TF reference Z1VRPKORR to 21/10/2009 and 29/10/2009 respectively.

StartRouting example with Booking Change







































ProcessTerms Request & Response

The differences to the standard ProcessTerms request of Search and Book API are in the TravellerList element. The TravellerList is required to contain all the travellers, having the same names and ages and in the exact same order, as found in the current airline supplier booking. Any new / additional travellers’ CustomSupplierParameter should be included if needed or required (as per the normal search & book flow). 

The response is almost identical to that seen during a standard booking, however, the group level amount returned in the response corresponds to the cost of the current booking change. The TaxItemList will include the following key components (which are intended for the booking change flow) that contribute to this cost:

Please note that occasionally, and depending on the airline supplier, any of the above could be absent, in which case the respective tax item amount is considered zero. Moreover, you might encounter additional tax items as per normal search & book flow, e.g. Credit Card Fee, Luggage Fees, etc. For every tax item, the type of contribution (whether to be added or deducted) to the group level total cost is defined by the sign ahead of each amount.

Below is an example of a Price block that might be returned by a ProcessTerms request (Note: Some values may be displayed as negative values):

ProcessTerms response - Price example






            <Name>Amount Already Paid</Name>





            <Name>Net Total Price</Name>





            <Name>Non-Refundable Amount</Name>





            <Name>Change Booking Fee</Name>





            <Name>Credit Card Fee</Name>






Booking Change Statuses

When performing a booking change request, the status of the new booking and the original booking will vary.

After the submission of the StartBooking request the new booking and the original booking will be assigned any of the following combinations:

See the Booking Handling Guide for more details of how to handle certain booking statuses. The BookingChangeSucceeded and BookingChangeFailed statuses need to be handled like Succeeded or Failed accordingly.

Reports System

As with regular bookings, booking changes can be reviewed via the reports system. The system can display both the original booking and the changed booking that has replaced it. The screenshot below shows a booking that has been modified. The entry with the status BookingChanged corresponds to the original booking, whilst the entry with the status BookingChangeSucceeded corresponds to the new changed booking.

Clicking on the 'TF Reference' link will display the details page for the corresponding booking. The details page is almost identical to that seen for a regular booking, however, the 'Total price' field will now correspond to the price of the booking change. Additionally there is also a 'Booking Change Details' section that displays supplementary information about how the booking has been modified.

For an original booking that has subsequently been modified the following information is provided:

For a new booking that has resulted from a booking change the following information is provided:

Note: If a booking has been changed multiple times the 'Booking Change Details' for a changed booking may contain both a parent and child TF booking reference.

The screenshots below illustrate both the original booking and new booking as they would appear after a successful booking change request has been processed: