Skip to main content

Exchange Shopping Request XML

This chapter provides detailed information about select portions of the XML request that may need additional explanation beyond what is described in general information and schema annotations, as well as sample Exchange Shopping requests for different business scenarios.

Note: This chapter is intended as a supplement to the Exchange Shopping schema definition available in Dev Studio.

Request Attributes

Attribute Description Exchange Shopping Path
XML version Required in the XML schema ExchangeShoppingRQ/@Version

Request Elements

Element Description Exchange Shopping Path
Header Standard header information ExchangeShoppingRQ/Header
One of the possible optional Header attributes
Default timeout override Header element includes the attribute that allows the user to override the default timeout. When sent, this will be the time after which Exchange Shopping will try to stop processing the transaction. However, if the system is in the middle of processing in one of the subsystems, the timeout may occur after the timeout sent by the user. ExchangeShoppingRQ/Header/@ttl
Request XML elements
Point of Sale (POS) Point of sale and agent requesting the Exchange Shopping transaction. This data must match the data that will be used in the subsequent exchange transaction to ensure the cost of the exchange does not vary. ExchangeShoppingRQ/POS
Ticketing provider code Two-character code of the partition on whose behalf the Exchange Shopping transaction is performed. Agency customers should use the value “1S or 1B” ExchangeShoppingRQ/TicketingProvider
Passenger information Details about passengers and the flight documents to be changed ExchangeShoppingRQ/PassengerInformation
Travel itinerary information Details about the requested travel itinerary, including portions of travel (and related segments) that should remain unchanged (legs not shopped). ExchangeShoppingRQ/OriginDestinationInformation
Travel preferences Additional shopping criteria to be used when searching for alternate options. Optional qualifiers are described in “Optional Search and Pricing Parameters” ExchangeShoppingRQ/TravelPreferences
Diagnostic Reserved for internal Sabre use only ExchangeShoppingRQ/Diagnostic

Elements of the Exchange Shopping Request

This section provides more details about select portions of the Exchange Shopping request that may require additional explanation.

Point of sale

The following elements identifying the Point of Sale are required in the Exchange Shopping request. These elements are optional in the XML schema; however they are verified at the business rule validation layer.

Element Description Example Exchange Shopping Path
Pseudo Three-letter pseudo city code G7HE ExchangeShoppingRQ/POS/Pseudo
Shopping path Allows the point of sale to specify the attribute that is used to determine shopping rules selection. The value of request type attribute passed by Point of Sale identifies the Shopping rule that should be applied during Exchange Shopping transaction. If there is no specific Shopping rule that the Point of Sale wants to apply, it is recommended to send the value “TNEXC”. TNEXC ExchangeShoppingRQ/POS/ShoppingPath/@requestType

Passenger Information

This part of the Exchange Shopping XML request is used to specify details about the passengers requesting the change.

A maximum of nine (9) passengers may be included in a single Exchange Shopping request, which means up to nine repetitions of this data set are supported.

The PNR status will dictate the required data set.

Passenger with an Active PNR

The following elements are required when the passenger has an active PNR.

Element Description Example Exchange Shopping Path
PNR locator All passengers in the request are not required to be booked in the same PNR, however the requested itinerary must match for all passengers in the request. If all passengers are not booked in the same PNR, it is the responsibility of the user to correctly handle the rebooking process. Not mandatory YTRBDE ExchangeShoppingRQ/PassengerInformation/PassengerWithPNR/@pnrLocator
Reference Number Passenger reference number as reflected in the PNR. Not mandatory 1.1 ExchangeShoppingRQ/PassengrInformation/PassengerWithPNR/@referenceNumber
Passenger name Full first and last name as reflected in the PNR. Mandatory ADAM JONES ExchangeShoppingRQ/PassengerInformation/PassengerWithPNR/@firstName ExchangeShoppingRQ/PassengerInformation/PassengerWithPNR/@lastName
Document number Ticket number to be changed. If the document in the request is a conjunctive ticket, e.g. 1234567890-91, only the number of the first ticket should be passed in the request (e.g.1234567890). If the name in the request does not match the name on the provided document, the transaction will still be processed, and a warning will be added when returning the options. It will be at the user’s discretion to display the options to the customer or fail the transaction. 1231234567890 ExchangeShoppingRQ/PassengerInformation/PassengerWithPNR/DocumentNumber

Passenger without an Active PNR

Element Description Example Exchange Shopping Path
This element is not currently supported and is planned for future versions of the service. N/A N/A N/A

Travel Itinerary information

This section of the XML request provides information about the requested travel itinerary and focuses on mandatory elements for specific business scenarios.

Types of Legs in the Exchange Shopping Request

There are three types of legs (O&Ds) which will require a different data set depending on what changes are requested:

  • Not shopped
  • Shopped
  • Shopped with same connections

All three types of legs can be combined within a single Exchange Shopping request.

Exchange Shopping Xpath ExchangeShoppingRQ/OriginDestinationInformation

Not Shopped Leg

