Booking Workflow

The booking workflow uses a workflow of multiple calls to build a workbench, add offer and traveler information to the workbench, and commit the workbench.

The workbench commit creates a PNR and a held booking pending subsequent ticketing.

This topic details the flow of requests and responses in the AirReservation booking workflow, both required and optional. For endpoints and a listing of objects in the requests and responses, see the AirReservation API Reference.

Some steps within the booking workflow are optional, or specific to either GDS or NDC content. Some steps can take place in either the AirReservation or the AirTicketing workflow. Be sure to see Reservation and Ticketing Workflows for a summary of possible workflow options.

Any of the following optional steps can be added into the workflow as necessary, see the links below:

  • Request seat availability and book free seats.
  • Add remarks and SSRs to the reservation. Some are sent when you add a traveler while others are sent in their own payload.

Travelport retains a search from any of the search APIs in cache for 12 minutes so it can be added as an offer to the workbench.

Any workbench, either before booking or after booking (post-reservation) is valid for 30 minutes and must be committed within that time window or it expires.

In this topic:

AirReservation Workflow Summary

The following table outlines all required and major optional steps that make up the booking workflow. Details and examples are provided in the following sections.

Step Type of request Notes

Create the reservation workbench

POST

First mandatory step in the workflow.

Returns an identifier for the workbench.

Add offer and store fare

POST

Add offer can be sent with either:

  • Full payload: Sends complete itinerary details, GDS only. Also supports storing fares with optional brand or pricing modifiers.

  • Reference payload: Sends reference identifiers from an air search response, GDS and NDC.

With AirReservation 21.9.5 and later, either the offer or traveler can be added next. In earlier versions, Travelport recommends adding the offer before the traveler.

For NDC only, you can repeat the multiple add offer step to combine multiple one-way offers into one PNR at commit.

Returns a confirmation identifier.

Add one or more travelers

POST

Returns a confirmation identifier for each traveler.

Each traveler must be sent in a separate request. Several types of traveler remarks and SSRs are included in the traveler payload.

Add remarks (optional)

POST

Some remarks are sent as part of the add traveler payload, while others are sent in their own payload. See Remarks for details.

Add form of payment (optional)

POST

Optional. Store form of payment information with the PNR to be used subsequently in ticketing.

Add payment (optional, NDC only)

POST

Optional. Commit payment information to both issue a PNR and a ticket in the subsequent commit step. This is the Instant Pay workflow and is supported only for NDC.

Check reservation details prior to generating the PNR (optional)

GET

Optional. Returns workbench details at any point before committing the workbench.

Commit the workbench, generating a PNR

POST

Final mandatory step in the reservation workflow. In this step, you can also assign a purge date to the PNR so it can be retrieved for up to 340 days after the date the reservation is made. This creates a retention segment on the host PNR.

Returns a reservation confirmation and PNR.

Ignore/discard workbench

DEL

Optional. At any point in the workflow prior to commit, if necessary, you can send a delete request to discard the workbench.

AirReservation Required Workflow

To create a booking, at a minimum, you must create a workbench session, add an offer, add at least one traveler, and commit the workbench. These required steps are detailed next.

Create New Workbench

Create a workbench to start booking.

The message payload sends a blank ReservationID object per below.

{
    "ReservationID": {
                
    }
}

The response returns a workbench identifier that must be sent in all subsequent requests for this workbench session.

{
    "ReservationResponse": {
        "Reservation": {
            "@type": "Reservation",
            "Identifier": {
                "authority": "Travelport",
                "value": "af9da82f-1966-4134-8561-3fd1a430d62e"
            }
        }
    }
}

Add Offer and Store Fare - Full Payload (GDS)

With AirReservation 21.9.5 and later, either the offer or traveler can be added in any order after creating the workbench. In earlier versions, Travelport recommends adding the offer before the traveler.

A request to add an offer for GDS can be sent with either:

  • a full payload, which sends full itinerary details; also supports storing fare with optional pricing modifiers or brand information. (See AirReservation API Reference for details.)
  • a reference payload per below, which sends identifiers from the AirSearch or Fare Family Search response

The following example full payload stores a fare for a one-way itinerary. It does not include pricing modifiers or brand information.

The request above returns a confirmation identifier per the following example response.

Add Offer and Store Fare - Reference Payload (NDC or GDS)

The Add Offer reference payload request sends identifiers from the AirSearch, Fare Family Search, or Next Leg Search response.

With AirReservation 21.9.5 and later, either the offer or traveler can be added in any order after creating the workbench. In earlier versions, Travelport recommends adding the offer before the traveler.

The reference payload does not support optional pricing modifiers and/or brand information.

NDC supports only the reference payload.

GDS can use either the reference payload or the full payload.

The response returns a confirmation identifier per below. Note that for a GDS itinerary, authority is Travelport as shown below, while for an NDC itinerary, authority is the carrier name.

Add a Traveler

AirReservation supports multiple travelers and all PTC types. Traveler information can include traveler contact details, some types of remarks including certain SSRs, and frequent traveler/loyalty code numbers.

Add each traveler to the workbench in a separate request.

Traveler information cannot be modified after that traveler is added.

Several types of SSRs and optional remarks can be added during this step, including traveler and client delivery remarks. See Remarks and SSRs.

Optional seat booking takes place after the Add Traveler step.

With AirReservation 21.9.5 and later:

  • Either the offer or traveler can be added in any order after creating the workbench. In earlier versions, Travelport recommends adding the offer before the traveler.
  • In earlier versions, if invalid SSR information is added during the Add Traveler step, the add traveler request fails at commit. With 21.9.5 and later, the invalid SSR information is not added, but the Add Traveler step succeeds, adding the traveler but returning an appropriate warning message about the invalid information. For example, if an invalid customer loyalty number is sent, the traveler is successfully added to the workbench and subsequently to the PNR at commit, but the addition of the loyalty number fails with the warning message M CHECK MILEAGE MEMBERSHIP NUMBER. AirReservation returns warning messages for other conditions as provided by either the host or the carrier as applicable.

Date of birth is required for child PTC types, including CNN and CHD.

Any traveler sent without a PTC value is defaulted to ADT. PTC can be sent or omitted for ADT travelers. AirReservation defaults the PTC to ADT and returns it in the PNR retrieve.

An INF (infant) cannot be added without an ADT (adult) PTC already on the itinerary.

The following example request sends information for one traveler.

Commit Workbench (Create PNR)

After adding all information to the workbench, commit the workbench to book the itinerary and create a PNR.

There is no message payload.

The commit step causes different actions depending on the workflow you are implementing (see Reservation and Ticketing Workflows):

  • In the NDC Instant Pay workflow, which includes adding FOP and payment, the commit both generates a PNR and issues a ticket.
  • In the Hold and Pay workflows, commit generates a PNR. The next step is Ticketing.
  • In the workflow for ticketless carriers, which includes adding FOP, the commit generates a PNR. There is no ticketing step.

The commit response is the same as a PNR retrieve response, returning all information added during the booking workflow.

If any optional pricing modifier sent in the Add Offer step 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.

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 PNR for one month after travel, at which time the PNR is purged and no longer available.

To set a longer purge date, as part of the commit POST request above, add that date in YYYY-MM-DD format in the query parameter ?autoDeleteDate=, as in ?autoDeleteDate=2019-12-12. You can set a purge date that is up to 338 days from the date the reservation was created. Adding a purge date creates a retention segment on the host PNR.

Carrier Locator Code

In some instances, the carrier requires more time to return the carrier locator code than the time between commit and returning the PNR. Some agencies require the carrier locator code at the time of booking. AirReservation attempts an additional PNR retrieve from the carrier to populate the carrier locator code if it is not initially available. In some instances, however, carriers do not return a carrier locator code for 15 minutes or longer; in this case agencies must do a PNR retrieve later. This can happen in any booking scenario upon commit, but it is most common when an ancillary such as a wheelchair is in the book request.

If the carrier locator code cannot be retrieved after one retry, AirReservation returns the following warning in Result/Warning/Message:: Carrier locator code not returned by carrier/provider. Please try to retrieve later.

Commit Response

The response returns a confirmation identifier and reservation details. The information in the Commit response varies depending on the booking flow used.

The following examples show a commit response for a GDS itinerary using multiple forms of payment, and then for an NDC booking using the instant pay booking flow.

Create post-commit workbench

To modify or ticket an existing reservation, you create a workbench by sending the PNR of the reservation. Carry out other steps as needed and finish the workflow by committing the workbench. Supported post-reservation modifications include the following:

  • adding additional forms of payment
  • adding free seats to a booking
  • ticketing

You may want to first retrieve the PNR to verify the information currently in that PNR.

See the Ticketing API Reference for the endpoint.

There is no message payload.

If you haven't yet created the booking, you must instead create a new workbench.

The response returns itinerary details and is the same as for a PNR Retrieve, plus a workbench ID in an additional Identifier object at the end of the response. The following excerpt shows a workbench ID. This workbench ID must be sent in all subsequent requests for this workbench session.

Optional AirReservation Steps

Any of the following steps can be added to the required workflow described above. You must first create a workbench for either a new or existing reservation as appropriate.

Retrieve Workbench

At any point before commit, you can retrieve the workbench. This optional step allows you to verify reservation details before booking.

There is no message payload.

The request returns all information that has been added to the reservation workbench at this point. For example, if you have added an offer but not travelers, the request returns offer details but no traveler information.

Add Remarks and Special Services

AirReservation supports adding several types of remarks and SSRs during the air reservation workflow. See the Remarks and SSRs topic for details and examples, including whether adding each remark is supported during the booking workflow and/or after a PNR is created. Some remarks are added as part of the Add Traveler step above while others use their own payload.

Add Multiple One-Way Offers (NDC)

In AirReservation 19.6.2 and later, for NDC only, you can perform multiple add offer steps to combine multiple one-way offers into one PNR at commit.

To do so, repeat the Add Offer step above, sending an Add Offer request for each one-way offer to add. For each request, send the same CatalogsOfferingsIdentifier value, and the CatalogOfferingIdentifier and ProductIdentifier values for the offer being added in that request.

An example PNR retrieve response for a PNR with multiple one-way offers is shown in PNR Retrieve.

Add Form of Payment

The AirReservation workflow supports adding form of payment (FOP) information as an optional step. If not added during booking, FOP is required at ticketing. See Book and Ticketing Workflows.

The request payload includes FOP information. See the AirTicketing API Reference for a listing of all payload objects.

FOP can be added during the reservation workflow in any of these three scenarios:

  • For GDS, FOP can be added during reservation to be stored and retrieved later during the AirTicketing workflow. If form of payment is not added at the time of reservation, it must be added in ticketing.
  • For NDC, FOP can be added only as part of the Instant Pay workflow, in which payment is added and the Reservation workbench committed to create a PNR and issue a ticket in one step. If FOP is added but a ticket is not issued in the commit step, the FOP is not stored and will not be available for retrieval during ticketing.
  • For ticketless carriers, add FOP and then commit to create the reservation.

The response returns a confirmation identifier.

Add Multiple Forms of Payment - GDS

For GDS only, AirReservation supports sending multiple forms of payment. Up to two forms of payment can be added either during the initial booking workflow, or after booking and before ticketing.

At this time multiple forms of payment are supported only for bookings with one single passenger.

To send multiple forms of payment, repeat the Add Form of Payment step as needed, assigning each form of payment a unique value in the FormOfPaymentRef object. This is a user-assigned identifier for this form of payment that must also be sent in the Add Payment step.

To add a first or additional form of payment to an existing booking, first create a post-commit workbench, repeat the Add Form of Payment step as needed, and then commit the workbench.

Note that when ticketing, you will need to repeat the Add Payment step in the ticketing workflow for each form of payment added.

Add Payment - NDC (aka Instant Pay)

For NDC itineraries only, when using the Instant Pay workflow, after adding FOP you can add payment. When you commit the workbench, both a PNR and ticket will be issued. (For GDS, you can add payment only after booking as part of ticketing.)

The response returns a payment confirmation. The value returned has no subsequent use in the workflow at this time.

Ignore/Discard Workbench

At any point in the workflow before commit, if necessary, you can discard the workbench and any information in it.

Send the DEL request to the following resource with the workbench ID returned in the create workbench step:

DEL reservationworkbench/{workbenchID}

Base path:

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

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

Send a blank ReservationID object in the payload per the example request below.

{
    "ReservationID": {
    }
}