Skip to main content

 

Guides

Learn about how to get started with our products, common concepts you may hear in the travel industry, and other guides to help you along the way.

 

Enhanced Hotel Book (EHB)

General overview

With the release of Content Services for Lodging (CSL), Sabre has expanded its traditional GDS hotel offering with content from external aggregators.

The Enhanced Hotel Book API (EnhancedHotelBookRQ) facilitates the booking of both traditional GDS hotel content as well as lodging aggregator content.

Features in the Enhanced Hotel Book API include:

  • Ability to book an Aggregator hotel as a CSL segment.
  • Ability to book a Sabre GDS hotel as a CSL segment or as a legacy segment.
  • Ability to specify a “Hotel Booking Key” that uniquely identifies the hotel property, room type, room rate, number of guests, etc.
  • Ability to identify failures during the orchestrated process, and properly notify the user.

Technical overview

Preconditions

To ensure a successful execution of this API the following data elements need to be present in the Sabre session (“AAA”) prior to calling the EnhancedHotelBookRQ API:

  • Traveler's name.
  • Travel agency's address.

You can can achieve this by adding these data elements via PassengerDetailsRQ prior to the call to EnhancedHotelBookRQ or by retrieving an existing reservation via GetReservationRQ / TravelItineraryReadRQ.

Additionally a valid "Hotel Booking Key" is required. This is the key element to trigger the hotel booking process.

Note: More details on this Key can be found in the "Hotel Booking Key" section below.

General booking logic

The API performs several steps when booking a hotel room:

  • It will decode and retrieve shopped rate details based on the data provided by the "Hotel Booking Key".

  • Depending on the data of the booking key and user input, the API will follow one of the following three strategies to book the desired hotel rate:

    • Aggregator hotel via CSL
    • GDS hotel via CSL
    • GDS hotel as a legacy segment

Note: Details on these booking strategies are available in the Usage of the @bookGDSviaCSL flag section below.

  • If the booking is successful, the API will validate the newly added segment statuses as returned by the hotel vendor or aggregator (HK/SS/NN/PN/UC/NO):
    • HK/SS/NN are considered successful (non-error) status codes
    • UC/NO are considered unsuccessful status codes and the API will return an error
    • PN will always be returned for aggregator bookings and is considered a successful (non-error) status code. See below table for more details.
  • Finally, it will return the details of the newly added segment.


Status Code Short Description Full Description
HK CONFIRMED The status code HK indicates holds confirmed status.
NN ON_REQUEST The status code NN indicates a pending request to the vendor, this is normally a temporary status code returned when the communication to a vendor is slow.
If this code persists after redisplaying a reservation it likely indicates a breakdown in communication between Sabre and the vendor.
NO UNCONFIRMED The status code NO indicates the vendor denied the booking request with NO action. You must cancel the denied segment and request an alternate booking.
If NO status is returned by a vendor on a previously confirmed segment, it may indicate that the Sabre PNR is out of synch with the vendor records (the records do not match). Contact the vendor to validate the PNR data.
PN PENDING PN will always be returned for aggregator bookings. The confirmation number at this time is created by Sabre and not the vendor. At time of commit (End Transaction), this status should change to either HK or UC:
- If HK, the previous confirmation number will be overwritten with the one created by the vendor.
- If the segment remains in PN status at time of Commit (End Transaction), this indicates something has gone wrong with the request and you will need to follow up with the aggregator manually. Segments in PN status cannot be updated by the API user.
SS CONFIRMED The status code SS indicates a successful Sabre system response. The segment sold through Sabre or a sell message was sent to the vendor.
UC UNCONFIRMED The status code UC indicates the segment is not confirmed. Cancel the segment and request an alternative booking.


Detailed booking execution

Hotel booking key

For the booking process to commence, a "Hotel Booking Key" needs to be passed at /EnhancedHotelBookRQ/BookingInfo/BookingKey.

XML snippet below:

<EnhancedHotelBookRQ version="2.0.0" xmlns="http://services.sabre.com/sp/enhanced/hotel/book/v2">
    <BookingInfo>
        <BookingKey>d9e73f0d-5f90-4b43-9c86-2d88a732604f</BookingKey>
    </BookingInfo>
    ...

