This extension point is executed when the user ignores a PNR from the graphical panel, or sends a manual ignore command "I(C|R)?.*".

This extension point is defined to allow Red Apps trigger their custom logic before the ignore PNR request is sent to Sabre, it may also abort the whole process.

This extension point is executed when the user ignores a PNR from the graphical panel, or sends a manual ignore command "I(C|R)?.*".

Extension is executed after receiving response (to the ignore PNR action) from Sabre, but before rendering the response to the screen.

This extension point is triggered by: sending the end command from the command line (e.g.: E, ET, ER, etc.) and ending the PNR from the graphical panel. Extension is executed upon taking one of these actions, but before the request is sent to Sabre.

This extension point is defined to allow Red Apps trigger their own logic before changes to the PNR get committed, e.g. PNR quality check or addition of agency’s internal transaction coding may be executed here.

This extension point is triggered by: sending the end command from the command line (e.g.: E, ET, ER, etc.) and ending the PNR from the graphical panel. Extension is executed after receiving response (to the end PNR action) from Sabre, but before rendering the response to the screen.

This extension point is defined to allow Red Apps trigger their own logic once the result of the end PNR command is already known, but before the response is rendered to the screen, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store certain notification.

This extension point is executed when the user places PNR on a queue in the Queue Place window or sends a manual queue place command, but before the request is sent to Sabre.

This extension point is defined to allow Red Apps trigger their own logic before the Queue Place action is committed. Typical actions performed by Red Apps here revolve around sending a PNR to additional queues, or taking advantage of the data model available here, e.g. modifying the queue number the PNR is sent to according to agency’s internal process.

This extension point is executed after receiving response to the queue place command from Sabre, but before rendering the response to the screen.

This extension point is defined to allow Red Apps trigger their own logic once the result of the queue place command is already known, but before the response is rendered to the screen, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store certain notification.

This extension point is executed when the user sends manual air price command (any WP…​ command except WPNI) or requests pricing graphically in the Advanced Pricing window (e.g. by choosing any of the options from the Pricing Options combo), but before the request is sent to Sabre.

This extension point is defined to allow Red Apps trigger their own logic before the air pricing request is committed. It is typically used to apply additional pricing qualifiers required by the agency, e.g. a corporate ID / account code / tour code to ensure proper values are used in the agency’s sales process.

This extension point is executed after receiving response to the air pricing request from Sabre, but before rendering the response to the screen.

This extension point is defined to allow Red Apps trigger their own logic once the result of the queue place command is already known, but before the response is rendered to the screen, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store certain notification.

This extension point is executed before sending the price quote creation request.

In case of a pricing request that contains the RQ qualifier, this extension point is executed after the beforePricing extension point. Please note that if the ABORT status is returned from the beforePricing extension, then the beforePriceQuoteCreation extention will not be executed.

This extension point is executed after receiving response to the price quote creation request, but before rendering the response to the screen.

In case of a pricing request that contains the RQ qualifier, this extension point is executed after the afterPricing extension point. Please note that if the ABORT status is returned from the afterPricing extension, then the afterPriceQuoteCreation extention will not be executed.

This extension point is executed before user sees the Air Shopping Form form.

Data provided through the extension point will automatically prepopulate the form. It saves agent’s time and ensures proper sales process required by the agency - Red App may convey specific shopping qualifiers to be used in the sales process (e.g. corporate ID, account code, vendor/alliance code, etc).

Workflow extension dynamo.airshopping:beforeAirShopping is executed after submitting Air Shopping form, but before the request being sent.

This extension point is executed after receiving response to the air shopping request from Sabre, but before rendering the response to the screen.

This extension point is defined to allow Red Apps trigger custom logic once the result of the air shopping is already known, but before the response is rendered to the screen, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store certain notification.

This extension point is executed when user books itinerary from the Air Shopping response via the "Sell & Save Price" button.

This extension point is used by some of Sabre-powered agencies to analyze sales decision factors in the booking process. To take advantage of if, the agency needs to use decorate Sabre’s air shopping response with its own tags (or use Sabre-generated tags), then at the time of booking ("Sell & Save Price") Red App may read such data in the extension point to be further stored and analyzed by the agency management.

This extension point is executed after user books itinerary from the Air Shopping response via the "Sell & Save Price" button. It is executed after receiving the response, but before it is displayed to the user.

