Offer-/Order-Structure

General information

The NDC structure is complete based on the concept of offers and orders. This starts with the shopping-flow, that works like a “shopping-cart”.

The client sends a request to the API and receives one or more offers, that include the requested content and pricing information.

These offers can then be combined individually to build an order, which represents the completed booking.

After an order has been created, it consists of several order items, that also represent content and pricing information.

These order items can also be altered or deleted, or new items can be added to the order.

Model

Offers and orders mostly have the same structure. The top-level offer/order contains one or more offer/order items, which represent specific parts of the offer/order.

These items themself contain several so-called services. These services should not be confused with ancillary services, like meals etc., that can be obtained using IATA_ServiceListRQ/RS.

In the NDC definition, everything is a service. So the services, that are included in the offer/order items can represent every single part of the booking.

Example:

Service, that contains a flight:

<Service>
   <PaxRefID>PX1</PaxRefID>
   <ServiceAssociations>
      <PaxJourneyRefID>FL1</PaxJourneyRefID>
      <PaxJourneyRefID>FL2</PaxJourneyRefID>
   </ServiceAssociations>
   <ServiceID>SV1</ServiceID>
</Service>

Service, that contains a non-flight service (e.g. a meal):

<Service>
   <ServiceDefinitionRefID>SVD1</ServiceDefinitionRefID>
   <ServiceID>SV1</ServiceID>
</Service>

Services always include references to the items they contain. In the above samples, the services refer to PaxJourneys and ServiceDefinitions, that are also present in the NDC response.

Here is a simplified sample of an offer:

<Offer>
   <OfferID>OF25a8bea9-89f5-11ea-98be-25340131a18b</OfferID>
   <OfferItem>
      <OfferItemID>OFI25a8bea9-89f5-11ea-98be-25340131a18b1</OfferItemID>
      <Price>
         <TotalAmount CurCode="EUR">129.99</TotalAmount>
      </Price>
    <Service>
         <PaxRefID>PX1</PaxRefID>
         <ServiceAssociations>
            <PaxJourneyRefID>FL1</PaxJourneyRefID>
         </ServiceAssociations>
         <ServiceID>SV1</ServiceID>
      </Service>
   </OfferItem>
   <OwnerCode>ZZ</OwnerCode>
   <TotalPrice>
      <TotalAmount CurCode="EUR">129.99</TotalAmount>
   </TotalPrice>
</Offer>

Offer-/Order-IDs

All offers, orders and their sub-elements can be identified by their IDs. The IDs are constructed in a specific structure:

Offer

Offer-IDs are based on UUIDs (Universal Unique Identifier), which are 128-bit numbers.

The Offer-ID always has the structure “OF” + UUID (e.g. OF25a8bea9-89f5-11ea-98be-25340131a18b).

The ids of the offer items are based on the id of the offer, to which they belong.

OfferItem-IDs have the following structure: “OFI” + UUID of the offer + number of the offer item in the offer (e.g. OFI25a8bea9-89f5-11ea-98be-25340131a18b1)

Services don’t follow that convention and are simply increment over the NDC message, as an exact reference isn’t required in the current implementation.

Service-IDs have the structure “SV” + incremented number.

Order

Order-IDs are also unique, but they’re based on the number in the airline reservation system.

If my booking in the reservation system has the number ABC123, this is also my order-ID.

The included order items are based on the id of the order: “OI” + orderId + numer of the order item in the order (e.g. OIABC1231).

Like in the offer structure, services are just incremented over the NDC message.

Structures

Orders mostly follow the same structure, but offers can include different amounts of content to provide as much flexibility as possible.

The most common offer structures are listed below, based on the NDC message, in which they’re included:

IATA_AirShoppingRS

The IATA_AirShoppingRQ/RS is used to search for flight items, which have no contextual reference to specific passengers.

Therefore, the response contains one offer per flight result. Depending on the airline reservation system, this flight result can contain either a single origin-destination (e.g. FRA-TFS including possible via-segments), or a roundtrip (e.g. FRA-TFS + TFS-FRA including possible via-segments).

IATA_ServiceListRS

The IATA_ServiceListRQ/RS is used to request a service catalogue with special ancillary services. These services are represented in a special structure called “ALaCarteOffers”, which have more flexibility of combination.

The response always contains one ALaCarteOffer, which contains multiple ALaCarteOfferItems. Each offer item represents one ancillary service and has an element “Eligibility”, which shows, with which segments these services can be combined.

IATA_SeatAvailabilityRS

The IATA_SeatAvailabilityRQ/RS is used to request available seats for a flight. Having an offer item for each seat would cause a huge payload, so the offer items represent seat groups.

The response always contains one ALaCarteOffer, which contains multiple ALaCarteOfferItems. Each offer item represents one seat group that contains all seats for a specific price.

Every seat in the response contains a reference, to which offer item (seat group) it belongs.

In the following requests, the offer item of the seat group is used and in addition the specific seat is stated.

IATA_OfferPriceRS and IATA_OrderViewRS

Starting with the IATA_OfferPriceRQ/RS, the different offers from the shopping stage are bundled and returned in a single offer (or later order).

After this step, the responses always contain one offer/order, that contains one offer/order item per passenger and per service.

That means, that if we have an order with 2 flights, 2 passengers and meals for each flight, then we would have 8 order items:

  1. Flight 1 Pax 1

  2. Flight 1 Pax 2

  3. Flight 2 Pax 1

  4. Flight 2 Pax 2

  5. Meal 1 Pax 1

  6. Meal 2 Pax 2

  7. Meal 3 Pax 1

  8. Meal 4 Pax 2

(Meal 1+2 refer to the first flight, Meal 3+4 to the second one)