Commit Workbench API Reference

POST

book/reservation/reservations/{workbenchID}

For {workbenchID} send the workbench identifier returned in ReservationResponse/Identifer/value in the workbench create response.

Base path:

Pre-production https://api.pp.travelport.com/11/air/

Production https://api.travelport.com/11/air/

Related Content: Booking Guide, Ticketing Guide

The Commit Workbench request ends a workbench session and commits all changes and requests in that session. Depending on the requests sent in the workbench session, the workbench commitClosed API call that ends a workbench session, finalizing all changes and requests in that session. Depending on the workbench transactions, the commit workbench request may create a reservation, issue a ticket or EMD, exchange tickets, or modify a reservation. might create a reservation, issue a ticket or EMDClosed Electronic miscellaneous document (EMD); issued for a paid seat, ancillary, or any other paid service after successful payment. See the Ancillary and EMD Guide., modify reservation data, or exchangeClosed Cancel or modify a ticketed itinerary and issue a new ticket. See the Cancel, Exchange, and Refund Options Guide. a ticket. Note that some workbench commit options are supported only in specific flows, such as the initial bookingClosed A confirmed reservation with the carrier. A held booking is a reservation that has not yet been ticketed. The terms booking and reservation are interchangeable. flow, a ticketing commit, or an exchange commit, as specified below for that option.

In the initial booking workflow, if any pricing modifierClosed A modifier that refines the API request based on fare and ticketing options and not the travel itself; sent in the PricingModifiersAir object. See the Air Shopping Guide for a list. sent in the Add Offer full payload or reference payload request does not have any fares associated with it, the commit will fail and return the error message No Fare Found. Pricing happens at the commit, not the Add Offer step.

NDCClosed New Distribution Capability, an XML standard for exchanging data that supports airlines in distributing their content directly to online travel agencies. See the NDC Guide. carrierClosed An airline. British Airways (BA) does not guarantee the price of a held booking. When ticketing a held booking, if the price has changed, the JSON APIs return the error message "ERROR AT ISSUANCE TIME: TST EXPIRED - OVERRIDE OR DELETE AND REPRICE Code = \"376\". In this case, you must use the Reprice and Resell APIs (see the Exchange, Refund, and Void Guide) and send payment to complete ticketing.

Carrier 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 ancillaryClosed Any paid optional service filed for a flight. Industry examples include paid seats, paid baggage, carbon offsets, pet transport fees, and unaccompanied minor charges. See the Ancillary and EMD Guide for supported ancillaries. such as a wheelchair.

Request

Query Parameters

Parameter Description Required/Optional

autoDeleteDate

Optional. Use to create, update, or delete retention segments, and to create a shell booking in certain cases of booking failures.

Retention Segments

By default, reservation details are stored for one month after all travel on the itineraryClosed The entire trip on a booking, including all flights on all legs. Also called a journey. 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 setting a purge date that is up to 331 days from the date the reservation was created: In the commit of the initial booking workbench session, send autoDeleteDate with a date in YYYY-MM-DD format, as in ?autoDeleteDate=2024-08-12. Adding a purge date creates a retention segmentClosed 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. on the host reservation.

The autoDeleteDate value is returned in the Reservation Retrieve, Workbench Commit, and Post-Commit Workbench responses. To update or delete the autoDeleteDate, at the end of a post-commitClosed Refers to the state of a booking after the booking is created, which happens after the initial booking workbench is commited and the reservation locator code issued. workbench session, send autoDeleteDate with one of the following:

  1. To update the purge date for an existing retention segment, send the new date; e.g., ?autoDeleteDate=2023-08-12

  2. To delete the existing retention segment, send with the value 1000-01-01

Create Reservation Shell (Shell Booking)

Sending autoDeleteDate with any date value in the commit of the initial booking workbench session creates a reservation shellClosed Created for bookings that fail due to inability to either add the offer or quote a fare. Includes traveler details to allow agency to complete the booking as necessary. For a reservation shell to be created, the autoDeleteDate query parameter must be sent at the workbench commit. if the booking fails either because the offerClosed 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. cannot be added or the fare cannot be quoted. This reservation shell contains traveler details and allows the booking to be completed later. See Create Shell Booking in Case of Booking Failure.

Optional

Issuance

Optional. Send with a value of BACKOFFICE to update any back office accounting systems. You can send Issuance in the workbench commit at the end of a booking session, or at ticketing.

The response includes an interface control number.

Optional

payLaterInd

For use only in Exchange Ticketing. Sets whether to issue the new ticket/s now, or create a held booking for later fulfillment. Supported values:

true: Holds changes for later fulfillment and ticketing.

false: Issues ticket and any other documents such as EMDs on commit.