This extension point is executed before user sees the "Issue ticket" form modal.

Data provided through the extension point will automatically prepopulate the form. It saves agent’s time and ensures proper ticketing process required by the agency - Red App may convey specific ticketing qualifiers (e.g. endorsment value, validating carrier, commission, etc).

This extension point is executed when the ticketing agent issues a ticket in the "Issue ticket" window, or sends a manual issue ticket command (W¥…​), but before the request is sent to Sabre.

This saves agent’s time and ensures proper ticketing process required by the agency - Red App may perform quality check for or actively insert/override specific ticketing qualifiers (e.g. endorsment value, validating carrier, commission, etc), it may also abort the whole process or perform any custom logic whenever data used for ticketing do not meet agency’s requirements.

This extension point is executed after receiving response to the ticketing request from Sabre, but before rendering the response to the screen.

This extension point is defined to allow Red Apps trigger their custom logic once the result of the ticketing request is already known, but before the response is rendered to the screen, e.g. to generate important reminder for the ticketing agent, suggest certain action, or generate/send/store custom notification.

This extension point is executed when the user voids a document (ticket or EMD) in the 'Cancel ticket/EMD' window, or sends a manual void command (WV.* (except WV*), WETRV, WEMDV). Extension point is triggered on each void request (first request and confirmation request).

Be aware that in the case of EMD in NDC, this extension point also works for refund (in addition to void). This is due to external limitations.

This extension point is defined to allow Red Apps trigger their custom logic before the void request is sent to Sabre, it may also abort the whole process.

This extension point is executed after receiving response to the void document (ticket or EMD) request from Sabre, but before rendering the response to the screen or showing response in modal. It is triggered by the graphical path in the 'Cancel ticket/EMD' window and the manual void command (WV.* (except WV*), WETRV, WEMDV). Extension point is triggered on each void request (first request and confirmation request).

Be aware that in the case of EMD in NDC, this extension point also works for refund (in addition to void). This is due to external limitations.

This extension point is defined to allow Red Apps trigger custom logic once the result of the void document is already known, but before the response is rendered to the screen or shown in modal, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store certain notification. It is up to the RedApp developer to verify if ticket or EMD is voided.

This extension point is executed when the user sends a manual cancel refund (WTRX.*) command, but before the request is sent to Sabre.

This extension point is executed when response for cancel document refund command (WTRX.*) is returned.

This extension point is defined to allow Red Apps trigger their custom logic after the cancel document refund request is sent to Sabre and before the response is displayed.

This extension point is executed when the user revalidates the electronic ticket record by sending a manual command (WETRL/.*).

This extension point is defined to allow Red Apps trigger their custom logic before the revalidate request is sent to Sabre, it may also abort the whole process.

This extension point is executed when response for revalidate ticket command (WETRL/.*) is returned.

This extension point is defined to allow Red Apps trigger their custom logic after the revalidate request is sent to Sabre and before the response is displayed.

This extension point is executed before user sees the exchange comparison form modal (launched during the ticket exchange procedure).

Data provided through the extension point will automatically prepopulate the form. It saves agent’s time and ensures proper ticketing process required by the agency.

This extension point is executed after user sends exchange comparison form data. Data provided to the extension point contains exchange comparison result with messages.

This extension point is executed before user sees the exchange confirmation form modal (launched during the ticket exchange procedure).

Data provided through the extension point will automatically prepopulate the form. It saves agent’s time and ensures proper ticketing process required by the agency.

This extension point is executed after user sends exchange confirmation form data.

Data provided to the extension point contains exchange confirmation result with PQR number in case of success or error messages in case of failure.

This extension point is executed before a reservation/order modify request is sent to Sabre. It is triggered: - by adding passive CSL hotel segment using hotel search or HOT command results - by "Add to PNR" modal when adding Phone/Email/Frequent Flyer/Security Information provided NDC Security Info is present in order

It allows agent to provide additional information before the modify request is finally sent which can prevent mistakes and gives more control over the reservation process as a whole.

This extension point is executed before a passive air segment is added to the itinerary either graphically from the "Add to PNR" modal, or from the command line (e.g. by sending the 0LO279Y17JULWAWLHRYK1 command).