A "Hotel Booking Key" is obtained as part of the response of the Hotel Price Check API (SOAP | REST).

Note: for additional details on general workflow usage, and the need for a Hotel Price Check API call please refer to the main Content Services for Lodging (CSL) reference.

The Enhanced Hotel Book API will automatically decode the booking key, obtain the hotel property ID, rate details, and more, and determine its source (GDS or Aggregator) in order to execute the booking through the appropriate vendor.

Usage of the @bookGDSviaCSL flag

The Enhanced Hotel Book API offers the same schema for booking both traditional GDS hotel content as well as new aggregator content, but provides a specific flag /EnhancedHotelBookRQ@bookGDSviaCSL to allow users to decide how to book the GDS hotel content.

If the user specifies @bookGDSviaCSL=true, eg:

<EnhancedHotelBookRQ bookGDSviaCSL="true" xmlns="http://services.sabre.com/sp/enhanced/hotel/book/v2" version="2.0.0">
...

or does not specify this field default = true, e.g:

<EnhancedHotelBookRQ xmlns="http://services.sabre.com/sp/enhanced/hotel/book/v2" version="2.0.0">
...

Then the GDS lodging content will be booked as a CSL segment.

If the user specifies @bookGDSviaCSL=false, e.g:

<EnhancedHotelBookRQ bookGDSviaCSL="false" xmlns="http://services.sabre.com/sp/enhanced/hotel/book/v2" version="2.0.0">
...

Then the GDS lodging content will be booked as traditional GDS segment.

To sum it up, depending on the data of the booking key and usage of this flag, the API will follow one of the following three strategies to book the desired hotel rate:

  • Book Aggregator as Content Service for Lodging segment
  • Book GDS as Content Service for Lodging segment
  • Book GDS as legacy segment

Booking method (guarantee or deposit)

In order to book lodging content a booking method needs to be specified. The two most common options are: guarantee or deposit, which is indicated via the following element in the API request: /EnhancedHotelBookRQ/PaymentInformation@Type

The API accepts two values in this attribute: GUARANTEE or DEPOSIT.

@Type="GUARANTEE" and credit card form of payment is the most common method for booking lodging content, but you will need to validate what are the specific criteria per each vendor.

The list of options is listed below (each specific type may be accepted or not per vendor):

Guarantee Deposit
Credit Card Y Y
Agency (Name & Address) Y Y
Agency IATA Y
Company (Name & Address) Y
Corporate Discount Code Y Y
Virtual Form Of Payment Y Y


A third option is available, normally referred to as “late arrival” (or simply “LATE”).

This method is supported by some hotel suppliers and allows customers to make a booking without any form of payment. This can be specified by completely omitting the /EnhancedHotelBookRQ/PaymentInformation section.

In order to determine which option should be used at time of booking, users can interrogate the specific guarantee conditions from the GetHotelAvailRQ API response.

eg. for the SOAP/XML GetHotelAvailRS: /GetHotelAvailRS/HotelAvailInfos/HotelRateInfo/Rooms/Room/RatePlans/RatePlan/RateInfo/Guarantee@GuaranteeType

Where the possible options are: GUAR, DEP or LATE.


XML sample below with @Type="GUARANTEE" and credit card form of payment:

<EnhancedHotelBookRQ xmlns="http://services.sabre.com/sp/enhanced/hotel/book/v2" version="2.0.0">
    <BookingInfo>
        <BookingKey>...</BookingKey>
    </BookingInfo>
    <Rooms>
        ...
    </Rooms>
    <PaymentInformation Type="GUARANTEE">
        <FormOfPayment>
            <PaymentCard>
                <PaymentType>CC</PaymentType>
                <CardCode>AX</CardCode>
                <CardNumber>4111111111111111</CardNumber>
                <ExpiryMonth>12</ExpiryMonth>
                <ExpiryYear>2019</ExpiryYear>
                <FullCardHolderName>
                    <FirstName>Max</FirstName>
                    <LastName>Power</LastName>
                </FullCardHolderName>
                <CSC>134</CSC>
                <Address>
                    <AddressLine>Wadowicka 6</AddressLine>
                    <CityName>Krakow</CityName>
                    <StateProvince code="KR"/>
                    <StateProvinceCodes>
                        <Code>KR</Code>
                    </StateProvinceCodes>
                    <PostCode>30-415</PostCode>
                    <CountryCodes>
                        <Code>PL</Code>
                    </CountryCodes>
                </Address>
            </PaymentCard>
        </FormOfPayment>
    </PaymentInformation>
