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, Booking Workflow, Ticketing Guide, Ticketing Workflow

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 commit might create a reservation, issue a ticket or EMD, modify reservation data, or exchange a ticket. 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 below for that option.

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 Resell APIs (see the NDC Modify, Exchange and Cancel 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 ancillary such as a wheelchair.

Request

Query Parameters

Parameter Description Required/Optional

autoDeleteDate

You can use the autoDeleteDate parameter as follows to create, update, or delete retention segments, and to create a shell booking in certain cases of booking failures.

Create, Update, Delete 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: At the end of the initial booking workbench session, commit and 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 Create Post-Commit Workbench responses. To update or delete the autoDeleteDate on an existing booking, 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 value at the end of the initial booking workflow causes AirReservation to create 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 Booking Guide for Failed/Shell Bookings.

Optional

Issuance

Sending the optional Issuance query parameter with a value of BACKOFFICE sends a message to update any back office accounting systems with ticket information at the time of ticketing.

You can send the message before the ticket is issued by sending a commit without payment, or commit with payment and the Issuance parameter to issue the ticket and send the message. The response includes an interface control number.

Optional

payLaterInd

For use only in Exchange Ticketing.

Optional, only for use in exchanges

DocumentValue

For use only in Exchange Ticketing.

Optional, only for use in exchanges

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:

  • For GDS, a value in OfferStatus/StatusAir/code of either TK or UN indicates the flight has schedule change information.

  • For NDC, the response returns NDC CONTENT HAS CHANGED in ReservationComment when a schedule change has occurred.

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

Update or Delete Ticketing Time Limit Date
AirReservation 23.11.31 and later. 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

AirReservation 23.11.39 and later. GDS only; not supported for NDC.

Send the following 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.

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.