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:

Use this base path if you have not yet received or not migrated to the new credentials from Travelport:

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

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

Use this base path after you have migrated to the new credentials from Travelport (using .net instead of .com):

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

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

Related Content: Booking Guide, Ticketing Guide

The Commit Workbench request ends a workbench session and commits all requests made in that session to the booking.

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 (if payment for that ticket or EMD is included in the workbench with the Payment request)

  • Modify traveler data (after the Traveler Updatable Items and Traveler Update requests are sent in the workbench)

  • Exchange a ticket using the GDS Exchange APIs (NDC exchanges use Modify to end the exchange)

Note that some workbench commit options are supported only in specific flows, such as the initial booking flow, a ticketing commit, or an exchange commit, as specified for that option where applicable in this topic.

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, 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 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. Reservation Retrieve can return additional data with query parameters not available for Workbench Commit. See the Reservation Retrieve API Reference for full details on the response structure. The following table includes objects returned for either booking or ticketing workbench commits. It does not include all objects that could possibly be returned, such as for seats or ancillaries on the booking, which are documented in several other places in the online help.

If the flight schedule or price has changed since the offer was added to the workbench, the booking is created at workbench commit and the response returns a notification in Result/Error/Message per the examples below. For GDS only, you can activate two-step commit if you want to receive a message prior to creating the booking so you can decide whether to proceed.

  • 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"

 

Response for initial workbench commit for two-step commit

In the initial booking workflow, or when adding an offer to an existing reservation, you can 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 the response differs from the typical commit response. The table below lists the top-level objects returned in the first commit of the two-step commit response, and provides details on any objects that are returned only in that response. For shared objects that are the same as in the regular Workbench Commit and Reservation Retrieve responses, the links below lead to full descriptions in the Reservation Retrieve API Reference.

For the second commit in the two-step commit process, see the typical Workbench Commit response in the preceding table.

See the Air Booking Guide for a full description and examples for two-step commit.

Example Request

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

No message payload is required for workbench commit. The following examples show some of the optional payloads supported; see the response table above and the Booking Guide for full details.

Send the following optional payload at workbench commit to trigger a two-step commit in the case of warnings about a schedule change, price change, and/or MCT warning.

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

Send the following optional payload to add the booking to an agency queue (QueueNumber) and update the ticketing time limit (Date object).

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 content.

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.

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.

The 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 three commit response examples are for NDC bookings. Similarly, the following example is for an NDC held 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.