</EnhancedHotelBookRQ>

Special use case for Virtual Form of Payment method.

Starting with version 2.1.0, Enhanced Hotel Book provides capability to book CSL content by means of a Virtual Card. To successfully book a room using this booking method, pass all the required values at: /EnhancedHotelBookRQ/PaymentInformation/FormOfPayment/VirtualCard. The required values are listed below :


Element / attribute Description
/PaymentInformation/@Type Payment method. Choose “GUARANTEE”
CustomerAccountCode The virtual card number
Agency/@Email Agency contact e-mail address
/HotelInfo/@Fax Hotel fax number
/HotelInfo/@HotelName Hotel name. Pass the value from: HotelPriceCheckRS/PriceCheckInfo/HotelInfo/@HotelName
/RoomDescription/@Name Room name. Pass the value from: HotelPriceCheckRS/PriceCheckInfo/HotelRateInfo/Rooms/Room/RoomDescription/@Name
/RoomDescription/Text Room text description. Pass the value from: HotelPriceCheckRS/PriceCheckInfo/HotelRateInfo/Rooms/Room/RoomDescription/Text
/RateInfo/@AmountAfterTax Booking total amount. Pass the value from: HotelPriceCheckRS/PriceCheckInfo/HotelRateInfo/RateInfos/RateInfo/@AmountAfterTax
/RateInfo/@CurrencyCode Currency code. Pass the value from: HotelPriceCheckRS/PriceCheckInfo/HotelRateInfo/RateInfos/RateInfo/@CurrencyCode
/SpecialInstructions/SpecialInstruction Use this to inform the hotel of any extra charges that will be covered by the virtual card. If the card is used to cover room only, pass “Room Only” value

XML sample below:

<EnhancedHotelBookRQ xmlns="http://services.sabre.com/sp/enhanced/hotel/book/v2_1" version="2.1.0">
    <BookingInfo>
        <BookingKey>...</BookingKey>
    </BookingInfo>
    <Rooms>
        ...
    </Rooms>
    <PaymentInformation Type="GUARANTEE">
        <FormOfPayment>
            <VirtualCard>
                <CustomerAccountCode>SABRECARD</CustomerAccountCode>
                <Agency Email='sp.support@sabre.com'/>
                <HotelInfo Fax='123456789' HotelName='Hotel Suites'/>
                <RoomDescription Name='BOOK EARLY N SAVE NO REFUNDS'>
                    <Text>1 KING BED LEISURE NONSMOKING WITH FREE WI FI ACCESS</Text>
                </RoomDescription>
                <RateInfo AmountAfterTax="356.02" CurrencyCode="USD"/>
                <SpecialInstructions>
                    <SpecialInstruction>Room Only</SpecialInstruction>
                </SpecialInstructions>
            </VirtualCard>
        </FormOfPayment>
    </PaymentInformation>
</EnhancedHotelBookRQ>


State management & authentication

The API is available in SOAP/XML and behaves in a stateful way, making it adaptable to most workflows implemented today by our API users.

In order to successfully invoke a stateful API you need to have a valid session-based token, these type of tokens are available upon a successful execution of the SessionCreateRQ API.

For users who desire to book hotel content in a stateless way, Sabre is expanding the capabilities of these two APIs:

  • Create Passenger Name Record (to support booking of new reservations) SOAP | REST
  • Update Passenger Name Record (to support adding bookings into existing reservations) SOAP | REST

Both APIs behave in a stateless way and can be consumed via session-less (ATK) tokens.

Both APIs will be available in SOAP/XML & REST/JSON.


Use cases

