Skip to main content

IATA_OrderRetrieveRQ

Request · Order Management · Implemented

Implemented

Delivers: SHPANC Shop for / with ancillaries · SHPAN3 3rd-party ancillaries (partial) · SHPSRV Airline Taxonomy (partial) · SHPLOC Localised offers · ORDRET Order retrieve · PAYSUM Payment transaction summary · PAYCOM Disclosure of commission.

Limits today:

  • SHPANC — ServiceListRS carries the full ServiceDefinitionList and priced à-la-carte items per segment / journey and passenger, for an offer and (post-sale) for a booked order. An AirShoppingRQ with OfferCriteria/ServiceCriteria also gets each offer's ALaCarteOffer of the airline's catalogue services — the same items and opaque ids ServiceList issues for them, orderable in OfferPrice / OrderCreate, narrowed to the requested RFIC / RFISC / Airline Taxonomy code — for the first NDC_SHOP_SERVICES_MAX_OFFERS offers, each read within a timeout and all within a deadline, fail-open (a Warning names what was not listed and whether it was transient); the rides (SHPMOD) and partner products (SHPAN3) ServiceList also lists are not shopped with the offers. An excluding criterion (IncludeInd false) removes the offers whose fare brand includes a classified bag it names; anything else a brand bundles is only text and is not filtered (a Warning says so). A fare brand's structured bag allowance (checked / cabin pieces and kg per piece, entered per fare family in the catalogue) is a BaggageAllowance (Checked / Carry on) in AirShoppingRS / OfferPriceRS / OrderViewRS for the fare-paying passengers; a brand the catalogue gives none states none. A booked order's ServiceList covers the airline's extras (Manage-My-Booking's catalogue, bought with ORDRE2); rides are SHPMOD and partner products SHPAN3.
  • SHPAN3 — Partner (marketplace) products an admin opted into the marketplace's ndc channel are listed for an offer's trip with the partner named — each variant its own offer item, a product's options chosen from its service bundle (SelectedBundleServices) — re-priced by the ordering domain in OfferPrice and ordered with the flight in OrderCreate (captured with the marketplace, paid by the same tenders, their fulfilment shown on the order). Not sold over NDC: Arcube-connected products (session-bound offers that need supplier-specific booking fields) and marketplace bundles (capture prices a bundle from its components against a snapshot discount, and the catalogue states no price for a sum-priced one). Each product is sold once per order, a partner product needs a contact email to be delivered to, and a partner product is not added to a booked order (ORDRE2 adds airline extras and seats only).
  • SHPSRV — The airline services, the pre-reserved seat, the rides (SHPMOD) and the partner products (SHPAN3) sold over NDC each carry their IATA Airline Taxonomy node, where one is classified (AirlineTaxonomy: TaxonomyCode + the codeset path as DescText), on their ServiceDefinition — and a service, ride or partner product also on its offer / priced / order item — from the versioned D8 table (packages/marketplace-shared airline-taxonomy), whose every code is checked against the public IATA/EASD Airline Taxonomy Codeset (page version 3 of 2026-02-11, checked in beside the table); a marketplace airline product is classified by what it is — its type, refined by its own attribute where its instances differ (priority scope, pet carriage, equipment type, IFE plan) — and a partner product by its marketplace category, stamped by the marketplace on its eligibility feed: lounge access (1B58), fast track (26AC), airport transfers (2CEC Ground / Transport — they are cars and trains), train and bus transfers (2E7C, 2FA8), car rental (2D50), hotel vouchers (3138), eSIM (319C), travel insurance and baggage protection (3200), carbon offset (0E10). ServiceListRQ ServiceCriteria select by TaxonomyCode (a parent node matches the nodes below it), RFIC or RFISC, partner products included. Sold with NO node — and so never returned to a criterion that selects by node, RFIC or RFISC, while an exclusion keeps them: a pet shipped as cargo (the codeset has no cargo concept), an airline product with no registered type, and every partner product whose node depends on what no partner product records. The codeset’s food, drink and shopping nodes are tied to where the product is consumed (on board, within the terminal, within a lounge) and the marketplace records no point of consumption for a partner product (only the airports it is offered at), so these carry none: food and drink (coffee shop, restaurant and pre-flight dining categories), duty free (on board, collected in the terminal or shipped home), retail (apparel, electronics, general: a terminal shop or shipped), airport parking (the codeset’s only parking node is offsite), destination experiences (passes, travelcards and meet & greets share no node) and the generic buckets (partner vouchers, services, travel services); a partner category added later carries none until the table keys it. Bilateral TaxonomyFeature sub-codes are not used.
  • SHPLOC — Prices come in the requested currency. The airline’s content (fare-brand names and benefits, station, cabin, service and partner-product names, seat descriptions, promotion names, picture captions) comes in the requested language (LangUsage, else PrimaryLangID) where the airline has translated it in the Staff Console, otherwise in English with a content_language_fallback Warning naming it, and Processing/LangUsage states the languages of the content. The same applies to OrderViewRS, OrderReshopRS, ServiceListRS and SeatAvailabilityRS. Text the gateway composes (penalty, rule, ride and baggage-allowance descriptions, fee labels, warnings, errors) is English. Carrier, operator and aircraft names are proper names and are not translated. Languages are matched on the primary subtag, so zh-Hant and zh-Hans both resolve to zh, and pt-BR and pt-PT both to pt — a request for one script or region may be answered in the other. Text a supplier localised itself is passed through labelled en, whatever language it is actually in.
  • ORDRET — The full OrderViewRS (passengers, segments, journeys, services, seats, tickets / EMDs with coupon status, payments, refunds, statuses). An e-ticket carries all its coupons: past four flown segments the ordering module issues conjunction tickets with consecutive numbers, rendered as one TicketDocInfo of up to four Tickets — the schema maximum, so one traveller’s trip is documented up to 16 coupons.
  • PAYSUM — Every payment and refund on the order is listed in PaymentFunctions from the PaymentSession ledger: card brand + last four + PSP reference, masked voucher, settlement form of payment, loyalty points with the masked member account.

