Skip to main content

IATA_SeatAvailabilityRS

Response · Shopping & Pricing · Implemented

Implemented

Delivers: SHPSRV Airline Taxonomy (partial) · SHPSTO Seat options (partial) · SHPSTA Seat map and availability · SHPSTP Seat price points · SHPLOC Localised offers.

Limits today:

  • 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.
  • SHPSTO — Seats from each flight's seat map (SeatAvailability) are priced in OfferPrice and ordered with the flight in OrderCreate, sold once across every channel. After the sale a seat change is one passenger, one seat and one flight per message: an OrderReshopRQ names one flight (OriginDestCriteria), one passenger (PaxList) and one seat (SeatCriteria), and an OrderChangeRQ buying from the order's seat map selects one seat (SelectedSeat) for one passenger; seats are reshopped and bought apart from extras (SeatCriteria and ServiceCriteria in separate OrderReshopRQs, a seat and extras in separate OrderChangeRQs).
  • 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.

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

Returns the cabin layout, seat map, and per-seat availability and price.

When to use​

Response to IATA_SeatAvailabilityRQ.

Transport​

IATA_SeatAvailabilityRS 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_SeatAvailabilityRS 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_SeatAvailabilityRS>

Key fields​

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

FieldTypeRequiredRepeatableNotes
ErrorErrorType✓✓choice — pick one
ResponseSeatAvailResponseType✓—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_SeatAvailabilityRS } from '@oms/ndc-24-4';

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