The Enhanced Hotel Book (EHB) API can be used to book new lodging reservations as well as to add lodging content to existing reservations. Each use case is detailed below:

New reservations:

Shop and book GDS hotel as a legacy hotel segment in a new PNR:
  1. Create Sabre Session / Token to use Content Services for Lodging APIs.
  2. Send a shopping request to GetHotelAvailRQ/GetHotelDetailsRQ and identify GDS content (InfoSource=100).
  3. Use Rate Key to send price check request to HotelPriceCheckRQ to obtain Booking Key.
  4. Submit required data elements into the Sabre session (“AAA”), including the Traveler's name and Travel Agency address, using, for example PassengerDetailsRQ.
  5. Set @bookGDSviaCSL=false, use the Booking Key obtained from HotelPriceCheckRS, plus other booking details, including guest details, form of payment, loyalty ID, special requests, etc, to create the booking request using EnhancedHotelBookRQ.
  6. Once a successful response is received, you can submit a second request to the PassengerDetailsRQ API or make a call to the EnhancedEndTransactionRQ API to commit the changes and end the PNR.
Shop and book GDS hotel as a CSL hotel segment in a new PNR:
  1. Create Sabre Session / Token to use Content Services for Lodging APIs.
  2. Send a shopping request to GetHotelAvailRQ/GetHotelDetailsRQ and identify GDS content (InfoSource=100).
  3. Use the Rate Key to a send price check request to HotelPriceCheckRQ to obtain the Booking Key.
  4. Submit required data elements into the Sabre session (“AAA”), including the Traveler's name and Travel Agency address, using, for example PassengerDetailsRQ.
  5. Set @bookGDSviaCSL=true, use the Booking Key obtained from HotelPriceCheckRS, plus other booking details, including guest details, form of payment, loyalty ID, special requests, etc, to create a booking request to EnhancedHotelBookRQ.
  6. Once a successful response is received, you can submit a second request to the PassengerDetailsRQ API or make a call to the EnhancedEndTransactionRQ API to commit the changes and end the PNR.
Shop and book aggregator hotel as a CSL hotel segment in a new PNR
  1. Create a Sabre Session / Token to use Content Services for Lodging APIs.
  2. Send a shopping request to GetHotelAvailRQ/GetHotelDetailsRQ and identify Aggregator content (InfoSource=110, 111 or 112).
  3. Use the Rate Key to send a price check request to HotelPriceCheckRQ to obtain the Booking Key.
  4. Submit any required data elements into the Sabre session (“AAA”), including the Traveler's name and the Travel Agency address, using, for example PassengerDetailsRQ.
  5. Use the Booking Key obtained from HotelPriceCheckRS, plus other booking details, including guest details, form of payment, loyalty ID, special requests, etc, and any other required aggregator data fields to create a booking request to EnhancedHotelBookRQ.
  6. Once a successful response is received, you can submit a second request to the PassengerDetailsRQ API or make a call to the EnhancedEndTransactionRQ API to commit the changes and end the PNR.
    • Note: Usage of the bookGDSviaCSL flag will have no impact on a CSL aggregator booking.

Existing reservations

Shop and book a GDS hotel as a legacy hotel segment and add it into an existing PNR:
  1. Create a Sabre Session / Token to use Content Services for Lodging APIs.
  2. Send a shopping request to GetHotelAvailRQ/GetHotelDetailsRQ and identify the GDS content (InfoSource=100).
  3. Use a Rate Key to send a price check request to HotelPriceCheckRQ and obtain a Booking Key.
  4. Use GetReservationRQ to retrieve an existing PNR and ensure it already contains required data, namely the traveler's name and the agency address.
  5. If the agency address is missing, add it prior to the subsequent step.
  6. Set @bookGDSviaCSL=false, use the Booking Key obtained from HotelPriceCheckRS plus other booking details, including guest details, form of payment, loyalty ID, special requests, etc, to create a booking request using EnhancedHotelBookRQ.
  7. Once a successful response is received, you can submit a second request to the PassengerDetailsRQ API or make a call to the EnhancedEndTransactionRQ API to commit the changes and end the PNR.
Shop and book GDS hotel as a CSL hotel segment into an existing PNR:
  1. Create a Sabre Session / Token to use Content Services for Lodging APIs.
  2. Send a shopping request to GetHotelAvailRQ/GetHotelDetailsRQ and identify the GDS content (InfoSource=100).
  3. Use a Rate Key to send price check request to HotelPriceCheckRQ and obtain a Booking Key.
  4. Use GetReservationRQ to retrieve an existing PNR and ensure it already contains the required data, namely the traveler's name and the agency address.
  5. If the agency address is missing, add it prior to executing the subsequent step.
  6. Setting @bookGDSviaCSL=true, use the Booking Key obtained from HotelPriceCheckRS, plus other booking details, including guest details, form of payment, loyalty ID, special requests, etc, to create a booking request using EnhancedHotelBookRQ.
  7. Once a successful response is received, you can submit a second request to the PassengerDetailsRQ API or make a call to the EnhancedEndTransactionRQ API to commit the changes and end the PNR.
Shop and book an aggregator hotel as a CSL hotel segment into an existing PNR:
  1. Create a Sabre Session / Token to use Content Services for Lodging APIs.
  2. Send a shopping request to GetHotelAvailRQ/GetHotelDetailsRQ and identify Aggregator content (InfoSource=110, 111 or 112).
  3. Use the Rate Key to send a price check request to HotelPriceCheckRQ and obtain the Booking Key.
  4. Use GetReservationRQ to retrieve an existing PNR and ensure it already contains the required data, namely the traveler's name and the agency address.
  5. If the agency address is missing, add it prior to executing the subsequent step.
  6. Use the Booking Key obtained from HotelPriceCheckRS, plus other booking details, including guest details, form of payment, loyalty ID, special requests, and any other required aggregator data fields to create a booking request to EnhancedHotelBookRQ.
  7. Once a successful response is received, you can submit a second request to the PassengerDetailsRQ API or make a call to the EnhancedEndTransactionRQ API to commit the changes and end the PNR.
    • Note: Usage of the bookGDSviaCSL flag will have no impact on a CSL aggregator booking.



Error Handling

The below table illustrates currently implemented error handling for EnhancedHotelBookRQ:

Location Scenario Error Message
Schema RQ Customer request schema validation has failed, customer provided an invalid input. SOAP Fault in response with schema validation details
Booking key retrieval error Booking key cannot be retrieved or decoded EnhancedHotelBookRS with Business error:
Unable to read Enterprise Shared Cache data - no data for provided key
Unable to read Enterprise Shared Cache data - data content is empty for provided key
Unable to read rateKey - wrong data format returned by Shared Cache
Unable to decode rateKey
Unable to decode rateKey - not supported type of rate key
Unable to use rateKey data - no XXX or empty
Unable to use rateKey data - XXX, "value should be higher then 0
Main business error Main error returned by the SP application. Will be followed by system specific errors generated by the application or the content providers. EnhancedHotelBookRS with Business error:
Unable to perform hotel booking step. See below messages for details
HotelProperty DescriptionLLSRQ GDS as legacy only. Low level error coming from the provider. EnhancedHotelBookRS with Provider error:
Unable to perform HotelPropertyDescriptionLLSRQ call. See below messages for details
HotelPropertyDescriptionLLSRQ Multiple calls GDS as legacy only. Unable to find matching rate within any of the responses from the low-level API. EnhancedHotelBookRS with Business error:
Unable to find a matching room rate code within HotelPropertyDescriptionLLSRQ response
HotelPropertyDescriptionLLSRQ GDS as legacy only. Shopped rate was found but its price does not match the amount decoded from the booking key. EnhancedHotelBookRS with Business error:
The total booking price does not match price returned during shopping
HotelRateDescriptionLLSRQ GDS as legacy only. Low level error coming from the provider. EnhancedHotelBookRS with Provider error:
Unable to perform HotelRateDescriptionLLSRQ call. See below messages for details
OTA_HotelResLLSRQ GDS as legacy only. Low level error coming from the provider. EnhancedHotelBookRS with Provider error:
Unable to perform OTA_HotelResLLSRQ call. See below messages for details
eg.
‡INVALID CARD NUMBER
‡INVLD‡ DEPOSIT NOT ACCEPTED BY THIS PROPERTY.
‡INVLD‡ CREDIT CARD TYPE NOT ACCEPTED BY PROP
OTA_HotelResLLSRQ GDS as legacy only. Low level service returned a success response but with an empty payload. EnhancedHotelBookRS with Provider error:
Hotel segment created successfully but no booking details were retrieved from the provider. Please redisplay the reservation to validate the addition of a new hotel segment.
UpdateReservationRQ All scenarios. Required missing data. EnhancedHotelBookRS with Provider error:
Unable to perform hotel booking step. See below messages for details.
eg.
Agency Address is Required
TravelItineraryReadRQ All scenarios. Final segment status unsuccessful (either UC or NO) EnhancedHotelBookRS with Business error:
Hotel booking segment status is unconfirmed. Please retry the transaction
TravelItineraryReadRQ All scenarios. Confirmation number from the hotel not present EnhancedHotelBookRS with Business warning:
Hotel booking succeeded but was not confirmed by the property. No confirmation number present



