Skip to main content

IATA_AirShoppingRQ

Request · Shopping & Pricing · Implemented

Implemented

Delivers: SHPFLT Shop for flights · SHPOPE Multi-city / open jaw · SHPITL Flights operated by other airlines · SHPANC Shop for / with ancillaries · SHPPER Personalised offers (PTC, loyalty, agreements) · SHPLOC Localised offers · SHPBND Bundled offers · SHPREV Price points with dynamic adjustments · SHPDSC Discounts / promotions · SHPRMD Rich media · SHPOR1 Offer conditions and restrictions (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.
  • SHPPER — Passenger types (the request's PTC) and ages, the authenticated seller's agreements (optionally a ContractID from OfferCriteria/ProgramCriteria of this airline's programmes) and this airline's loyalty tiers price offers through the Staff Console promotions engine, for rules that target the NDC channel. Member pricing is all-or-nothing per party — a product choice, fail-closed: it applies only when every fare-paying passenger carries this airline's account with the account holder's name (checked by the platform; an unknown or unverified account is priced exactly as no account), otherwise the party is priced as guests with a Warning; there is no per-passenger tier pricing within a party. Every offer of a member-priced shop is bound to those accounts (kept internal, as keyed MACs): OrderCreate must carry them in the holders' names, else it is refused (753); the tier is the one priced at shop (the offer's lifetime) and is not re-read at OrderCreate. An offer priced for a seller can be booked by that seller only. Personalised pricing is given to the NDC gateway alone — a shop that does not present the gateway's own credential is priced as an anonymous public shop, with no adjustments at all. If the platform credentials the offer and ordering services share do not match, an offer's binding cannot be read and it is REFUSED at OrderCreate rather than booked unbound. Reshop alternatives (OrderReshop) are priced without member or agreement adjustments, so a flight change re-prices the changed bound at the public fare: a member or agreement discount carried on it is clawed back in the change quote (and any surcharge on it refunded). A ProgramCriteria without such a ContractID, and any ProgramAccount, is reported in a Warning, not applied.
  • 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.
  • SHPREV — The price points are the offer engine's fares and fare-brand ladder; the adjustments are the Staff Console promotions engine's auto-apply rules that explicitly target the NDC channel — discounts down and surcharges up — itemised as Discount and Surcharge per offer and item and recorded on the order (its lines at what they cost, so refunds, bound cancels and divides work from what was paid; OrderViewRS states the breakdown only while the order stands at the total it was recorded for). Whenever the promotions engine cannot be asked for a shop — promotion criteria not switched on, or the engine unreachable, slow or refusing — that shop is priced with NO adjustments at all and a Warning says so: it is all-or-nothing, so SURCHARGES are dropped along with discounts (an unpriced surcharge is never added later). A surcharge is part of what the order costs: the seller's commission and the traveller's loyalty earn are both computed on the order total INCLUDING it — a deliberate rule, not an oversight. A fixed amount or cap applies only to offers priced in its own currency (never converted): elsewhere the rule is not applied and a Warning says so. Reshop alternatives (OrderReshop) are priced without these adjustments, so a flight change re-prices the changed bound at the unadjusted fare: a surcharge carried on it is refunded in the change quote (and a discount on it clawed back). Continuous (demand-shaped) pricing is a separate capability, SHPCPR.
  • SHPOR1 — Every flight offer on this channel carries its fare brand’s own conditions — the airline’s brand policy, the terms the servicing engine applies once booked: changeable and refundable from the policy, cancellable and renameable as the engine allows. An offer whose brand policy cannot be read keeps the supplier’s conditions and says so (fare_conditions_supplier). Those conditions are frozen onto the order at booking and read back by the engine, so a booking is serviced by the terms it was sold under and not by a later edit of the policy or a rename of the brand; an order booked before they were stored falls back to today’s policy and every quote and listing says so. Changeability is judged per direction, so a round trip sold Light out and Plus back is not refused on the strength of its outbound, and OrderRulesRS states each direction’s terms when they differ. An order holding an active, unused Flexibility service is changeable under that service’s terms whatever its fare says, and the service is consumed once. OrderRulesRQ answers a booked order (OrderStructureKey: its fare conditions, servicing fees, cutoffs and live eligibility) and a quoted fare before booking (FareRef, with the OfferID it was quoted in as FareRefText: the conditions its offer carries, the brand policy and the servicing terms per time-to-departure band). No Penalty states a fee for what the fare does not allow, and the machine channels refuse a change on a fare that is not changeable (fare_not_changeable). Fares are priced per offer, not filed: a fare basis alone is refused (missing_offer_id). STILL PARTIAL: (1) the platform holds no airport time zones — the only such data in the repo covers 62 of the 112 airports it sells and belongs to a storefront package — so departure times are read as UTC and every cutoff and band edge (72h / 24h) is out by the origin’s UTC offset, up to 13 hours; (2) the change fee the engine charges (25/50/75 by band) is not keyed by fare brand, so it is charged on Plus too, contradicting that brand’s published “Free changes” benefit — a data inconsistency between the catalogue and the rule table, not a mapping gap; (3) servicing fees are rule-table integers with no currency of their own and are charged as the same raw number in every currency, so 2500 is EUR 25.00 on one order and SEK 25.00 or JPY 2500 on another; (4) only CHANGES are judged per direction — a cancel’s refundability, and the conditions OrderRulesRS states for the order as a whole, still come from the outbound direction alone, so a round trip sold non-refundable out and refundable back is refunded as non-refundable. By design rather than a gap: the airline’s own staff are never refused by the fare. An agent may change a fare that forbids it, and the engine records the override on the quote and in the audit trail instead of turning the customer away; a customer’s Flexibility is spent only when the agent asks for it.

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

Search for flight offers across one or more origin-destination pairs.

When to use​

The first call in the shopping flow. Request offers by route, dates, passengers, and cabin/fare preferences; the airline responds with IATA_AirShoppingRS.

Transport​

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

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_AirShoppingRQ 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>
    <FlightRequest xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
      <AffinityShoppingCriteria>
        <AffinityOriginDest/>
      </AffinityShoppingCriteria>
    </FlightRequest>
  </Request>
</IATA_AirShoppingRQ>

Response example​

Paired response: IATA_AirShoppingRS.

<?xml version="1.0" encoding="UTF-8"?>
<IATA_AirShoppingRS 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_AirShoppingRS>

Key fields​

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

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

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

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