Rests on simulated supply (inventory, payment) — flagged on every response; see Simulated supply.

Retrieve a known order by its OrderID.

When to use​

To fetch the current IATA_OrderViewRS for an order you can already identify.

Transport​

PropertyValue
Method & pathPOST /24.4/OrderRetrieveRQ
Content-Typeapplication/xml
AuthAuthorization: Bearer <token> (or X-API-Key: <key>)
Routing headerIATA-Message-Name: IATA_OrderRetrieveRQ

See Authentication & connection for the full handshake.

Request example​

note

✅ The example below validates against the original XSD.

<?xml version="1.0" encoding="UTF-8"?>
<IATA_OrderRetrieveRQ xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersMessage">
  <DistributionChain>
    <DistributionChainLink xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
      <Ordinal>1</Ordinal>
      <OrgRole>Carrier</OrgRole>
      <ParticipatingOrg>
        <OrgID>X</OrgID>
      </ParticipatingOrg>
    </DistributionChainLink>
  </DistributionChain>
  <Request>
    <OrderValidationFilterCriteria xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes"/>
  </Request>
</IATA_OrderRetrieveRQ>

Key fields​

Top-level content model of IATA_OrderRetrieveRQ (one level deep, including inherited content):

FieldTypeRequiredRepeatableNotes
AugmentationPointxs:any——extension point (AugmentationPoint)
DistributionChainDistributionChainType✓—
PayloadAttributesIATA_PayloadStandardAttributesType——
POSPOS_Type——
RequestOrderRetrieveRequestType✓—

Build it with the SDK​

The @oms/ndc-24-4 package is a reference SDK — build, serialize, parse, and validate this message in code:

import { IATA_OrderRetrieveRQ } from '@oms/ndc-24-4';

const xml = IATA_OrderRetrieveRQ.toXML(payload, { pretty: true });
const obj = IATA_OrderRetrieveRQ.parseXML(xml);    // round-trips
IATA_OrderRetrieveRQ.schema.parse(obj);            // strict Zod validation