Limitations of Current Release:

The Enhanced Hotel Book API has been released with its final schema while certain capabilities are still in work. Users of this API need to be aware that these capabilities are not supported:

Item Description CERT Status PROD Status
# None identified N/A N/A



Frequently Asked Questions (FAQs)

Why would I use this API to book lodging content?

The Enhanced Hotel Book API enables shopping to be conducted using Content Services for Lodging and the booking key to be used as an input in the booking request.

In the booking request, it allows GDS bookings to be created as legacy segments or as CSL segments and aggregator bookings as CSL segments.

Supporting GDS bookings as legacy segments allows agencies and third parties to use Content Services for Lodging for shopping while the changes to support Content Services for Lodging segments in mid and back office systems and True Modify to be supported.

What protocol is Enhanced Hotel Book (EHB) available in? SOAP/XML and REST/JSON?

EHB is a stateful service and is available in SOAP/XML only. A stateless version of the Enhanced Hotel Book service will be made available using Create Passenger Name Record in the near future.

Please refer to this section for more details.

What is the difference between a Content Services for Lodging (CSL) segment and a legacy segment?

CSL segments are a new type of segment in the Sabre reservation system that enables us to represent any lodging reservation in the same normalized way (independent of the booking source).

Legacy hotel segments have limitations to properly represent the new aggregator reservation data, this is the reason why Sabre is migrating lodging reservations to the new CSL segment structure.

Please refer to these additional questions on specific functional differences:

Can I cancel bookings made with this API?

GDS bookings made using Enhanced Hotel Book where the GDS segment is booked as legacy need to be cancelled (if permitted) using the existing XI cancel commands as well as the OTA_CanceLLSRQ API.

Content Services for Lodging segments need to be cancelled (if permitted) via Sabre Red 360 as well as the UpdateReservationRQ API.

Be mindful that 7B bookings (Booking.com) cannot be cancelled in lower enviornments (TEST/CERT). Booking.com does not return confirmation number in environments that are non-Production.

Note 1: Cancelling Content Services for Lodging segments via XI commands or using OTA_CanceLLSRQ is not supported. If attempted the Sabre system will respond with: CANNOT CANCEL SEGMENT SUMMARY-NOT AUTHORIZED indicating that the cancellation was not processed.

Note 2: Cancelling legacy hotel segments using for Lodging segments via the UpdateReservationRQ API is not supported. If attempted the API will respond with: Hotel Segment delete not allowed with UpdateReservation, indicating that the cancellation was not processed.

Update: Starting in April, 2020, Sabre will expose the capability to cancel both legacy & Content Services for Lodging content in a single call. The service Cancel Booking is part of the Booking Management API, exposed as RPC/JSON and will execute the cancel process independent of the content source.

Can I modify bookings made with this API?

GDS bookings made using Enhanced Hotel Book where the GDS segment is booked as legacy can be modified (if permitted) using the existing HOM modify commands as well as the HotelResModifyLLSRQ API provided by Sabre.

