Skip to main content

IATA_ServiceListRS

Response · Shopping & Pricing · Implemented

Implemented

Delivers: SHPANC Shop for / with ancillaries · SHPAN2 Airline ancillaries · SHPAN3 3rd-party ancillaries (partial) · SHPMOD Transportation ancillaries · SHPSRV Airline Taxonomy (partial) · SHPLOC Localised offers · ORDRE2 Reshop for ancillaries (partial).

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.
  • SHPAN2 — The Airline Product Catalog (bags, meals, wifi, priority, lounge, pets, flex) is listed, re-priced in OfferPrice by the ordering domain and ordered with the flight in OrderCreate; adding one to a booked order is ORDRE2.
  • 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).
  • SHPMOD — Rail, coach and private-car rides timed to the offer's departures and arrivals (configured check-in / connection buffers) are listed, re-priced in OfferPrice by the ordering domain and ordered with the flight in OrderCreate; a ride cannot be added to a booked order (ORDRE2 adds airline extras and seats, not rides).
  • 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.
  • ORDRE2 — Airline extras (the booked order's catalogue — what Manage-My-Booking sells) and seats (its flights' seat maps) are reshopped as frozen quotes and accepted, or bought directly from the order's ServiceList / SeatAvailability; a seat is one passenger, one seat and one flight per message, and seats and extras are reshopped and bought in separate messages; ground-transport rides (SHPMOD) and partner products are not added to a booked order; a change paid by the seller's settlement plan is authorised against the agency's credit before it is made and refused under a flat-amount commission agreement, which states no rule for a charge made after the sale (commission_rule_undefined), or a tiered one stated in another currency than the change (commission_currency_mismatch); a change whose voucher or loyalty payment fails to capture stands, unpaid (no EMD), and goes to staff at once — it is not captured automatically; a loyalty hold the reconciler must give back instead (points that paid for no change) is retried for about half a day before it goes to staff, and lapses by itself at the hold's expiry.

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

Returns the catalogue of services available for the requested context.

When to use​

Response to IATA_ServiceListRQ.

Transport​

IATA_ServiceListRS is a response body. It is returned by its paired request rather than POSTed directly.

Example​

note

✅ The example below validates against the original XSD.

<?xml version="1.0" encoding="UTF-8"?>
<IATA_ServiceListRS xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersMessage">
  <Error>
    <LangCode xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">X</LangCode>
    <TypeCode xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">X</TypeCode>
  </Error>
</IATA_ServiceListRS>

Key fields​

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

FieldTypeRequiredRepeatableNotes
ErrorErrorType✓✓choice — pick one
ResponseServiceListResponseType✓—choice — pick one
AugmentationPointxs:any——extension point (AugmentationPoint)
DistributionchainDistributionChainType——
PayloadAttributesIATA_PayloadStandardAttributesType——

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_ServiceListRS } from '@oms/ndc-24-4';

const obj = IATA_ServiceListRS.parseXML(xml);   // parse a received response
IATA_ServiceListRS.schema.parse(obj);            // strict Zod validation