Workbench Commit 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.net/11/air/

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

Related Content: Booking Guide, Ticketing Guide

The Workbench Commit request ends a workbench session and commits all requests made in that session. Depending on the requests sent in the workbench session, the workbench commit could result in any of the following:

  • Create a booking at the end of the initial booking workflow

  • Issue a ticket or EMD, after sending payment for that ticket or EMD in the workbench with the Payment request

  • Modify or cancel a booking (you can cancel a booking or add or remove offers, products, or segments with Cancel Workbench Items)

  • Modify traveler data, after sending the Traveler Updatable Items and Traveler Update requests in the workbench

  • Exchange a ticket using the GDS Exchange APIs (note that NDC exchanges use Modify to end the exchange instead of Workbench Commit)

The workbench commit supports several optional query parameters and payloads to carry out certain actions at commit. Some are supported only in specific flows, such as the initial booking flow, a ticketing commit, or an exchange commit, as specified.

In 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 will fail and return the error message No Fare Found. Pricing happens at the commit, not the Add Offer step.

NDC carrier British Airways (BA) does not guarantee the price of a held booking. When ticketing a held booking, the workbench commit returns an error message if the price has changed. In this case, you must use the Reprice and Modify 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. Because this can be an issue for agencies that require this code at the time of booking, AirReservation makes one additional attempt to retrieve the reservation from the carrier. If the carrier locator code cannot be retrieved, 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.

Request

As part of the request requirements, also see Authentication and Common Air Headers.

Query Parameters

Parameter Description Required/Optional

autoDeleteDate

Optional. Use to create, update, or delete retention segments, and to create a shell booking for booking failures caused by specific scenarios.

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 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 segment 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-commit 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 shell if the booking fails either because the offer 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 when exchanging GDS tickets; see the Exchanges, Refunds, and Void Guide for details. 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 when exchanging GDS tickets; see the Exchanges, Refunds, and Void Guide for details. 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 MCO 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 at commit as usual.

Optional for a ticket exchange

If not sent any value remains on the EMD.

Request Body

Although a workbench commit does not require any message payload, it supports several optional actions that can be specified in an optional payload. The following table includes all objects that are supported for the optional workbench commit payload. See the following links in the Air Booking Guide for a full description of these optional actions supported at commit:

Response

The Workbench Commit response uses the same structure as the Reservation Retrieve response; see Reservation Retrieve response for full documentation. However, the Workbench Commit request does not support the query parameters available in Reservation Retrieve and so information such as fare rules and certain remarks are not returned. See the intro to the Reservation Retrieve response for a full list.

Response for first workbench commit at two-step commit

See Enable Two-Step Commit and Warnings in the Booking Guide for usage details and examples for two-step commit.

In the initial booking workflow, or when adding an offer to an existing reservation, you can send enableTwoStepCommitInd=true to enable a two-step commit process that returns a warning if specific error scenarios occur. If a two-step commit is triggered, the booking is not created and this first commit response differs from the typical commit response.

The following table lists the top-level objects returned in the first commit of the two-step commit response and details all objects that are returned only in that response. For objects that are the same as in the typical Workbench Commit response, see full descriptions in the Reservation Retrieve API Reference.

The response to a second commit that creates a booking uses the same structure as a Reservation Retrieve response, as outlined above.

Example Request

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

No message payload is required for a workbench commit. The following examples show some of the optional payloads supported.

The following optional payload triggers a two-step commit in the case of warnings about a schedule change, price change, and/or MCT warning.

The following optional payload accepts an involuntary schedule change from the carrier. This is not related to schedule changes at initial commit in the preceding example.

The following optional payload adds the booking to an agency queue (QueueNumber) and updates the ticketing time limit (Date object).

The following optional payload sends a ReceivedFrom object that 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 content.

Because a workbench commit is 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, download the developer toolkits and see Using Postman and Developer Toolkits.
See the Air Booking Guide for a full description and examples of the two-step commit process, including examples of the responses returned for the price and schedule change warning scenarios.

GDS booking and ticketing examples

The first example below is the response to a workbench commit at the end of the initial booking workflow. It creates a GDS booking with record locator BXPJVM. This is a one-way itinerary with one traveler.

For comparison purposes, this same example booking (locator code BXPJVM) is also shown in the following example response for the ticketing commit, in the Post-Commit Workbench Create API Reference example response, and in the Reservation Retrieve API Reference example for the ticketed one-way GDS Itinerary.

The example below is the response to a workbench commit at the end of the ticketing workflow. It tickets the same booking in the previous example, with record locator BXPJVM. The FormOfPayment and Payment objects here were not returned in the first commit. In addition, Receipt includes an instance with @type ReceiptPayment that includes the Document object, which returns the ticket number in Number.

The next example shows the commit when exchanging a GDS ticket with the GDS Exchange APIs. While the commit response returns both the previous offer and the newly issued offer, subsequent Reservation Retrieve responses return only the new offer, which has several indicators that the offer has been exchanged. See the Exchange, Refund, and Void Guide for details on exchanges.

NDC booking and ticketing examples

The next three commit response examples are for NDC bookings. The first example is the commit response to hold an NDC booking, one-way with one traveler. This commit response shows the Travelport locator code B7KT1S.

The example below shows the commit response when ticketing the same NDC booking in the preceding example, with the Travelport locator code B7KT1S.

The next example shows the response for the NDC Instant Pay flow, which books and issues the ticket in the same, initial booking workbench (NDC only; carrier support varies). Receipt/Document/Number returns the ticket number while Receipt/Document/contentSource returns NDC, indicating the ticket was issued on NDC. This is a round-trip itinerary with one traveler.

GDS exchanged ticket example

In the following example workbench commit response for an exchanged ticket, the previous itinerary is returned in the Offer object and the new itinerary is returned in OfferModify. For brevity, the text of TermsAndConditionsFull has been omitted and is shown as ... .