Skip Navigation


The UpdateReservationRQ message can be used to modify a reservation that was previously confirmed. The modification is only allowed for confirmed lodging segments. Below criteria must be met:

  • Segment must be previously end transacted
  • Status must be HK
  • CF must not be empty number
  • UpdateReservationRQ can consist of only one action applied to a given segment with one or many fields modifications

If above mentioned conditions are not met an Error message will be generated.

Similar to the Sell request, Modify is a two-step process. The steps include Initiate then Commit. The modify functionality allows you to change, add, or remove certain fields to or from the lodging segment PNR:

  • Change – Fiield modification is only possible if was available at or provided during sell. Field modification means changing one value of the field to another. UpdateReservationRQ should contain the lodging product with the modification applied (e.g. with IATA number changed). All other fields should also be provided.
  • Add – Adding a field means the field was not available or provided during sell but the agent wants to add it to the PNR. UpdateReservationRQ should contain the lodging product with this field added to the old (before modification) segment (e.g. Frequent Traveler Number added). All other fields should also be provided.
  • Remove – Removing a field means the field was available or provided during sell and the agent wants to remove it from the PNR. UpdateReservationRQ should contain the lodging product with this field removed. All other fields you want to remain should also be provided. This does not include Form Of Payment, it can be omitted completely in modify initiate request. In such case the form of payment remains unchanged.

Some modifications require the customer to perform lodging availability and pricing steps once again with the new criteria to obtain a new booking key. These modifications are marked as Y in the Requires re-shop column below. Once they have a new booking key they will be able to use it in the UpdateReservationRQ request to perform the modification. For modifications that do not require a re-shop the booking key is not required but the old rate key does need to be passed. For modifications that do require a re-shop, the new booking key should be passed as well as the old rate key. 

The fields that can be modified in the CSL segment are as follows:

Field Type Change Add Remove Requires re-shop
Check In/Check Out date (outside date range) Y N/A N/A Y
Check In/Check Out date (within date range) Y N/A N/A N
Room Type Y N/A N/A Y
Guest Number Y N/A N/A Y
Guest Loyalty ID Y Y Y N
Corporate ID Number Y Y Y N
Frequent Traveler Number Y Y Y N
Arrival Time/Departure Time Y Y Y N
Special Instructions Y Y Y N
Form of Payment Y Y N N
IATA Number Y Y N N
Lead Guest Name Y N/A N/A N

The UpdateReservation request will support modification of one or more of these elements in the same request. In UpdateReservationRQ all the elements from the existing segment are required with modification applied. 

UpdateReservationRQ can consist of one or more UpdateReservationItem. One of these UpdateReservationItem can be a product update (a lodging segment modify action). This UpdateReservationItem may modify one or many fields of the lodging segment. There is no restriction on the number of fields that can be modified in the same update. Additionally, the type of the operation can be mixed between fields. For example, you can change the IATA number and remove the Guest Loyalty ID in the same update action. You can modify multiple fields as long as they are sent together in one UpdateReservationItem. There can be only one UpdateReservationItem for a given segment in an UpdateReservationRQ. If there are others UpdateReservationItems, they must apply to other segments or elements in the PNR.

You can:

  • Send an UpdateReservationRQ with one UpdateReservationItem to modify one or many fields of a lodging segment
  • Send an UpdateReservationRQ with many UpdateReservationItems. Each UpdateReservationItem must be applied on a different segment
  • Send many UpdateReservationRQ modifying different segments without having to ignore or commit modifications between requests; each segment can only be modified once before ignoring or committing.

You cannot:

  • Send an UpdateReservationRQ with more than one UpdateReservationItem applying to the same segment
  • Send UpdateReservationRQs modifying the same segment sequentially (one after another) without either committing or ignoring changes 
  • Ignore modification(s) of a segment without ignoring all other changes in the session

Point of sell (POS)

Point of sell (POS) of the modify initiate request is optional. If point of sell is not provided, current user's session information will be used. 

Both check-in and check-out dates can be modified outside of initial dates. This type of modification requires re-shop and a new booking key to be provided in the UpdateReservationRQ. Below is a sample request:

<ns3:UpdateReservationRQ Version="1.19.0" xmlns:ns3=""xmlns:or="">
        <ns3:ReservationUpdateItem UpdateId="modify1">
            <ns3:ProductUpdate op="U" id="24">
                        <or:ProductName type="HHL">Lodging</or:ProductName>
                                <or:BookingInfo RequestorID="SG11112" CorpDiscount="1234567">
                                        <or:HotelReservation Id="12345678" Type="5"/>
                                <or:StayDateRange StartDate="2021-03-27" EndDate="2021-03-28"/>
                            <or:Rooms NumberOfRooms="1">
                                <or:Room InvBlockCode="QNXUNHG" SegmentNumber="1" RoomIndex="1">
                                    <or:Guests Count="1">
                                        <or:Guest Type="10" Email="" Age="103" Index="1"LeadGuest="true"FrequentFlyerNumber="FLY12345" LoyaltyId="LOY12345" Title="Mr"FirstName="Amerigo" LastName="Vespucci">
                                            <or:Contact Phone="750650818" Mobile="186795353"/>
                                <or:SpecialInstruction>PS4 Needed</or:SpecialInstruction>

AA facts and general facts OSI lines behavior

Host Facts and General Facts OSI lines associated with the segment being modified will be removed and added to the history. Additional OSI data associated with the segment after the modification will be added to the PNR.

Initiate failure behavior

If there is a timeout, system down or connectivity issues at Initiate between the supplier and Sabre (Status SS code 17) or supplier rejected the request (Status NN code 43), PNR will receive the information required from NGHP to create the OX and SS segment or NN Segment. If the user proceeds to Commit, a Type B Modify is sent to the GDS supplier. The SS segment or NN segment is filed down as HK without a confirmation number at this point and OX segment stays in the PNR.

If Type B returns a “successful”, the confirmation is added to the HK segment. The OX segment remains in the PNR.

OSI for both segments are present in PNR. History contains new OSI associated with new segment.

ON VARIABLE........../AA/GVI4539105011539664EXP 11 20-TEST/CD-G