Modification of Content Services for Lodging segments will be available in Q1 2020 where supported by the supply source.

Do bookings made with this API generate the standard/traditional Interface-User-Records (IURs)?

If the service is used to book a GDS legacy segment then this will generate the same IUR as is generated currently, so no changes will be required to any back office system.

If the service is used to book a CSL segment (either GDS or aggregator) then this will generate a new IUR which reflects changes required for CSL bookings. These changes were detailed in SAN notification 15563 published on 21st March 2019.

After a booking is created, how can I identify if the segments in my hotel PNR are CSL or legacy segments?

Content Services for Lodging (CSL) segment:

When displaying your reservation via TravelItineraryReadRQ or GetReservationRQ, the existence of @productCategory="AGTLCSSEGMENT" in the specific lodging segment denotes a CSL segment.

TravelItineraryRS Xpath:

/TravelItineraryReadRS/TravelItinerary/ItineraryInfo/ReservationItems/Item/Product/ProductDetails@productCategory="AGTLCSSEGMENT"

TravelItineraryReadRS v3.10.0 XML snippet below:

<tir310:TravelItineraryReadRS xmlns:tir310="http://services.sabre.com/res/tir/v3_10" xmlns:stl="http://services.sabre.com/STL/v01" xmlns:or110="http://services.sabre.com/res/or/v1_11" Version="3.10.0">
    ...
    <tir310:TravelItinerary>
        ...
        <tir310:ItineraryInfo>
            <tir310:ReservationItems>
                <tir310:Item ...>
                    <tir310:Hotel ...">
                        ...
                    </tir310:Hotel>
                    <tir310:Product>
                        ...
                        <or110:ProductDetails productCategory="AGTLCSSEGMENT" ...>
                            ...
                        </or110:ProductDetails>
                    </tir310:Product>
                </tir310:Item>

GetReservationRS Xpath:

/GetReservationRS/Reservation/PassengerReservation/Segments/Segment/Product/ProductDetails@productCategory="AGTLCSSEGMENT"

GetReservationRS v1.19.0 XML snippet below:

<stl19:GetReservationRS xmlns:stl19="http://webservices.sabre.com/pnrbuilder/v1_19" 
    xmlns:ns6="http://services.sabre.com/res/orr/v0" 
    xmlns:or114="http://services.sabre.com/res/or/v1_14" 
    xmlns:raw="http://tds.sabre.com/itinerary" 
    xmlns:ns4="http://webservices.sabre.com/pnrconn/ReaccSearch" Version="1.19.0">
    <stl19:Reservation ...>
        ...
        <stl19:PassengerReservation>
            ...
            <stl19:Segments>
                <stl19:Segment ...>
                    <stl19:Hotel ...>
                        ...
                    </stl19:Hotel>
                    <stl19:Product ...>
                        ...
                        <or114:ProductDetails productCategory="AGTLCSSEGMENT" ...>
                            ...
                        </or114:ProductDetails>
                    </stl19:Product>
                </stl19:Segment>
            </stl19:Segments>

Legacy segment:

If the attribute @productCategory is not present as part of the lodging segment, this denotes that the segment is a legacy one.

Are there differences between how the PNR looks with a GDS legacy booking made using Enhanced Hotel Book (EHB) versus one made not using EHB?

A historical remark (5H) -containing the Hotel Booking Key and confirmation number- is added to the PNR if a GDS segment is made using the identifier to BookGDSviaCSL=false, designating that the booking was booked through this path for research / reporting.

Content Services for Lodging segments booked through EHB do not contain this remark.

Can the API client shop in one PCC and book in another PCC?

Yes as long as corresponding authorization between PCCs exists.

How? The Enhanced Hotel Book API behaves in a stateful way, so users who desire to change PCCs between shop and book can execute a "Change AAA" call via the ContextChangeLLSRQ API prior executing EnhancedHotelBookRQ.

Does Enhanced Hotel Book support payment via Sabre Virtual Payments (SVP)?

Enhanced Hotel Book does not currently support payment via Sabre Virtual Payments SVP). Support for SVP for CSL content is planned for 3Q 2020.