It allows to trigger Red App’s custom logic when adding passive air segments. Red Apps may read and override passive air segment’s data according to the agency’s needs. This provides better agency’s control over adding passive segments - it may speed up the whole process and eliminate potential mistakes.

This extension point is executed after a CreateOrUpdateRs with air passive add response is retrieved.

This extension point is defined to allow Red Apps trigger custom logic once the result of the request to add an air passive segment is already known, but before the response is rendered to the screen, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store certain notification.

This extension point is defined to make Red Apps able to modify passive hotel segment(s) properties before request is actually sent. After filling in the hotel passive segment graphical form or sending manual 0HHT command, data are passed to the extension point and can be read or modified by a Red App. Then the flow continues with the modified properties.

The BeforeHotelPassiveAdd extension point is executed before a passive hotel segment is added to the itinerary from:

Commands with incorrect format won’t trigger the extension point.

This extension point is defined to make Red Apps able to modify/extend the flow once passive hotel segment is added to the PNR. The AfterHotelPassiveAdd extension point is executed after response is retrieved, but before it is displayed to the user. Trigger points are described in beforeHotelPassiveAdd section.

This extension point is defined to make Red Apps able to modify passive car segment properties before a request is actually sent. After filling in the passive car segment form, data are passed to the extension point and can be read or modified by a Red App. The flow will proceed with the modified request.

The BeforeCarPassiveAdd extension point is executed before a passive car segment is added to the itinerary. It is invoked only when a segment is added from the "Add To PNR" modal. Adding a passive car segment by sending a Sabre 0CAR…​GK1…​ command will not trigger the extension point.

This extension point is defined to make RedApps able to modify/extend the flow once a passive car segment was added to the PNR.

The AfterCarPassiveAdd extension point is executed after a passive car segment is added and the response is received, but before the response modal is displayed. It is invoked only when a segment is added from the "Add to PNR" modal. Adding a passive car segment by sending a Sabre 0CAR…​GK1…​ command will not trigger the extension point.

This extension point is defined to make Red Apps able to modify passive other segment(s) properties before a request is actually sent. Data passed to the extension point can be read and modified by a Red App. Then the flow continues with the modified properties.

The BeforeOtherPassiveAdd extension point is executed before a passive other segment is added to the itinerary from:

Commands with incorrect format won’t trigger the extension point.

This extension point is defined to make RedApps able to modify/extend the flow once a passive other segment was added to the PNR. The AfterOtherPassiveAdd extension point is executed after a passive other segment is added and the response is received, but before the response is displayed. Trigger points are described in beforeOtherPassiveAdd section.

This extension point is executed when the user issues a miscellaneous intelligent service fee.

This extension point is defined to allow Red Apps trigger their custom logic before the issue request is sent to Sabre, it may also abort the whole process.

This extension point is executed after the user issues a miscellaneous intelligent service fee.

This extension point is defined to allow Red Apps trigger their custom logic after the issue request is sent to Sabre and before the response is displayed.

This extension point is executed before user deletes a segment: - by sending cancel itinerary segments (X) commands, - from Trip Summary in the "Delete segments" window, - from the "ITINERARY" section in Graphical PNR, - by clicking the "Cancel PNR" button available in the expandable 'drawer' section under the main PNR header in Graphical PNR, but before the request is sent to Sabre.

This extension point is executed after the response to the cancel segment(s) request is received, but before the response is rendered to the screen.

This extension point is defined to allow Red Apps trigger custom logic once the response to the cancel segment(s) request is received, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store custom notification.

This extension point is executed before user sees the "Create order" form modal when working with an NDC itinerary. Data provided through the extension point will automatically prepopulate the form. NOTE: If phones or emails data are provided by the extension point no other phones or emails data will be prepopulated from the user session if they are being observed there. NOTE: Multi ADT passenger types are supported.

This extension point is executed: a/ for customers with CSL (Content Services for Lodging) configuration enabled: after a hotel shopping request is triggered by the agent by either sending the HOT command from the command line or hitting the "Shop Hotels" in the graphical hotel shopping form, but before the request is sent to Sabre services. NOTE: CSL content (multi-host) is the default configuration for {short_brand_name} users. b/ for customers with CSL content disabled, i.e. with legacy hotel path only (Sabre content only): after a hotel shopping request is triggered by the agent by either sending the HOT command from the command line or hitting the "Shop Hotels" in the graphical hotel shopping form, but before the request is sent to Sabre services.

This extension point is defined to allow for Red Apps to execute their logic before sending a hotel shopping request. Red Apps may either trigger custom actions, or - while relying on the extension point’s data model - read and override properties of the hotel shopping request, e.g. hotel chain code, property name, zip code, distance from a point of interest, check-in date, etc. Red Apps that leverage this extension point may then easily control user’s workflow, append additional hotel shopping qualifiers according to agency’s goals, or trigger custom actions (alerting, notifications, reporting, cross-selling, etc.) based on the data used in agent’s request.

This extension point is executed after the hotel shopping response is received, but before it is rendered to the screen. It is defined to allow Red Apps trigger custom logic once the response to the hotel shopping request is received, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store custom notification.

This extension point is executed after a user either sends a HOD-type Sabre command from the command line, or sends a hotel rate request from the Hotel Availability display (by clicking the "View Rates" button available in the expandable 'drawer' widget provided for each option of the Hotel shopping response), but before the request is sent to the Sabre host.

This extension point is defined to allow for Red Apps to execute their logic before sending a hotel details request. Red Apps may either trigger custom actions, or - while relying on the extension point’s data model - read and override properties of the hotel details request, e.g. Property ID, Check-in date, Rate code, etc. Red Apps that leverage this extension point may then easily control user’s workflow, append additional hotel details qualifiers according to agency’s goals, or trigger custom actions (alerting, notifications, reporting, cross-selling, etc.) based on the data used in agent’s request.

This extension point is executed after the hotel details response is received, but before it is rendered to the screen. It is defined to allow Red Apps trigger custom logic once the response to the hotel details request is received, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store custom notification. There is an extensive read-only data model defined for this extension point, which makes it possible to read and leverage various hotel offering details data while performing Red App’s logic.

This extension point is executed before user sees the Hotel Reservation form. Data provided through the extension point will automatically prepopulate the form. To make use of this extension point CSL enabled is required. Extension point can be triggered from command such as "0H1¥1" or from graphical path:

An agent either sends a 0Hx-type (hotel sell) Sabre command from the command line, or sends a hotel book request from the graphical Hotel Rates window (by clicking the "Book" button available in the expandable 'drawer' widget provided for each option of the Hotel Rates response). This action opens Hotel Reservation modal window. The extension point is executed after clicking the "Book" button on the modal window or triggered by the manual command, but before the request is sent to the Sabre host.

This extension point is defined to allow for Red Apps to execute their logic before sending a hotel sell request. Red Apps may read and override data in the hotel sell request, it may be especially important regarding the Credit Card value - agencies may leverage this extension point to automize charging the chosen card for agency transactions.

Important note: CreditCardInfo is not exposed in this extension (the field is null). However, it is possible for the Red App to supply credit card information by setting the CreditCardInfo field. Check details of the data model in Javadocs.

This extension point is executed after the hotel sell (book) response is received, but before it is rendered to the screen. It is defined to allow Red Apps trigger custom logic once the response to the hotel sell request is received, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store custom notification.

This extension point is executed after the hotel modify response is received, but before it is rendered to the screen. It is defined to allow Red Apps trigger custom logic once the response to the hotel modify request is received, e.g. to generate important reminder for agent, suggest certain action, or generate/send/store custom notification. There is an extensive read-only data model defined for this extension point, which makes it possible to read and leverage various hotel segment details (e.g. Segment number,Check-in date,Total price, Chain code, etc.) data while performing Red App’s logic.

This extension point is executed after user submits air availability request (from graphical form or manual CPA command) but prior final command execution. Modified request will be utilized to build final air availability command executed against Sabre System (sample command: 122JULDFWORD).

Note: In case where agent is requesting multi air availability from graphical form then all legs are present in extension data model. So far it is not possible to add/remove air availability legs in request or modify their sequence.

This extension point is executed after segment(s) are booked from availability response, either using graphical style and clicking 'Sell' button from the drawer or using manual command (e.g. 01Y1). It provides detailed information about the flight segments booked in a single booking transaction.

This extension point is executed before 'Car Book' graphical form, opened from air segment in Trip Summary, is displayed. It allows modification of the data that is displayed on the form.

This extension point is executed before 'Car Reservation' graphical form, opened after pressing select button on one of the listed car segment displayed after car search.