Skip to main content



The PassengerDetailsRQ service allows client applications to create shell PNRs containing names, phone numbers, email addresses, customer numbers, passenger types, address information, remarks, and retention segments.

The client application can end the transaction once processing is complete, or leave the transaction open in the AAA for subsequent processing. If this option is chosen, the client application can add additional information into the PNR via existing TPF Connector-based Sabre Web Service calls, or other orchestrated service calls, before ending the transaction.

PassengerDetailsRQ orchestrates the following operations:

  1. SabreCommandLLSRQ (N*(Profile Name)(end-item)NM)
  2. TravelItineraryAddInfoLLSRQ (-, 9, PE, DK, PD, W-, 7)
  3. MiscSegmentSellLLSRQ (0OTH, 0MCO, 0INS, 0PTA)
  4. SpecialServiceLLSRQ (3, 4)
  5. AddRemarkLLSRQ (5)
  6. AirSeatLLSRQ (4G)
  8. SabreCommandLLSRQ (PQL(record number)(* or –)(name number)
  9. EndTransactionLLSRQ (6, E)
  10. QueuePlaceLLSRQ (QP)
  11. User defined wait interval before reservation redisplay
  12. TravelItineraryReadRQ
  13. IgnoreTransactionLLSRQ (I)

Client applications can pass on any of the services contained within the workflow outlined previously, and in terms of responses they can opt to only receive the record locator generated as a result of the process, or to receive the entire PNR generated as a result of the process via the TravelItineraryReadRQ response message.

In the event you use PassengerDetailsRQ to add frequent flyer number to the PNR and PostProcessing/@RedisplayReservation is set to true, the orchestration engine will ensure that frequent flyer information is added to the PNR before the response is returned to your customer. If PassengerDetailsRQ doesn’t find frequent flyer information in the PNR, it will perform two (2) more attempts, each after 1 second delay. If frequent flyer data is not present in the PNR after 3 attempts, the response is returned and a warning is added to ApplicationResults: Missing expected CustLoyalty information.


<?xml version="1.0" encoding="UTF-8"?>
<PassengerDetailsRS xmlns="">
  <stl:ApplicationResults xmlns:stl=""
      <stl:Success timeStamp="2019-01-08T07:13:47.884-05:00"/>
      <stl:Warning type="BusinessLogic" timeStamp="2019-01-21T09:44:44.353-05:00">
            <stl:Message code="WARN.SP.PROVIDER_WARNING">Missing expected
CustLoyalty information</stl:Message>

Completing a reservation with PassengerDetailsRQ after a call to EnhancedAirBookRQ

When the client application needs the PNR to store Price Quote records, the PNR can be completed by performing a call to EnhancedAirBookRQ plus a single subsequent call to PassengerDetailsRQ. Whenever the price Retain flag is set to true (to retain the Price Quote records in the PNR) within the EnhancedAirBookRQ service call,

<!-- .... -->
 <PriceComparison AmountSpecified="88.2"/>
 <PriceRequestInformation Retain="true">
     <PassengerType Code="ADT" Quantity="1"/>
     <PassengerType Code="INF" Quantity="1"/>
<!-- .... -->

and the client application wants to create a PNR as the result of the subsequent PassengerDetailsRQ service call, then the same PassengerDetailsRQ request needs to explicitly specify the relationship/link between the passengers and the Price Quote record(s) that will be generated and retained in the PNR being built.

Note: The PNR is completed by filling in mandatory information like contact phone number, ticket time limit, received from, passenger name(s), and using PostProcessing/EndTransactionRQ/EndTransaction Ind="true".

The relationship stated above needs to be established using the passenger name number of each passenger and the associated Price Quote record number, considering the passenger type.

For example, if the call to EnhancedAirBookRQ includes the OTA_PriceRQ section as shown above, the following Price Quote records will be generated:

  • Price Quote Record #1 for Adult (ADT) passengers
  • Price Quote Record #2 for Infant (INF) passengers

Note: When generating and retaining Price Quote records, the EnhancedAirBookRQ service respects the order in which the PassengerType elements are specified, so the order of the associated Price Quote record numbers is the same.

This way, the call to PassengerDetailsRQ needs to include:

  <Link NameNumber="1.1" Record="1"/>
  <Link NameNumber="2.1" Record="2"/>

Considering the NameNumber and PassengerType fields are also specified for each passenger in the same PassengerDetailsRQ:

 <!-- .... -->
 <PersonName NameNumber="1.1" PassengerType="ADT">
 <PersonName Infant="true" NameNumber="2.1" PassengerType="INF">

Important! If the price Retain flag is set to true in the EnhancedAirBookRQ service call, but no relationship/link to the generated and retained Price Quote record/s is specified in the PassengerDetailsRQ service call, then the PassengerDetailsRQ response will return this error:


Automated handling of hosted vs.non-hosted indicators for SSRs/OSIs

Due to Sabre specifics, it's necessary to append information based on whether SSR/OSI information should be passed to a hosted or non-hosted carrier. This is controlled within PassengerDetailsRQ by the below attributes:

/PassengerDetailsRQ/SpecialReqDetails/SpecialService/SpecialServiceInfo/AdvancePassenger/ VendorPrefs/Airline/@Hosted

Please note that from version 3.3.0, the API will handle the above flags automatically. Therefore, it is not necessary to include below elements/attributes within the payload: