Air Booking Guide

The JSON APIs booking workflow uses a workbench session and multiple requests to create a held air reservation for later fulfillment, called a booking.

This guide summarizes the steps in the workflow. Endpoints, requests, responses, and examples are in the API Reference for each step, linked below.

Related Content: JSON Air APIs Guide, Reservation Retrieve Guide, Multi-content Booking Guide (Air, Hotel, Car), Ticketing Guide

In this topic:

• Basic Concepts
• Workbench Actions Summary
• Booking Workflow Summary
• Booking Workflow Diagrams
  • Hold and Pay Workflow
  • Add Product Workflow (omit Search and Price)
  • NDC Instant Pay Workflow (book and ticket in same workbench)
  • Expired Booking Workflow
• Book Commit Response Layout Diagram
• Optional Actions at Workbench Commit
  • Enable Pre-Commit Warnings for Price/Schedule Changes, or Connect Time (MCT)
  • Create Retention Segments
  • Confirm Involuntary Schedule Change
  • Update or Delete Ticketing Time Limit Date
  • Add ReceivedFrom for Deem
  • Create Shell Booking in Case of Booking Failure
• NDC Flight Disruption Handling
• Passive Segments
• Unpriced Segments and AutoPrice/Manual Fares
• Remove Offers, Products, Segments, or Filed Fares from a Booking
• Multi-offer Bookings
• Multi-content Bookings (Air and Hotel and/or Car Content)
• Travel Agency Details
• Custom Booking Rules

Basic Concepts

The booking process uses a workflow of multiple calls to create a workbench session, add an offer for flight/s to the workbench, add travelers to the workbench, and commit the workbench. Booking also supports several optional actions, such as adding or modifying seats, paid ancillaries, and remarks and special service requests. Once the workbench is successfully committed and the flights confirmed by the carrier, the details added during the booking workflow are referred to as the reservation, or the booking. The terms booking and reservation are interchangeable.

Some agents and airlines may use the term PNR for a reservation . Because PNR is specific to GDS only, this online help uses the more generic terms reservation or booking instead.

Committing the workbench at the end of the booking workflow creates a held booking: The booking is confirmed by the airline but not yet ticketed. The booking must still be ticketed in an additional workbench session, and will expire if ticketing doesn't take place within a certain time, usually within 24 hours of booking. Expiration and ticketing time limits are returned in the commit response in TermsAndConditionsFull/ExpiryDate and PaymentTimeLimit.

The commit response returns all details added to date about the booking, which generally include the offer (actual air segments booked), traveler details, and reservation confirmation information. A successful booking returns a unique six-digit alphanumeric number called the reservation locator in Receipt/Confirmation/Locator.

During the workbench commit, for GDS only, you can send the autoDeleteDate query parameter to ensure that even if the booking fails, a reservation shell is created to retain the traveler details and allow the booking to be completed later. See Create Reservation Shell in Case of Booking Failure below.

After booking you can retrieve booking details with a Reservation Retrieve.

While the above is the standard booking workflow, the JSON APIs also support these alternate booking workflows (see below):

• Expired Booking workflow: Renew an expired booking, meaning that the offer on a held reservation has expired and can no longer be ticketed at the held price.

• Add Product booking flow: Start with booking and skip the Search and AirPrice steps; however, you must already have full details for the itinerary to book. GDS only.

• Instant Pay workflow: Create the reservation and issue the ticket/s in the same workbench session. NDC only; not supported for GDS.

• Ticketless carriers workflow: For ticketless carriers, the booking is issued and completed in the commit step; there is no separate ticketing step.

Workbench Action Summary

All steps in the booking workflow take place in a workbench session, which is like a container that holds all details as they are added before sending them to the carrier all at once.

To start a new booking, create a new workbench. The response returns a workbench identifier that is sent in the HTTP request of all subsequent transactions in that workbench. When the workbench is committed, the booking details become part of the reservation record and the workbench is discarded.

Once a booking is made and a reservation issued, any further updates or changes to that reservation, including ticketing, generally also take place in a workbench. Because the initial booking has already been committed, this is called a post-commit workbench and is created using the reservation locator of the booking to modify.

Workbench Requests List

The table below lists all available actions and links to the API reference for each request, which provides endpoints and examples. These workbench actions are not sequential and would not all take place in the same session.

Workbench Action	Description and Notes	API Reference
Create an initial booking workbench	Create new workbench when no booking exists. Returns an identifier for the workbench that must be sent in all subsequent calls in that session. First step in the initial booking workflow.	New Workbench API Reference
Create post-commit workbench	Initiate a workbench for an existing booking by sending the reservation locator code in the POST request. First step for any workbench session to modify, update, or ticket an existing reservation.	Post-Commit Workbench API Reference
Retrieve workbench	Returns all workbench details added up to the time of the retrieve.	Retrieve Workbench API Reference
Cancel items from workbench	Cancels a reservation, or removes offers from a booking or a workbench. Supports the following at this time; see the Cancel Workbench Items API Reference for details: in an initial booking workbench, canceling all offers in the workbench; supported only for NDC in a post-commit workbench, canceling either the entire booking or only the offers on a booking; supported only for GDS	Cancel Workbench Items API Reference
Delete data from the workbench	Deletes selected data from the workbench, such as a remark. Only specific information can be deleted.	Several add/delete requests are supported in both initial and post-commit workbench. See Traveler Modify Guide and Remarks and Service Requests Guide.
Commit the workbench	Closes the workbench session and finalizes all transactions in workbench. Depending on the workbench, the commit may create a held booking, issue a ticket, update a reservation, or exchange a ticket. Final step in all workbench sessions.	Commit Workbench API Reference
Discard workbench	Discards the workbench and deletes all data in it.	Workbench Discard API Reference

Booking Workflow Summary

To create a booking, at a minimum, you must create a workbench session, add an air offer, add at least one traveler, and commit the workbench. Certain optional steps are also supported.

The following table summarizes the required and optional steps. The API reference for each request provides endpoints, payloads, and examples.

Step #	Booking Workflow Step	Description and Notes	API Reference
1	Create the workbench	First step in the workflow. Returns a system-generated identifier for the workbench that must be sent in subsequent requests for that workbench.	New Workbench API Reference
2 or 3	Add offer	Add the offer (flight details) to the workbench. Supports either a full payload request that sends all required itinerary details, or a reference payload request that references flights returned in a preceding Search response. You can add either the offer or traveler/s first. Returns a system-generated identifier for the offer that is part of the booking record and must be sent in subsequent transactions about that offer. Add multiple offers To combine multiple offers into one reservation (GDS only; not supported for NDC), called a multi-offer booking, repeat the Add Offer step as needed. You can use either the full or reference payload. While there is no specific limit on the number of offers that can be combined, a reservation cannot have more than 16 flight segments. When adding an unpriced segment An air segment without any associated fare or pricing, generally booked for availability versus cost. Shown in the UnpricedSegments object instead of the Offer object. GDS only; NDC does not use unpriced segments. to the workbench, use the Unpriced Segment API instead of Add Offer. Or, or if adding both an unpriced segment and an offer, send both Unpriced Segment and Add Offer .	Add Offer Reference Payload API Reference   Add Offer Full Payload API Reference
2 or 3	Add traveler	Send traveler details such as name and contact information, and optional comments and service requests. You can add either the offer or traveler/s first. Returns a system-generated identifier for the traveler that is part of the reservation record and sent in subsequent transactions about that traveler, such as seat selection. Optionally, if the traveler has a personal and/or business profile in the Travelport host system, you can send the Host Profile Move request to copy traveler details into the booking instead of sending Add Traveler. GDS only; not supported for NDC. Any traveler sent without a PTC (passenger type code) value is defaulted to ADT. PTC can be sent or omitted for ADT travelers. An INF (infant) cannot be added without an ADT (adult) PTC. Only select traveler information can be modified after a traveler is added. See Traveler Modify Guide.	Add Traveler API Reference Remarks & Service Requests Guide
optional after offer and traveler	Shop and book seats	Requesting seat availability and adding seats is supported in the initial booking workflow as per the Seats Guide after adding an offer and traveler. To add ancillaries or seats to a multi-offer booking, send the Ancillary Shop or Seat Map request, then send one book request for each offer, in any order. Supported in the initial booking workflow only for free seats; supported for an existing booking for both ancillaries and seats. GDS only; multi-offers not supported for NDC.	Seats Guide
optional after offer and traveler	Shop and book ancillaries	Certain paid ancillaries are supported in the initial booking workflow as per the Ancillaries Guide after adding an offer and traveler.	Ancillaries Guide
optional after offer and traveler	Add comments and service requests	Certain comments/service requests can be added separately from the Add Traveler payload.	Remarks & Service Requests Guide
optional after offer and traveler	Add form of payment (FOP)	Store form of payment (FOP) information with the reservation to be used subsequently in ticketing. The response returns a system-generated identifier for the FOP that is part of the reservation record and sent in subsequent Add Payment request. Adding FOP for GDS in the booking flow is optional. If sent, FOP is stored and retrieved later during ticketing. If not sent at booking, FOP is required at ticketing. Adding FOP for NDC is not supported in booking, only at ticketing or in the Instant Pay workflow. If FOP is added but payment and ticketing are not completed, the FOP is not stored and is not available for retrieval during ticketing. Ticketless carriers require FOP. The booking is issued and completed in the commit step; there is no ticketing step. Add Multiple Forms of Payment (GDS only) For GDS only, you can add up to two FOP in either the booking or ticketing workflow by sending a Form of Payment request for each FOP. At ticketing you must send a separate Add Payment request for each FOP. The additional FOP can be any supported form of payment. Multiple FOP are supported only for bookings with a single passenger.	Add Form of Payment API Reference
Final step	Commit the workbench and create booking	Final step in the booking workflow. Creates a held booking for subsequent ticketing. A successful workbench commit creates a held booking, returns a confirmation from the supplier, and returns a unique six-digit alphanumeric code for that booking, called a locator code. This locator code must be sent in any subsequent transactions for this booking. GDS bookings return a single locator code issued by Travelport. NDC bookings return two locator codes, one issued by the NDC carrier and another from Travelport - the Travelport code is called the passive locator code. For more details on NDC locator codes and an example see Passive Booking Records in the NDC Guide. The commit response is largely the same as but not identical to a Reservation Retrieve response. The commit does not return any document override or accounting comments. Commit for ticketless carriers creates a booking with the carrier. There is no ticketing step. Notes on workbench commit at end of the initial booking workflow If any pricing modifier sent in the Add Offer full payload or reference payload request does not have any fares associated with it, the commit fails and returns the error message No Fare Found. Pricing happens at the commit, not the Add Offer step. Shell Reservations for Failed Bookings You can choose to create a shell booking if a booking fails either because the offer cannot be added or the fare cannot be quoted. This shell booking retains the traveler details and allows the booking to be completed later. To do so, in the initial booking workflow, send the autoDeleteDate query parameter at the workbench commit. See Create Shell Booking in Case of Booking Failure. Retention Segments By default, reservation details are stored for one month after all travel on the itinerary is completed. You can extend this time by setting a purge date in the autoDeleteDate query parameter at the workbench commit in the initial booking workflow. See Retention Segments in the Booking Guide. CarrierLocator Code Delay at Booking In some instances, the carrier requires additional time to return the carrier locator code, which can be an issue for agencies that require this code at the time of booking. So, if the carrier locator code is not immediately available, AirReservation makes one attempt to retrieve the reservation from the carrier. If the carrier locator code cannot be retrieved, AirReservation returns the warning: Carrier locator code not returned by carrier/provider. Please try to retrieve later and agencies must retrieve the reservation later. This can happen in any booking scenario upon commit but is most common when the booking contains an ancillary such as a wheelchair.	Commit Workbench API Reference

Booking Workflow Diagrams

Hold and Pay Workflow

The following diagram shows all required and some optional steps in the typical JSON API booking workflow. This workflow follows a preceding Search request to find the flight/s to book. Ticketing happens in a subsequent workbench.

You can shop for and add seats and ancillaries either during booking or ticketing, or in a separate workbench session, per the support noted in the Seats and Ancillaries guides.

Sending form of payment (FOP) in the initial booking workflow is supported only for GDS. If FOP is added for NDC it is not stored and must be sent again at ticketing.

See the following section and All Book and Ticketing Workflows for other workflows.

Add Product Workflow (omit Search and Price)

As an alternative to the entire JSON API minimum required workflow, you can send Add Product at booking instead of Add Offer. Add Product is a full payload request that allows you to skip the Search and AirPrice steps and start with booking. You must already have full details for the itinerary to book. This request is best suited for corporate customers who frequently travel the same itinerary and do not need or want to check price or alternative options. The request sends flight and class of service data as sourced from outside the JSON APIs.

You may choose to check pricing with a Standalone Price request. You can send Standalone Price in any workbench session.

You can send the optional Fare Display request (not shown below) in any workbench session to retrieve fare rule text for an itinerary.

Booking seats and/or ancillaries is not supported in the initial booking workflow for Add Product. You can add those in a separate workbench after creating the reservation.

NDC Instant Pay Workflow (book and ticket in same workbench)

The Instant Pay workflow, supported only for NDC, allows you to book and ticket in the same workbench session.

Booking ancillaries is not supported in the Instant Pay workflow.

Expired Booking Workflow

An air offer is valid only for a set length of time before it either must be ticketed or will expire. Several JSON APIs, including AirPrice when pricing an offer and Reservation Retrieve when retrieving a held booking, return TermsAndConditionsFull/ExpiryDate with the date and time the held booking must be ticketed or the offer will expire.

If the offer on a held booking is not ticketed by the ExpiryDate and expires, you can renew that booking with a new offer so that traveler and itinerary details do not have to be re-created:

• For GDS, use Add Offer to add an offer to a booking when the current offer has expired. Start with a post-commit workbench create request, add the new offer with either the full payload or reference payload Add Offer request, and commit the workbench.

• For NDC, use Standalone Reprice to reprice the itinerary on a booking either before or after the price guarantee expires. It must be followed by a Modify request to commit the workbench and either ticket or hold the itinerary. If you want to ticket at Modify, and the NDC carrier supports ticketing in the same workbench, send Form of Payment and Payment before Modify.

Book Commit Response Layout Diagram

The following diagram illustrates the general structure of the Book Commit response, including most high-level objects. Objects returned depend on the data added in the booking workflow.

Optional Actions at Commit

Enable Pre-Commit Warnings for Price or Schedule Changes, or Minimum Connect Time (MCT)

At the end of a typical booking workflow, committing the workbench is a single-step process that results in a booking confirmation. However, certain scenarios can product unexpected results if booked immediately, such as if the price or schedule has changed. If you want to receive a warning before the booking is committed, you can enable two-step commit An optional process to return a warning at Workbench Commit in certain scenarios instead of booking. To enable two-step commit, set indicators in the Workbench Commit request to receive a warning before booking in the event of price or schedule changes, or minimum connect time violations..

When enabled, two-step commit keeps the workbench active and returns a warning in the following scenarios:

• if the price or schedule has changed since the offer was added

• if the carrier sends a minimum connect time (MCT) warning

If a two-step commit is triggered, you must send an additional commit request if you want to complete the booking.

Step 1: Enable two-step commit

You must enable two-step commit before the errors occur. To do so, in the initial Commit Workbench request, you must send enableTwoStepCommitInd=true combined with one or more of the following to specify what should trigger the two-step commit:

• Schedule changes: Send errorWhenScheduleChangesInd=true to return a warning if the schedule has changed since the offer was added to the workbench.

• Price changes: Send errorWhenOfferPriceChangesInd=true to return a warning if the price has changed since the offer was added to the workbench.

If price or schedule changes occur and you do not enable two-step commit in the initial commit request, or send the above indicators set to falseor do not send them, AirReservation creates the booking even if the price or schedule has changed. The response returns a warning message about the change as part of the booking confirmation.

• MCT warnings: A carrier may send a Minimum Connect Time (MCT) warning if it deems there is not sufficient time for passengers to reach their connecting flight. Send overrideMCTInd=false at initial commit to trigger a two-step commit if the carrier returns an MCT warning.

Note the Boolean values to trigger two-step commit for MCT are opposite of schedule/price changes. If you do not enable two-step commit, or send overrideMCTInd set to true or do not send it, AirReservation overrides the warning, creates the booking, and returns the carrier MCT warning in the response.

Step 2: Continue with booking, or book with a different offer

If a two-step commit is triggered, for the second step, you can either proceed with the booking, or avoid the error condition by booking a different offer.

To proceed with the booking, send a second Commit Workbench request as follows:

• Accept a price or schedule change: At second commit, send errorWhenOfferPriceChangesInd or errorWhenScheduleChangesInd as false, or send empty or do not send, to accept the price or schedule change and proceed with the booking. The response continues to include a warning that a change occurred. For price changes, Offer returns the updated price. For schedule changes, Product returns the updated flight details. OfferModify is no longer returned.

  Do not send errorWhenOfferPriceChangesInd or errorWhenScheduleChangesInd a second time with a value of true. Doing so discards the workbench and returns an error. Send them in the second commit set to false or do not send.

• Override an MCT warning: At second commit, send overrideMCTInd=true, or send empty or do not send, to override the MCT message from the carrier and create the booking.

If you do not want to proceed with the booking under the warning condition/s, you can take any of the following actions instead:

• Discard the workbench and start the booking over.

• Send Cancel Workbench Items to remove the current offer/s from the workbench and then either:

  • Add a different offer to the workbench with the Add Offer full or reference payload, or

  • Commit the workbench without any offers to create a shell booking and retain traveler details. You can then search for a new offer to add to that shell booking.

Examples

The following example Commit Workbench request payload sends enableTwoStepCommitInd and all optional indicators about error conditions set to true.

Note that for MCT, this payload would create the booking in the event of an MCT warning instead of triggering a two-step commit.

In the example workbench commit response below, a price change has occurred since the offer was added to the workbench. The response includes a warning message and indicator for the price change, and the Offer object returns the new price and breaks down the price change:

• The Offer object is returned with @type OfferModify and priceUpdatedInd=true.

• The updated price is returned in Offer/Price/TotalPrice. The previous price is not returned.

• Offer/ModifyPrice returns a breakdown of the difference between the new price and the previous price. In the Base, TotalTaxes, and/or TotalPrice objects: 

  • Negative amounts indicate the new amount is less than the previous amount .

  • Positive amounts indicate the new amount is more than the previous amount.

  • Zero amounts (0) indicate the new amount is the same as the previous amount.

• Product details are unchanged, as there was no change to the flights or schedule.

• In this example, Result/Warning/Message returns "The Total Price has been increased from 725.0 GBP to 740.0 GBP".

These and other objects identifying the changes are highlighted in yellow in the example. In this case, not only the schedule but also the carrier and flight numbers changed. Note several objects in this example were truncated [...] for brevity.

In the next example, a schedule change has occurred since the offer was added to the workbench. The response includes a warning message and indicator about the schedule change, and returns both original and updated schedule details:

• The Offer object is returned with @type OfferModify and scheduleChangeInd=true.

• The Product object returns previous and updated schedule details in two instances of Product/FlightSegment as follows:

  • The previous flight segment is identified with sequence=1 and Flight/id=flight_1

  • The updated flight segment is identified with sequence=2 and Flight/id=flight_2

• Unless a price change has also occurred, Offer/Price repeats the original price of the offer and Offer/ModifyPrice returns all amounts as zero (0) to indicate there is no price change.

• In this example, Result/Warning/Message returns "EasyJet flight 123 could not be booked. It is not available for the date requested".

These and other objects identifying the changes are highlighted in yellow in the example. In this case, not only the schedule but also the carrier and flight numbers changed. Note several objects in this example were truncated [...] for brevity.

Create Retention Segments

By default, reservation details are stored for one month after all travel on the itinerary is completed. This means you can continue to retrieve the reservation for one month after travel, at which time the reservation is purged and no longer available. You can extend this time by sending an optional workbench commit request payload with the autoDeleteDate query parameter at the end of the initial booking workflow. You can set a purge date that is up to 331 days from the date the reservation was created. Adding a purge date creates a retention segment on the reservation.

The autoDeleteDate value is returned in the Reservation Retrieve, Workbench Commit, and Post-Commit Workbench responses, as shown in the example excerpt below. To update or delete the autoDeleteDate on an existing booking, send the autoDeleteDate query parameter at the end of a post-commit workbench session.

Confirm Involuntary Schedule Change

When the flight schedule on an existing reservation has changed, the Reservation Retrieve response indicates the change by returning a value of either TK or UN in OfferStatus/StatusAir/code. You can send the optional workbench commit request payload with scheduleChangeAcceptedInd set to true to confirm a carrier-initiated schedule change. In this case, you do not need to first create a workbench session.

For NDC, also see NDC Flight Disruption Handling below.

Update or Delete Ticketing Time Limit Date

AirReservation supports an optional workbench commit request payload that adds or deletes the ticketing time limit for a booking. The ticket time limit is the last day to ticket the booking before the offer expires.

Add ReceivedFrom for Deem

AirReservation supports an optional workbench commit request payload that sends a ReceivedFrom object. This allows online travel agencies (OTAs) and agents using the Deem platform to include an optional receive field at reservation creation or update.

Create Shell Booking in Case of Booking Failure

You can choose to create a shell booking in the case of bookings that fail due to inability to either add the offer or quote a fare. To do so, send the autoDeleteDate query parameter at Workbench Commit at the end of the initial booking workflow. A shell booking retains traveler details and allows an agency to contact the customer offline through their call center and complete the booking as necessary, or to complete with the JSON API booking workflow.

To ticket a failed booking with a reservation shell, use the following workflow:

1. Create a post-commit workbench request, sending the locator code for the failed booking.

2. Send an Add Offer request.

3. If necessary, send an Add Traveler request to complete traveler details.

4. Send an Add Form of Payment request.

5. Send an Add Payment request.

6. Send a Commit Workbench request with the autoDeleteDate query parameter.

Optional steps such as seats, ancillaries, or remarks are also supported in the workflow above after adding the offer and traveler/s.

Shell bookings support the following remarks for add and delete; use the applicable workflow in the Remarks and Service Requests Guide:

• Vendor remarks

• DOCI remarks

• Itinerary (associated and unassociated) remarks

• Notepad remarks

• Historical Notepad remarks

• Accounting remarks

• OSI remarks

Shell bookings support add, update, and delete for any traveler details supported in the TravelerUpdateableItems request. See the Traveler Modify Guide.

The following example reservation retrieve response is for a shell reservation for a failed booking. The response does not return offer details, and the Result object returns the warning NO FARES FOUND.

NDC Flight Disruption Handling

Travelport has implemented a structured approach to managing a variety of flight disruptions for NDC carriers. To summarize, when an airline-initiated flight change occurs, Travelport updates the booking and routes it for processing onto agency back-end queues. The Reservation Retrieve response returns the booking with scheduleChangeInd=true to indicate the change and details of the update. You can then choose to either accept the change, rebook the itinerary, or cancel for a refund per the carrier rules for the type of disruption.

Processing of OCN from NDC Carrier

Behind the scenes, when an NDC airline sends an order change notification OCN, an update sent from an airline to notify Travelport of an airline-initiated change such as a schedule change, flight number change, or flight cancellation. (OCN) for a Travelport booking, Travelport updates the affected segments on the booking and routes the booking to a specific back-end queue Each Travelport PCC has a set of numbered queues. Queues provide the ability to place a booking into an area that allows you to manage, sort, and store booking files, messages from vendors, and manage workflow. Queue management distributes messages from vendors and customers to the specified queues for action. based on the type of OCN received:

• Q11: schedule change such as flight number change, route change, retimed, partial involuntary cancellation

• Q23: full involuntary cancellations, TTL (time to ticket limit) expiry, no show, voluntary cancellation, or change outside NDC channel

Reservation Retrieve Response for Disrupted Booking

In the JSON APIs, the Reservation Retrieve response returns an Offer object with @type OfferModify and scheduleChangeInd=true to indicate a change has occurred. The disrupted and new flight segment details are returned as follows depending on the type of disruption:

When the carrier cancels and rebooks flight/s:

• Offer @typeOfferModify/Product/FlightSegment/Flight/id increments the new flight id by 1 from the impacted segment; e.g., Flight_01 for the impacted segment and Flight_02 for the new segment.

• Confirmation/OfferStatus/Status Air returns the new flight with status code TK and status value Confirmed.The impacted flight is returned with status code UN and status value Pending.

The following example is for a round-trip booking that has been canceled and rebooked on different dates. The previous and rebooked flights for the first leg are returned in the first instance of Product @type ProductAir, followed by an instance with the previous and rebooked flights for the return leg. The impacted segments are Flight/id Flight_01 and Flight_03; the new segments are Flight_02 and Flight_04. Note this example excerpts only the Offer object and has truncated several objects with ... for brevity.

Show Example Reservation Retrieve response - Offer object for canceled and rebooked itinerary

            "Offer": [
                {
                    "@type": "OfferModify",
                    "scheduleChangeInd": true,
                    "id": "offer_1",
                    "Identifier": {
                        "authority": "QF",
                        "value": "UUYwODFISjM1OVdBNHxQMjg3NkVDQjctNEFFNi00MEY0LUFCQ2Z6amhhcjJnMHp4d3UtMS0xfFAyODc2RUNCNy00QUU2LTQwRjQtQUJDZnpqaGFyMmcwenh3dS0xLTJ8U3RhdHVzOlVTRUQgTlRBQw=="
                    },
                    "Product": [
                        {
                            "@type": "ProductAir",
                            "id": "product_1",
                            "Identifier": {
                                "authority": "QF",
                                "value": "f91dd03d-f2b4-4af3-9de7-60055200fe1b"
                            },
                            "FlightSegment": [
                                {
                                    "@type": "FlightSegment",
                                    "id": "FlightSegment_01",
                                    "sequence": 1,
                                    "Flight": {
                                        "@type": "Flight",
                                        "duration": "PT1H35M",
                                        "carrier": "QF",
                                        "number": "403",
                                        "id": "Flight_01",
                                        "Identifier": {
                                            "authority": "QF",
                                            "value": "7f083ca6-9af0-4003-90e9-e4493d8a2e1e"
                                        },
                                        "Departure": {
                                            "@type": "Departure",
                                            "location": "SYD",
                                            "date": "2025-10-01",
                                            "time": "06:15:00"
                                        },
                                        "Arrival": {
                                            "@type": "Arrival",
                                            "location": "MEL",
                                            "date": "2025-10-01",
                                            "time": "07:50:00"
                                        }
                                    }
                                },
                                {
                                    "@type": "FlightSegment",
                                    "id": "FlightSegment_02",
                                    "sequence": 2,
                                    "connectionDuration": "PT49H35M",
                                    "Flight": {
                                        "@type": "Flight",
                                        "duration": "PT1H35M",
                                        "carrier": "QF",
                                        "number": "403",
                                        "id": "Flight_02",
                                        "Identifier": {
                                            "authority": "QF",
                                            "value": "80cd437b-ac37-408a-8084-ae2f1b264082"
                                        },
                                        "Departure": {
                                            "@type": "Departure",
                                            "location": "SYD",
                                            "date": "2025-09-29",
                                            "time": "06:15:00"
                                        },
                                        "Arrival": {
                                            "@type": "Arrival",
                                            "location": "MEL",
                                            "date": "2025-09-29",
                                            "time": "07:50:00"
                                        }
                                    }
                                }
                            ],
                            "PassengerFlight": [
                                {...},
                                {...}
                            ]
                        },
                        {
                            "@type": "ProductAir",
                            "id": "product_2",
                            "Identifier": {
                                "authority": "QF",
                                "value": "46b4cdbc-dae6-4a1c-9e26-4bc08ad1294d"
                            },
                            "FlightSegment": [
                                {
                                    "@type": "FlightSegment",
                                    "id": "FlightSegment_03",
                                    "sequence": 3,
                                    "connectionDuration": "PT212H55M",
                                    "Flight": {
                                        "@type": "Flight",
                                        "duration": "PT1H25M",
                                        "carrier": "QF",
                                        "number": "400",
                                        "id": "Flight_03",
                                        "Identifier": {
                                            "authority": "QF",
                                            "value": "3a258976-3554-4f08-be41-0eb8c70a0675"
                                        },
                                        "Departure": {
                                            "@type": "Departure",
                                            "location": "MEL",
                                            "date": "2025-10-08",
                                            "time": "05:45:00"
                                        },
                                        "Arrival": {
                                            "@type": "Arrival",
                                            "location": "SYD",
                                            "date": "2025-10-08",
                                            "time": "07:10:00"
                                        }
                                    }
                                },
                                {
                                    "@type": "FlightSegment",
                                    "id": "FlightSegment_04",
                                    "sequence": 4,
                                    "connectionDuration": "PT46H35M",
                                    "Flight": {
                                        "@type": "Flight",
                                        "duration": "PT1H25M",
                                        "carrier": "QF",
                                        "number": "400",
                                        "id": "Flight_04",
                                        "Identifier": {
                                            "authority": "QF",
                                            "value": "0b679307-a27b-4dde-88fd-01a806eee5ec"
                                        },
                                        "Departure": {
                                            "@type": "Departure",
                                            "location": "MEL",
                                            "date": "2025-10-10",
                                            "time": "05:45:00"
                                        },
                                        "Arrival": {
                                            "@type": "Arrival",
                                            "location": "SYD",
                                            "date": "2025-10-10",
                                            "time": "07:10:00"
                                        }
                                    }
                                }
                            ],
                            "PassengerFlight": [...]
                        }
                    ],
                    "Price": {...},
                    "TermsAndConditionsFull": [
                        {
                            "@type": "TermsAndConditionsFullScheduleChange",
                            "id": "termsAndConditions_1",
                            "Identifier": {
                                "authority": "Travelport",
                                "value": "b1995cc5-be45-4c5f-9c39-4b75369bb29b"
                            },
                            "ScheduleChangeOptions": [
                                {
                                    "@type": "ScheduleChangeOptions",
                                    "options": [
                                        "Accept"
                                    ]
                                },
                                {
                                    "@type": "ScheduleChangeOptions",
                                    "options": [
                                        "Reshop"
                                    ],
                                    "waiverCodeRequiredInd": true
                                },
                                {
                                    "@type": "ScheduleChangeOptions",
                                    "options": [
                                        "Refund"
                                    ]
                                }
                            ]
                        },
                        {
                            "@type": "TermsAndConditionsFullAir",
                            "ExpiryDate": "2025-06-03T23:59:00Z",
                            "TextBlock": [...],
                            "BaggageAllowance": [...],
                            "FareRuleInfo": [...],
                            "Penalties": [...]
                        }
                    ]
                }
            ],

The following example is an excerpt of the receipt confirmation in the same response, returning the status codes for all four flight segments.

Show Example Reservation Retrieve response - Receipt object

                {
                    "@type": "ReceiptConfirmation",
                    "Identifier": {
                        "authority": "Travelport",
                        "value": "383a3c09-7205-4dd9-8e20-c97be37ba09c"
                    },
                    "Confirmation": {
                        "@type": "ConfirmationHold",
                        "Locator": {
                            "source": "1G",
                            "creationDate": "2025-06-03",
                            "value": "BXQLQC"
                        },
                        "OfferStatus": {
                            "@type": "OfferStatusAir",
                            "StatusAir": [
                                {
                                    "flightRefs": [
                                        "Flight_02",
                                        "Flight_04"
                                    ],
                                    "code": "TK",
                                    "value": "Confirmed"
                                },
                                {
                                    "flightRefs": [
                                        "Flight_01",
                                        "Flight_03"
                                    ],
                                    "code": "UN",
                                    "value": "Pending"
                                }
                            ]
                        }
                    }
                }

When the carrier changes the time of flight/s:

• Offer @typeOfferModify/Product/FlightSegment/Flight returns only the updated segment/s.

• Confirmation/OfferStatus/Status Air returns the updated flight/s with status code TK and status value Confirmed.

When the carrier fully cancels flight/s:

• Offer @typeOfferModify/Product/FlightSegment/Flight/id returns the impacted segment/s. There are no new segments to return.

• Confirmation/OfferStatus/Status Air returns the impacted segment/s with status code HX and status value Cancelled.

In addition, the Result/Warning object returns details or a description of the change in each scenario.

The available follow-up actions are returned in the same instance of Offer @typeOfferModify in TermsAndConditionsFull with @type TermsAndConditionsFullStatusChange. One or more instances of ScheduleChangeOptions is returned with one of the following values in the options object:

• Accept

• Reshop (also returns waiverCodeRequiredInd=true if a waiver code is required to rebook)

• Refund

For involuntary full cancellation, accept and refund are typically returned. For either a flight time change or cancel and rebook, all three options are typically returned.

Follow-up Action Workflows

You can choose to either accept the change, rebook the itinerary, or cancel for a refund per the carrier rules for the type of disruption.

Accept Changes

To accept the changes shown in the Reservation Retrieve response, send the workbench commit request payload with the scheduleChangeAcceptedInd indicator set to true. In this case, you do not need to first create a workbench session.

Rebook

To rebook the itinerary, follow the standard NDC exchange workflow. The following links go to the API Reference for each step. See NDC Workflow to Exchange Tickets in the Exchange, Refund, and Void Guide if you need details:

1. Post-Commit Workbench

2. Reshop

3. Reprice

4. Form of Payment (may be optional or required depending on carrier rules)

5. Form of Payment (may be optional or required depending on carrier rules)

6. Modify

Refund

To cancel the itinerary and receive a refund, follow the standard NDC refund workflow. The following links go to the API Reference for each step. See Workflow to Refund Ticket in the Exchange, Refund, and Void Guide if you need details:

1. Post-Commit Workbench

2. Refund Quote

3. Cancel

Passive Segments

The JSON APIs support using the booking process to add an air segment booked outside the Travelport GDS, called a passive segment, to a booking. This allows that booking to include complete travel details. That segment can also then be ticketed with the JSON APIs. To book a passive segment, follow the standard booking workflow and send the Add Offer full payload request with the following two objects in ProductCriteriaAir:

• SpecificFlightCriteria/passiveSegmentStatus

• SupplierLocator

The following examples are for a booking consisting solely of a passive segment. The first example shows the Add Offer full payload request. It sends passiveSegmentStatus set to AK, and the carrier's code and locator in the SupplierLocator object. The next example shows the workbench commit response returning full reservation details. Note the response returns two instances of Receipt @typeReceiptConfirmation; each instance returns a locator code, one for the Travelport locator code (B7RVBF) and another for the passive locator code sent in Add Offer (WTR84G).

Unpriced Segments and AutoPrice/Manual Fares

An unpriced segment is an air segment without any associated fare or pricing, It is generally booked for availability versus cost. Across the JSON APIs unpriced content is sent and returned in UnpricedSegments object instead of the Offer object, which by definition includes fare and pricing details.

An unpriced segment can be added to a workbench and booked, or added to an existing reservation, using the Unpriced Segment API. Segment statuses NN, BK, AK, and YK are supported for booking. You can use the Unpriced Segment API instead of the Add Offer request in either the booking or post-booking workflow. Or, to add both an unpriced segment and an offer, you can send both Unpriced Segment and Add Offer.

In addition, an unpriced segment can also be created by removing the filed fare The specific price and all associated rules for a ticket, published by the airline to the ATPCO centralized system and then distributed to GDSs. Once an airline prices a flight and a passenger books it, that specific fare and its rules are stored as a filed fare in the booking system and becomes the contractual basis for the ticket. from an offer using the Cancel Workbench Items API. This removes the pricing details from the offer but leaves the segment details in the booking intact, creating an unpriced segment.

Unpriced content can include GDS air segments. In addition, any Arrival Unknown (ARNK) segment is returned as an unpriced segment.

The JSON APIs support two options for pricing unpriced segments. Both use the AutoPrice/Manual Fare API , which provides separate payloads to price in either of the following ways: 

• auto-price one or more unpriced segments

• build a manual fare A custom or specially negotiated price that isn’t a standard system-generated fare. Travel agents or consolidators use manual fares for unique itineraries such as complex international tickets, group travel, re-routing after disruptions, or when a standard fare isn't found. Agents must manually combine segments and ensure that all rules and conditions are met. for one or more unpriced segments using fare and pricing details from the airline or another source

Each scenario uses its own request payload. Both payloads support pricing one or multiple segments for one or multiple passengers on a booking and are supported in the booking workflows as follows:

• Auto pricing an unpriced segment is supported in either the booking or post-booking workflow; i.e., both when creating a booking and for an existing booking.

• Manual fare build for an unpriced segment is supported only in the post-booking workflow. If you add an unpriced segment to the workbench, you must commit that workbench and create a new post-commit workbench before using the Manual Fare request.

The following objects are returned for unpriced segment/s in the Reservation Retrieve, Commit Workbench, and Workbench Retrieve responses:

• Reservation returns UnpricedSegments with details of the unpriced segment.

• TravelerProduct returns UnpricedFlightSegmentRefs to list unpriced segment/s for that traveler.

• Receipt/Confirmation returns UnpricedSegmentsStatus with the status of the air segment.

• ReservationDisplaySequence returns UnpricedSegmentDisplaySequence to indicate the sequence of the unpriced segment.

The following functionality is supported for unpriced segments; see the linked JSON APIs for each item:

• Cancel unpriced segments (Cancel Workbench Items API)

• Cancel a price from an offer (aka, cancel a filed fare), creating an unpriced segment (Cancel Workbench Items API)

• Book one or more unpriced segments or add unpriced segments to an existing reservation (Unpriced Segments API)

• Auto-price multiple or all air segments per passenger (AutoPrice/Manual Fare API)

• Build a manual fare for an unpriced segment (AutoPrice/Manual Fare API)

Exchanges with unpriced segments are not supported.

Remove Offers, Products, Segments, or Filed Fares from a Booking

The Cancel Workbench Items API supports several options for canceling GDS and NDC air offers, hotel segments, and car content during either the initial booking workflow or from a held booking. Supported options vary for the initial booking workbench from those supported for a held booking. Cancel Workbench Items cannot be used after a booking is ticketed.

In the initial booking workbench (i.e., when creating a booking), Cancel Workbench Items supports canceling the following:

• Cancel entire reservation, including all GDS and NDC air, hotel, and car offers

• Cancel all offers In the JSON Search APIs, an offer is a product available at a specific price under a set of terms and conditions. An offer includes the flight or connecting flights for one leg of the itinerary, plus a service level that includes the cabin class and any fare codes that may apply. At booking, the selected offer from the Search response - including the flight/s, service level, price, terms and conditions, and brand if applicable - is converted into a single Offer object that is subsequently returned for that booking. in the workbench from all sources

• Cancel a specific offer in the workbench (NDC only)

In the post-commit workbench (i.e., for a held booking), Cancel Workbench Items does not support changes for NDC bookings. Instead, modify an NDC held booking with the NDC Modify API.

Cancel Workbench Items is supported for the following in the post-commit workbench:

• Cancel entire booking, including hotel, car, and GDS air content and any unpriced segments, and discard traveler data.

• Cancel all offers on the booking, including hotel, car, and GDS air offers and any unpriced segments; retains all other information in the booking including passenger details.

• Cancel one or multiple hotel, car, or GDS air offers or unpriced segments on the booking

• Cancel one or multiple products In the JSON APIs, a product is the term used in the model for one leg of the itinerary. It includes the flight or connecting flights between one origin and destination pair; e.g., LON > EWR. Product information also includes a service level of the cabin class and any applicable fare codes. within a GDS air offer (hotel and car do not have products)

• Cancel one or multiple segments A flight or flights under one flight number. One flight equals one segment. A segment could have multiple flights if the flight number remains the same, which happens if a flight makes a stop without changing planes. within a product in a GDS air offer (hotel and car do not have products or segments)

• Cancel all or only specific unpriced segments An air segment without any associated fare or pricing, generally booked for availability versus cost. Shown in the UnpricedSegments object instead of the Offer object. GDS only; NDC does not use unpriced segments.

• Cancel any combination of offers and unpriced segments

• Cancel the filed fare on an offer, which removes the price from the offer and converts it to an unpriced segment. After commit, you can add a fare with either Standalone Reprice or Manual Fare Build (release pending).

Multi-offer Bookings

AirReservation supports multiple offers on the same booking. This allows you to, for example, book two one-way offers together instead of a single round-trip offer. To combine multiple offers into one reservation, repeat the Add Offer request in the initial booking workbench as needed (see the Booking Workflow Summary). You can use either the full or reference payload. While there is no specific limit on the number of offers that can be combined, a reservation cannot have more than 16 flight segments.

Multi-offer bookings support seats and ancillaries, and can be exchanged.

Multi-content Bookings

Reservation Retrieve and Post-Commit Workbench return air, hotel, and/or car segments for any reservation that includes that content, called a multi-content booking. All segments must have been booked with the JSON Air APIs, JSON Hotel APIs, JSON Car APIs (release pending), or a Travelport+ terminal program. You can add either GDS or NDC air offers to a hotel and/or car booking, but not both. See the Multi-content Booking Guide (Air, Hotel, Car) for workflows and examples.

Travel Agency Details

The JSON Travel Agency APIs allow you to add, modify, and delete the travel agency corporate ID and/or address of a travel agency for the booking in the current workbench, either in the initial booking workbench or for an existing reservation in a post-commit workbench. Use any of the following APIs as needed:

• Travel Agency Details: Add an agency corporate ID, email address, email, or telephone for the booking in the current workbench.

• Travel Agency Corporate ID: Add, update, or delete the agency corporate code for the booking.

• Travel Agency Address: Add, update, or delete the agency address for the booking.

• Travel Agency Email: Add, update, or delete the agency email address for the booking.

• Travel Agency Telephone: Add, update, or delete the agency telephone number for the booking.

Custom Booking Rules

The JSON Custom Rules APIs allow you to manage and use the custom rules set up for your PCC (pseudo city code, a travel provider's identification code provisioned from Travelport).

Custom rules are created in a booking file management tool to validate bookings against specific criteria. They could be organization rules, corporate rules, business rules, personal rules, and so on. For example, a custom rule could provide a check for certain non-mandatory data, such as that every booking must contain a delivery address, or that an after hours contact number must be sent to the airline as an OSI remark. Or, a rule could check for items needed for back office systems such as a name remark.

Custom rules are not created in the JSON APIs but can be applied to bookings in the JSON APIs. You can add up to three custom rules to a booking.

If custom rules are configured for your PCC at Travelport, when the workbench is committed at the end of the booking workflow, the booking is compared to the conditions in any custom rules added to that booking. If any conditions are not met, an error message is returned and the changes in the workbench are not committed. The workbench session is maintained so that the conditions required by the attached rule can be corrected in the booking.

Note the following:

• When adding a rule to a booking, that rule must already have been created and associated with your PCC. Otherwise, the error message INVALID - RULE {NAME} DOES NOT EXIST - CustomRule is returned.
• The exception is that you can send a rule name created for a PCC with which your PCC has an agreement. If your PCC does not have an agreement with that PCC, the error message NO AGREEMENT EXISTS FOR PSEUDO CITY - {PCC} - CustomRule is returned.
• You must send a separate request for each rule to add.
• You can add up to three custom rules to a booking. If additional rules are sent, the error message INVALID - THREE RULES ALREADY ATTACHED - CustomRule is returned.
• If you send a rule name that has already been attached to the booking, the error message RULE {NAME} ALREADY ATTACHED - CustomRule is returned.

The following APIs allow you to use custom rules with bookings made in the JSON APIs. See the linked API references for details:

• Custom Rule: Add or delete a custom rule on a booking. Sent in a workbench session.
• Custom Rule List: Return a list of all custom rules associated with a PCC. Standalone request that can be sent as part of a workbench or without a workbench.
• Custom Rule Details: Return details of a specific custom rule associated with a PCC. Standalone request that can be sent as part of a workbench or without a workbench.

To return the rules associated with a specific booking, send a reservation retrieve with detail view requested.