Skip to content
/
Workbench Commit

Workbench Commit

Request

After all required and any optional steps in a booking workbench session, send a POST request with the workbench identifier to commit the workbench. 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 (If no Add Payment request has been sent, committing the workbench books the itinerary and generates a PNR).

  • 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).

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.

Please note:
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.

Security
bearerAuth
Path
Identifierstring, <= 128 charactersrequired

The ReservationWorkbenchIdentifier you wish to commit

Example:49f58f5f-c443-43b4-9f5d-be405fd00a01
Query
autoDeleteDatestring, (date)

Used to create, update, or delete retention segments, and to create shell bookings for booking failures caused by specific scenarios.

For Retention Segments:
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:

  • To update the purge date for an existing retention segment, send the new date

    • e.g., ?autoDeleteDate=2026-08-23

  • To delete an 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.

Issuancestring

Indicates the type of issuance that should be performed at commit.
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.

Enum:"Ticket""BackOffice""All""Invoice"
DocumentValuestring

For use only when exchanging GDS tickets - optional for GDS Exchanges - 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.
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 you to display, modify, and issue your own MCO outside of the TripServices APIs if desired. If the reservation is subsequently ticketed using Exchange Ticketing, the MCO is issued at commit as usual.
If not sent any value remains on the EMD.

Enum:"Retain""Refund""Forfeit""Void"
payLaterIndboolean

For use only when exchanging GDS tickets - required for GDS Exchange - 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:

  • If true: Holds changes for later fulfillment and ticketing.

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

Headers
TraceIdstring, [ 10 .. 89 ] characters

Identifier used to correlate Air API invocations across a multi-call business flows.

Example:TraceID_123456789
XAUTH_TRAVELPORT_ACCESSGROUPstring, = 36 characters([a-zA-Z-0-9-_]*)

Identifies the Travelport access group with which the caller is associated

Example:19Y88702-C27A-4E5D-829A-89D7016688B1
travelportPlusSessionIdentifierstring, [ 0 .. 100 ] characters([a-zA-Z-0-9-_]*)

travelportPlusSessionIdentifier used to maintain an established agency session

Example:49f58f5f-c443-43b4-9f5d-be405fd00a01
TVP-PCC-Corestring^[a-zA-Z\d]{3,4}_\w{2}$

Allows user to pass PCC instead of Access Group ID

Example:DU7_1G
Bodyapplication/json

Workbench Commit request payload.

NotificationArray of objects, [ 1 .. 5 ] items(Notification)

Optional top-level object; required for QueueNumber or Date objects, such as Ticketing Time Limit.

scheduleChangeAcceptedIndboolean

Indicator to update the booking with an involuntary flight schedule change, which occurs when an airline has modified a flight schedule. Used when a schedule change has occurred after the booking has been made. If you are only accepting a schedule change, you can (but are not required to) create a workbench session before this commit.

  • If true: Accepts the schedule change.

  • If false (default behavior): Does not update the booking with the schedule change.

To check whether a flight schedule has been modified, send a Reservation Retrieve request. In the response:

  • 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. See NDC Flight Disruption Handling in the Booking Guide for details.

inhibitResidualDocumentIssuanceIndboolean

If true, any residual value will not be applied to an MCO or EMD.

Example:true
enableTwoStepCommitIndboolean

GDS only; not supported for NDC. Supported in the initial booking workflow, or when adding an offer to an existing reservation, or during GDS exchange.
Enables a two-step commit process that, when combined with errorWhenPriceChangesInd (not supported for exchange workflow), errorWhenScheduleChangesInd, and/or overrideMCTInd, returns a warning if the error for that indicator occurs. If so, AirReservation keeps the workbench active and returns a warning message and additional details.

  • If true: Enables a two-step commit that returns a warning message in selected scenarios instead of proceeding with the booking or exchange. Reservation warnings, such as minimum connection time, will be returned to the user for review and a second commit will be required to proceed with creating the reservation.

  • If false (default behavior): Does not enable two-step commit. In the case of a price or schedule change, or MCT violation, creates the booking or completes the exchange and returns a warning message about the change.

If a two-step commit is triggered, you must send an additional commit request if you want to complete the booking or exchange. See Optional Actions at Commit in the booking guide for more details and alternative actions to proceeding with the booking or exchange.

Example:true
overrideMCTIndboolean

GDS only; not supported for NDC.
A Minimum Connect Time (MCT) violation occurs when an airline deems there is not sufficient time for passengers to reach their connecting flight. MCT thresholds are set by individual carriers.
Behavior at initial workbench commit and during exchange:

  • If true (default behavior): In the case of MCT violation, AirReservation overrides the warning, creates the booking or completes the exchange (if successful), and returns the warning in the response.

  • If false: When sent with enableTwoStepCommitInd=true, triggers a two-step commit if the carrier returns an MCT violation, returning a response with a message that the connection duration cannot be less than the minimum connecting time. Note that if sent with false and enableTwoStepCommitInd=false or is not sent, an error occurs and the booking workbench is discarded.

If no MCT violation occurs, AirReservation creates the booking or completes the exchange at initial commit as usual.
If a two-step commit is triggered and you want to proceed with the booking or exchange, for the second workbench commit, send overrideMCTInd as true, or send empty or do not send, to override the MCT message from the carrier and create the booking or complete the exchange. Do not send again with false, which discards the workbench.

Example:true
errorWhenScheduleChangesIndboolean

GDS only; not supported for NDC.
Behavior at initial workbench commit and during exchange:

  • If true: When sent with enableTwoStepCommitInd=true, triggers a two-step commit if the schedule has changed since the offer was added to the workbench or since repricing for an exchange. The response includes a warning, an Offer @type OfferModify object that returns scheduleChangeInd=true to note the schedule change, and updated flight details in Product.

  • If false (default behavior): In the case of a schedule change, creates the booking or completes the exchange and returns a warning message about the change.

If no schedule change occurs, AirReservation creates the booking or completes the exchange at initial commit as usual.
If a two-step commit is triggered and you want to proceed with the booking or exchange, for the second workbench commit, send with false or do not send. Do not send with true, which returns an error and discards the workbench.

Example:true
scheduleChangeRepricestring(ScheduleChangeRepriceEnum)
Enum:"RetainOfferPrice""AcceptOfferPriceDifference"
Example:"AcceptOfferPriceDifference"
ReceivedFromstring, <= 61 characters

GDS only; not supported for NDC. Supported for both ticketing and exchanges.
Override the ReceivedFrom field with custom data.
After sending, ReceivedFrom details are viewable only in a terminal program, not in the TripServices Reservation Retrieve API.

Example:"TW"
errorWhenOfferPriceChangesIndboolean

GDS only; not supported for NDC.
Behavior at initial workbench commit:

  • If true: When sent with enableTwoStepCommitInd=true, triggers a two-step commit if the price has changed since the offer was added to the workbench. The response includes the warning, and an Offer @type OfferModify object that returns priceUpdatedInd=true to note the updated price, returns the new price, and breaks down the price change.

  • If false (default behavior): In the case of a price change, creates the booking and returns a warning message about the change.

If no price change occurs, AirReservation creates the booking at initial commit as usual.
If a two-step commit is triggered and you want to proceed with the booking, for the second workbench commit, send with false or do not send. Do not send with true, which returns an error and discards the workbench.

Example:true
errorWhenOfferPriceCancelledIndbooleandeprecated
curl -i -X POST \
  'https://api.pp.travelport.net/11/air/book/reservation/reservations/49f58f5f-c443-43b4-9f5d-be405fd00a01?autoDeleteDate=2019-08-24&Issuance=Ticket&DocumentValue=Retain&payLaterInd=true' \
  -H 'Authorization: Bearer <YOUR_JWT_HERE>' \
  -H 'Content-Type: application/json' \
  -H 'TVP-PCC-Core: DU7_1G' \
  -H 'TraceId: TraceID_123456789' \
  -H 'XAUTH_TRAVELPORT_ACCESSGROUP: 19Y88702-C27A-4E5D-829A-89D7016688B1' \
  -H 'travelportPlusSessionIdentifier: 49f58f5f-c443-43b4-9f5d-be405fd00a01' \
  -d '{
    "enableTwoStepCommitInd": true,
    "overrideMCTInd": false,
    "errorWhenScheduleChangesInd": true,
    "errorWhenOfferPriceChangesInd": true
  }'

Responses

OK - Successful Response - 200

Bodyapplication/json
ReservationResponseobject(ReservationResponse)

The response of a Create Reservation (Reference or Full Payload), Sync Reservation, Modify/Add Reservation, Create/Modify Passive Reservation, Retrieve Reservation, or Cancel Reservation endpoint.
The structure detailed here is the same for all of these API responses. For Post-Commit Workbench Create and Workbench Retrieve the response is structured the same, plus a workbench identifier.
The information returned in the Reservation Retrieve response varies depending on the information that has been added to the reservation at the time of retrieve, whether the reservation has been ticketed, and whether the reservation was created using the Travelport TripServices APIs or another program.

Please note the requests for Workbench Commit (Create Reservation), Post-Commit Workbench Create, and Workbench Retrieve do not support the query parameters available in Reservation Retrieve and do not return the following:

  • any document override, accounting, historical, and DOCI remarks
  • any custom rules
  • brand attributes
  • baggage dimension and fee details
  • fare rules
  • ATPCO RouteHappy flight amenities

For Two-step Commit: In the initial booking workflow, or when adding an offer to an existing reservation, or during an exchange, you can send enableTwoStepCommitInd=true to enable a two-step commit process that returns a warning if specific error scenarios occur. See Two-step Commit in the Guides for more information. If a Two-step Commit is triggered, the booking is not created and the first commit response returns objects that may not return in a typical commit response payload. The payload varies based on the warning that triggered the Two-step Commit, and may include additional objects if seats or other ancillaries were added to the workbench. Because the booking was not committed, Result/status is 'Not Processed'. A descriptive error or warning is returned in Result/Error/Message or Result/Warning/Message. The response to a second commit that creates a booking uses the same structure as a Reservation Retrieve response.

Response
{
  "ReservationResponse": {
    "@type": "response",
    "transactionId": "49f58f5f-c443-43b4-9f5d-be405fd00a01",
    "traceId": "TraceID_123456",
    "correlationId": "49f58f5f-c443-43b4-9f5d-be405fd00a01",
    "reservationStatus": "Success",
    "Result": {
      "@type": "Result",
      "status": "Complete",
      "Error": [ … ],
      "Warning": [ … ]
    },
    "Identifier": {
      "value": "A0656EFF-FAF4-456F-B061-0161008D7C4E",
      "authority": "TVPT"
    },
    "NextSteps": {
      "baseURI": "www.travelport.com",
      "id": "5",
      "NextStep": [ … ]
    },
    "ReferenceList": [
      null
    ],
    "CurrencyRateConversion": [
      { … }
    ],
    "Pagination": {
      "@type": "Pagination",
      "page": 1,
      "pageSize": 20,
      "totalPages": 5,
      "totalItems": 100
    }
  }
}