Required for a ticket exchange only

DocumentValue

For use only in Exchange Ticketing. If sent, send with a value of REFUND, which refunds an EMD that has a refundable balance to the original FOP and is the only supported value.

Refunds are indicated in the Exchange Search response by a negative amount in ModifyPrice/TotalPrice, and a value of either EMD or MCOClosed Miscellaneous change order; generally issued during the exchange process by either the airline or agency to process a residual balance for future travel, paper ticket fees, tour payments, etc. in TermsAndConditions/FulfillmentMethod/RefundMethod.

Alternately, you can refund or forfeit any EMD value using the EMD Void request.
If the new itinerary is ticketed at the time of reservation (pay now flow), and there is a residual balance to an MCO (miscellaneous change order), the MCO is issued along with the ticket at workbench commit. If the new itinerary is booked but not ticketed (pay later flow), any MCO is created but not issued yet. This allows customers to display, modify, and issue their own MCO outside of the JSON APIs if desired. If the reservation is subsequently ticketed using Exchange Ticketing, the MCO is issued as usual at commit.

Optional for a ticket exchange

If not sent any value remains on the EMD.

Request Body

No message payload is required for a workbench commit.

The following optional payloads below are supported for optional actions at commit:

Accept Involuntary Schedule Change

The indicator scheduleChangeAcceptedInd allows you to update the reservation with schedule changes when an airline has modified a flight schedule (called an involuntary schedule change). To check whether a flight schedule has been modified, send a standard Reservation Retrieve request:

To accept the schedule change, send the workbench commit request payload per below, with scheduleChangeAcceptedInd set to true. You do not need to create a workbench session first.

Currently there are defects associated with accepting involuntary schedule changes for NDC; these will be resolved in upcoming releases; until then you may receive error messages.
Specify a Queue

Optionally, you can send a message payload to specify a queue for this reservation: Each Travelport PCCClosed Pseudo city code. A travel provider's identification code for the JSON APIs, provisioned from Travelport. Used to determine access and other settings in the JSON APIs for your company. has a set of numbered queues. Some of these queues have predetermined functions and others can be customized for internal use. The queue system allows you to sign into and out of queues, place booking files on a queue, and perform various maintenance functions on the booking files currently on queue.

This is one of two ways to specify a queue. Alternately, you can send the standalone Queue Placement request anytime after booking and before ticketing.

Update or Delete Ticketing Time Limit Date
GDS only; not supported for NDC.

Send the following payload to add or delete the ticketing time limit for a booking. This is the last day to ticket the booking before the offer expires.

Add ReceivedFrom

GDS only; not supported for NDC. Supported for ticketing and exchanges.

Send the following payload to send a ReceivedFrom object to add name details for the person a backoffice comment was received from. This allows online travel agencies (OTAs) and agents using the Deem platform to send a receive field at reservation create or update, or during exchanges. After sending, receivedFrom details are viewable only in a terminal program, not in the JSON Reservation Retrieve.

Response

The booking workbench commit response is similar but not identical to the Reservation Retrieve response, returning data added during the booking workflow. See the Reservation Retrieve API Reference for full details.

After the workbench commit, if the flight time or fare has changed since the offer was added, a notification message per the examples below is returned:

  • Price increase example: "The Total Price has been increased from 17272.68 USD to 18272.0 USD"
  • Price decrease example: "The Total Price has been decreased from 665.7 USD to 620.8 USD"
  • Flight time change example: "The Departure Date and/or Time has changed from 2023-01-19/16:35:00 to 2023-01-23/18:35:00 for KL 1243 from AMS to CDG"

Example Request

For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.

No message payload required for workbench commit. The following optional payloads are supported.

To accept a schedule change on a reservation, send the workbench commit request payload per below, with scheduleChangeAcceptedInd set to true. You do not need to create a workbench session first. (To check whether a flight schedule has been modified, send a standard Reservation Retrieve request: In the response, a value in OfferStatus/StatusAir/code of either TK or UN indicates the flight has schedule change information. )

Send the following optional payload to add the reservation to an agency queue.

Send the following optional payload to send a ReceivedFrom object. This allows online travel agencies (OTAs) and agents using the Deem platform to send a receive field at reservation creation or update. This object is not returned in the reservation retrieve.

Example Response

The following examples show workbench commit responses for both GDS and NDC at the end of the initial booking workflows.

Because a workbench commit can be used to conclude multiple scenarios - including but not limited to creating a reservation, updating an existing reservation, adding seats or ancillaries, exchanging a ticket - any workbench commit response may vary from the examples shown here.
For additional examples and scenarios, download the developer toolkits and see Using Postman and Developer Toolkits.