Full information about the segments in the PNR that should be included on the new ticket must be included in the request, as the Exchange Shopping service does not access the PNR to verify details.

Exchange Shopping Xpath ExchangeShoppingRQ/OriginDestinationInformation/@shopIndicator = “false”

Required Information for Not Shopped Leg

If the leg is not shopped, details about all related segments pertaining to this leg are required. If no flight segment information is provided for the leg, an error message will be returned, and the transaction will be terminated.

The following flight segment information elements from the PNR are required for the leg that is not shopped:

Element Description Example ExchangeShopping Path
Operating carrier Two-character alphanumeric code for the operating carrier of the flight segment XX ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@operatingProvider
Marketing carrier Two-character alphanumeric code for the marketing carrier of the flight segment YY ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@marketingProvider
Flight number Numeric marketing flight number 6130 ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@marketingFlightNumber
Departure airport Three-character departure airport of the flight segment LHR ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@startLocation
Arrival airport Three-character arrival airport of the flight segment PHL ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@endLocation
Reservation booking class Code for the reservation booking class S ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@bookingClass
Reservation status Reservation status as in the PNR HK ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@reservationStatus
Departure date/time Flight segments departure date and time 2017-05-20T12:40:00 ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@startDateTime
Arrival date/time Flight segment arrival date and time 2017-05-20T15:25:00 ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@endDateTime
Booking date/time Flight segment booking date and time 2017-05-10T04:08:00 ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@bookingDateTime

Sample XML Request with Not Shopped Leg

The passenger would like to keep the first leg of the journey and exchange only the return (PHL-LHR), which means the outbound leg (LHR-PHL) is not shopped.

1 AA6130S 20MAY 6 LHRPHL HK1 1240 1525 /DCAA*NSSUOV /E
2 AA6129S 26MAY 5 PHLLHR HK1 1830 0635 27MAY 6

Details of not shopped leg in the Exchange Shopping request:

<ExchangeShoppingRQ xmlns=“" xmlns:n0=“" xmlns:xsi=“" version=“2.2.0">
        <STL_Header.RQ ttl=“300">
            <OrchestrationID seq=“0">027364343467758035</OrchestrationID>
            <ShoppingPath requestType=“TNEXC" bookingChannel=“TN"/>
            <PassengerWithPNR pnrLocator=“DNANZS" referenceNumber=“1.1" firstName=“MARK" lastName=“JONES">
        <OriginDestinationInformation shopIndicator=“false">
            <RelatedSegment operatingProvider=“XX" marketingProvider=“YY" marketingFlightNumber=“6130" startDateTime=“2017-05-20T12:40:00" endDateTime=“2017-05-20T15:25:00" startLocation=“LHR" endLocation=“PHL" bookingClass=“S" reservationStatus=“HK" bookingDateTime=“2017-05-10T04:08:00"/>
        <OriginDestinationInformation shopIndicator=“true">

Shopped Leg combined with “Use Same Connections” Parameter

If the leg is shopped AND the “Use Same Connections” parameter is used for this leg, only itinerary options for the indicated city pair and travel dates connecting through the same airports as already ticketed will be searched. Full details are required for related segments in the request.

Exchange Shopping Xpath ExchangeShoppingRQ/OriginDestinationInformation/@shopIndicator=“true” and ExchangeShoppingRQ/OriginDestinationInformation/@preserveConnectionsIndicator=“true”

Shopped Leg NOT combined with “Use Same Connections” Parameter

When a leg is shopped but the “Use Same Connections” search parameter is not applied, no related flight segment details are required. These details will be ignored if included in the request.

Exchange Shopping Xpath ExchangeShoppingRQ/OriginDestinationInformation/@preserveConnectionsIndicator=“false” or is not sent at all

Information on the Leg Level

The following elements need to be passed for the leg that is not shopped:

|Element| Description| Exchange Shopping Path| |Start Location| Three-letter airport or city code where portion of travel should begin| ExchangeShoppingRQ/OriginDestinationInformation/StartLocation| |End Location| Three-letter airport or city code where portion of travel should end ExchangeShoppingRQ/OriginDestinationInformation/EndLocation| |Departure or arrival date or date and time| Departure or arrival date or date and time when portion of travel should start or end. |ExchangeShoppingRQ/OriginDestinationInformation/DateTimeSelection/DepartureDate ExchangeShoppingRQ/OriginDestinationInformation/DateTimeSelection/DepartureDateTime ExchangeShoppingRQ/OriginDestinationInformation/DateTimeSelection/ArrivalDate|

Note: All other search and pricing parameters are optional.

Maximum Number of Legs vs. Maximum Number of Segments

The maximum number of legs (O&Ds) supported is ten (10). The maximum number of segments supported is sixteen (16). If a leg is shopped and the “Use Same Connections” parameter is not applied, that leg is counted both as one leg and one segment.

Exchange Shopping Xpath for Leg ExchangeShoppingRQ/OriginDestinationInformation

Exchange Shopping Xpath for Segment ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment