Skip Navigation

UpdatePassengerNameRecordRQ

Update Passenger Name Record - REST

Update Passenger Name Record - SOAP

UpdatePassengerNameRecordRQ allows client applications to:

  • Simplify the process of updating a Passenger Name Record (PNR) in a single API call (removes the need to use an individual/granular API)
  • Update reservations in a stateless way
  • Update reservation via session-based (ATH) or session-less (ATK) tokens
  • Define the API behavior when encountering the most common errors at the time of booking. For example, halt the modification of a reservation if an error is returned during a price check, or retry the booking to the next available class of service if the initial booking attempt fails.
  • Specify a different target city (PCC) for the modification of a PNR

UpdatePassengerNameRecordRQ performs different steps based on the provided criteria. This is managed by orchestrating different calls to specific APIs:

  • Adds general passenger details (names, contact details, etc.)
  • Performs air booking and pricing
  • Performs hotel booking via a booking key
  • Adds miscellaneous segment information and special service details (SSRs, remarks, TSA-related details, etc.)
  • Adds seats for air bookings
  • Finalizes the transaction (commits the changes)

General guidelines related to update operations

  • To ensure the successful execution of this API, the request should specify a valid PNR record locator at: /Itinerary/@id.
  • If you plan to provide agency and/or traveler information, a miscellaneous segment or special request details in a reservation, your request should contain ../PostProcessing/EndTransaction in order to commit the changes.

  • Additionally, if you plan to add air segments to a reservation that did not previously contain air segments, the request should contain the below information:

    • Ticketing time limit: /TravelItineraryAddInfo/AgencyInfo/Ticketing/@TicketType
    • Details of the air segments to be booked: /AirBook/OriginDestinationInformation/FlightSegment
    • Request to price the successfully booked segments: /AirPrice/PriceRequestInformation
    • Request to commit the transaction: /PostProcessing/EndTransaction /PostProcessing/EndTransaction/Source/@ReceivedFrom
    • For reservations departing to/from the US, or flying over the US, it is mandatory to pass Secure Flight Passenger Data (required by TSA): /CreatePassengerNameRecordRQ/SpecialReqDetails/SpecialService/SpecialServiceInfo/SecureFlight
    • If you plan to add hotel segments to a reservation that did not previously contain hotel segments, the request should contain the below information:
    • Travel agency address: /TravelItineraryAddInfo/AgencyInfo/Address
    • Hotel booking key: /HotelBook/BookingInfo/BookingKey
    • Request to commit the transaction: /PostProcessing/EndTransaction and /PostProcessing/EndTransaction/Source/@ReceivedFrom

Booking multiple rooms

The benefits of booking multiple hotel rooms:

  • Manage all reservations under one confirmation number
  • Book multiple rooms for several guests and get immediate confirmation/rejection from the property based on availability
  • For stateless RESTful APIs, confirm or reject all rooms in one call, instead of having to cancel other reservations later if the number of rooms available is less than required

To successfully book multiple rooms for a given property:

  1. Send multiple .../Rooms/Room elements (or JSON Room objects).
  2. Send the applicable room index value (starting from 1) - .../Rooms/Room/@RoomIndex. If you request three (3) rooms, all indices (1, 2, and 3) must be present.

Notes:

  • Each /Room element must contain at least one .../Rooms/Room/Guests/Guest
  • Each /Room element must have the same Adults/Children configuration

Important!

You cannot book different room types in the same request. This requires two separate calls to the Enhanced Hotel Book (EnhancedHotelBookRQ) API. These cases will result in a PNR that will show two different hotel segments, each for a separate room type. These cases will result in a PNR that will show two different hotel segments, each for a separate room type.

Due to limitations with supplier connectivity, when you shop for multiple rooms, we cannot guarantee that the property will have the number of required rooms.

  • If the number of requested rooms are available for a property, your sell will succeed and you will have a single segment in the PNR with multiple rooms.
  • If the number of requested rooms are not available for a property, your sell will be rejected.

Migration to the new form of payment field (*FOP)

With the release of Sabre Advance Notification (SAN) 16643, Sabre is retiring the 5- form of payment remarks field in Q1 2025.

Why are we changing this?

5- has been the traditional method of adding form of payment information in the Update Passenger Name Record (v1.1.0 and older) API. To prepare customers for the migration, version 1.2.0 of the API introduces support of the updated method of adding form of payment information.

Self-activate the new form of payment field by enabling the PNAPNR TJR setting on your PCC level.

Summary of changes
  • v1.2.0
    • Take advantage of downline calls to UpdateReservationRQ instead of the legacy AddRemarkLLSRQ API to add form of payment information
    • You can now add up to ten (10) forms of payment. Previously, only one form of payment could be added.
  • There are no other request schema changes. You may continue adding form of payment information in the same way as with previous versions.

  • Once the form of payment information is added, you will see a different identifier at /UpdatePassengerNameRecordRS/TravelItineraryRead/TravelItinerary/OpenReservationElements/OpenReservationElement[n]/@elementId

    Forms of payment added in the new way will show an extra of interfix: “-or-“.

New method snippet

<OpenReservationElement elementId="pnr-or-3" id="3" type="FP" displayIndex="1">

Old method snippet

<OpenReservationElement elementId="pnr-3" id="3" type="FP" displayIndex="1">

Supported functions

Payment type

The list below highlights the current supported form of payment types and corresponding schema paths:

  • Payment card: .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/CC_Info/PaymentCard

  • Payment card with cardholder information: .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/CC_Info/PaymentCard + .../CardHolderName

  • Cash: /SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/@Type="CASH" or "CA"

  • Check: /SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/@Type="CHECK" or "CHEQUE"

  • Non-refundable type: /SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/@Type="CASH NON REF" or "CASH NONREF" (also applies to "CA", "CHECK", "CHEQUE", or you may simply use "NON REF")

  • Agency/Agent invoice: /SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/@Type="AGT INV" or "AGT INVOICE"

Other values are currently not accepted and will be ignored by the service. The list may be expanded in the future.

Association of the form of payment to its use type and/or trip type

You may associate a form of payment with its corresponding use type or trip type. It's possible to add a new form of payment and include its association; this requires passing a matching @temporaryId that maps a new form of payment to its use or trip type.

Each form of payment can be associated with its specific use type or trip type. You can also send multiple repetitions of .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark_Association/Child to indicate different types.

When associating existing forms of payment using UpdatePassengerNameRecordRQ/SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark_Association/Parent/@displayIndex, the API may return a downstream error stating "INVALID LINE NUMBER". In this case, ensure to review the content of the session and make sure that the form of payment present in the *FOP wallet entry matches the @displayIndex attribute.

When neither Parent/@displayIndex nor ../Child/@temporaryId is passed within a single FOP_Remark_Association node, the API can return a downstream error stating "NO ASSOCIATION PARENT PROVIDED". In this case, please review the request and amend either @displayIndex when referencing a form of payment that already exists within the customer session or @temporaryId when referencing a new form of payment added in the same UpdatePassengerNameRecordRQ request.

One .../FOP_Remark_Association/Child element can contain a single-use type or trip type. If you wish to associate use/trip type (Child) to an existing form of payment (Parent), you must pass both .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark_Association/Parent (identifies an existing payment index) and .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark_Association/Child (identifies use/trip type association).

Supported use types:

  • "AZ" - All
  • "AN" - Ancillary
  • "AL" - Airline
  • "BU" - Bus/Ground Transportation
  • "CR" - Car
  • "CS" - Cruise
  • "HL" - Hotel
  • "IN" - Insurance
  • "LC" - Low-Cost Carrier
  • "OT" - Other
  • "RL" - Rail
  • "SS" - Specialty Service
  • "TR" - Tour
  • "IR" - Interface Record

Supported trip types:

  • "AZ" - All
  • "CP" - Corporate/Business
  • "LS" - Leisure
  • "EM" - Emergency
  • "FM" - Family
  • "GP" - Group

For known error scenarios related to form of payment remark association, refer to the PassengerDetailsRQ section.

Notes:

  • If you have already enabled TJR PNA PNR setting, we recommend migrating to the new functionality in version 1.2.0.
  • If you have not yet enabled the TJR PNA PNR setting:
    • You may migrate to the new functionality in version 1.2.0, but note that the addition of the payment card manual approval code (the equivalent of a Z qualifier) is not supported.
    • You may also stay on the old version of the API (1.1.0) until you are ready to migrate or before the sunset of the legacy functionality.