The AirTicketRQ API allows client applications to:
- Issue multiple Air Tickets and EMDs within a single call
- Issue multiple PQRs in one call
- Issue more than one PTC in the same transaction with installments
- Integrate printer address designation/un-designation
- Manage sessions on behalf of the client application
- Manage error handling to ensure the successful issuance of an Air Ticket
- Return newly issued ticket numbers together with additional details pertaining to specific documents
- Handle Context change/AAA (modify target city)
- Delete air accounting lines prior to ticketing
The API performs several steps to issue a single ticket or multiple tickets:
- Performs an ignore transaction to ensure that the AAA is clear
- Handles context change/AAA (modify target city)
- Validates the existence of an
- Designates printers
- Retrieves an existing reservation using the record locator provided within the payload
- Deletes accounting lines prior to ticketing, issuea a single ticket (ETR/EMD/PQR) or multiple tickets
- Ends transaction and commits the tickets to the face of the PNR (this step is omitted when the
- Retrieves newly generated ticket details
- Undesignates printers
- Performs ignore transaction after the transaction to ensure that the AAA is clear
Single Call Strategy
A single ticketing instruction (single call to
AirTicketLLSRQ) is generated by sending a single instance of
The API follows the workflow below:
- Sends a single call to low level service, AirTicketLLSRQ
- If the
TJRsetting is on (
AUTOER), the issued ticket will be automatically commited to the PNR. The EndtransactionLLSRQ call is omitted.
- Attempts to retrieve the newly issued ticket details by calling the low-level API, TicketingDocumentServicesRQ
- When all ticket details have been collected, attempts to undesignate all previously designated printers, ignores the transaction (to clean the session), and reverts the target city if previously specified within the request payload
Refer to the diagram below for more details:
Issuing Multiple Tickets
To issue multiple tickets/ticket types, send the
…/AirTicketRQ/Ticketing element within the request payload as many times as there are tickets are to be generated.
The AirTicketRQ API will then perform a single ticket issuance (as decribed in the above paragraph) and attempt to perform the steps below:
- Ignores the transaction to clear session data
- Retrieves the reservation
- Performs a single call to the low-level service, AirTicketLLSRQ
- If the
TJRsetting is on (
AUTOER), the issued ticket will be automatically commited to the PNR. The EndtransactionLLSRQ call will be omitted.
If there are more tickets to be issued, the above steps will be repeated as many times for as many
…/AirTicketRQ/Ticketing elements are present within the request payload. When the whole process is completed, the API will attempt to retrieve the newly issued ticket details by calling TicketingDocumentServicesRQ.
See the diagram below for more details:
Handling Mask Scenarios
There are a number of mask scenarios that can be triggered during ticket issuance. The ones that are handled by the orchestrated AirTicketRQ API are:
UNABLE TO TICKET STORED FARE - PQ EXPIRED – handled by
VERIFY TKT TTL (*) TICKET – handled by
UNABLE TO TICKET STORED FARE - NEGOTIATED FARE STORED – handled by
The AirTicketRQ API will attempt to recover from minor errors, but when it encounters a critical error, it will throw the below message:
<Message code="ERR.SP.PROVIDER_ERROR">No new tickets have been issued</Message>
This message means that all low-level AirTicketLLSRQ calls (or one, in the event of a single ticket transaction) failed, and that the application was not able to issue any tickets.
Additionally, the orchestration engine will collect error messages coming from low-level services to indicate which specific ticketing transaction (a specific instance of
/AirTicketRQ/Ticketing) failed and which low-level service triggered it:
<ApplicationResults xmlns="http://services.sabre.com/STL_Payload/v02_01" status="Incomplete">
<Error type="Application" timeStamp="2018-11-07T01:56:16.357-06:00">
<Message code="ERR.SP.PROVIDER_ERROR">No new tickets have been
<Warning type="Application" timeStamp="2018-11-07T01:56:10.731-06:00">
<Message code="WARN.SP.PROVIDER_WARNING">AirTicketLLS failed for
/Ticketing with Cause: AirTicketLLSRQ: TKT PRT NOT ASSIGNED/USE W*-1496</Message>
There is a possibility that all AirTicketLLSRQ calls are successful (all tickets were issued), but the application was unable to receive a successful response from TicketingDocumentServicesRQ (newly created ticket details could not be retrieved).
In this case, the API will return:
<Message code="WARN.SP.PROVIDER_ERROR">Ticketing was successful but application was
unable to retrieve new ticket details</Message>
To remedy this, retrieve the reservation using UpdateReservationRQ to check if the new tickets are within the PNR.
If there are errors from low-level services that did not prevent the API in collecting new ticket details, these errors will be passed within the
Understanding "Simultaneous Changes" Message
During the commit stage (when a newly issued ticket is in the process of being pushed onto the face of the PNR) the warning message
SIMULTANEOUS CHANGES TO PNR - USE IR TO IGNORE AND RETRIEVE PNR may appear.
When this warning is returned, the system did not immediately update the PNR with the ticket data. If the system is able to retain it, the API will update the PNR with the ticket information approximately 15 minutes after the message occurs.
We recommend reviewing the agency audit trail (using DailySalesReportLLSRQ) and validating the PNR information (using GetReservationRQ). If the ticket number does not appear in the GetReservationRQ response, but displays in the agency audit trail (DailySalesReportLLSRQ response), we recommend voiding and re-issuing the ticket.
Ghost Ticket Validation
Starting with version 1.2.1, Enhanced Air Ticket will validate the existence of ghost tickets.
Ghost tickets occur when, after ticket issuance, newly created tickets are not pushed to the Sabre reservation system (PNR). Because the Sabre and airline databases are not synchronized, the customer's reservation may not show any new documents, but they do exist in the airline database. This may result in Advance Debit Memos issued by the carrier against an agency.
In order to avoid ghost tickets, Enhanced Air Ticket has introduced two strategies:
Adds a sleep mechanism for common scenarios that may drive the creation of ghost tickets. Common scenarios include things like issuing multiple price quote records in one transaction, issuing from F line, and more.
In these cases, the system will add a delay prior to committing new tickets to the reservation. This additional time allows both databases to synchronize.
This is an automatic process not controlled by the user.
Reservation Display Validation
Introduces reservation display validation, which checks if newly issued documents appear on the face of the PNR.
This process is controlled by the user via the
Both attributes are meant to control the number of reservation redisplays and time intervals that happen in-between. After exhausting the specified redisplay limit, the response will indicate whether the document has been found in the Sabre reservation by means of setting