Core concepts

Every NDC 24.4 message shares the same envelope, namespaces, and extension mechanism. Understanding them once makes all 48 messages read the same way.

The message envelope

A message root (e.g. IATA_AirShoppingRQ) wraps a small set of standard top-level sections:

Section	Purpose
PayloadAttributes	Message metadata — version, correlation, timestamps.
DistributionChain	The participants in the transaction and their roles (see below).
POS	Point of sale — country, agency, channel context.
Request / Response	The message-specific body (shopping criteria, order content, results…).
AugmentationPoint	The standard extension point (see below).
Signature	Optional W3C XML Digital Signature (xmldsig).

Each reference page lists the top-level fields for that specific message, derived directly from the XSD.

The four namespaces

NDC 24.4 messages use qualified element names across four namespaces. With elementFormDefault="qualified", every element is namespace-qualified, which is why nested elements re-declare a default namespace in the examples.

Prefix (conceptual)	Namespace URI	Used for
message	http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersMessage	Message roots.
common	http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes	Shared data types.
paymentClearance	http://www.iata.org/IATA/2015/00/2022.1/	The Payment Clearance family.
dsig	http://www.w3.org/2000/09/xmldsig#	XML Digital Signature.

The DistributionChain

NDC models a transaction as a chain of participants, each with an OrgRole. The common roles:

• Seller — the agency / OTA / retailer initiating the request.
• Aggregator — an intermediary or aggregator in the path (optional).
• Carrier — the airline (offer/order owner).

Each DistributionChainLink carries an Ordinal (its position in the chain), the OrgRole, and the participating organization's id. The Postman environment exposes these as {{sellerId}}, {{aggregatorId}}, and {{carrierCode}} so you fill them once.

Shopping with this airline

What an AirShoppingRQ gets back, and where each part comes from:

• Origin-destinations. One OriginDestCriteria is a one-way; a second one that returns to the start is priced as one round trip (one offer covering both journeys). Anything else — multi-city, open jaw — is shopped per origin-destination: you get offers per OD and combine one per OD when you order.
• Segments. Each flight is described three ways, as 24.4 intends: PaxSegment (cabin) → DatedMarketingSegment (the flight number sold, e.g. RT 5456) → DatedOperatingSegment (who flies it — e.g. British Airways on a codeshare, Eurostar on a rail leg) → DatedOperatingLeg (equipment; a train is TRN, with station names).
• Fare brands. Every flight comes in the airline's brands (Light / Standard / Plus) as separate offers. Each brand is a PriceClass with its name and benefits, and the offer's JourneyOverview and fare components point to it.
• Baggage allowance. Where the airline has set a brand's included bags, the offer carries them as BaggageAllowance (TypeCode Checked / Carry on, PieceAllowance and WeightAllowance/MaximumWeightMeasure — the most one bag may weigh, in KGM, sent only beside a piece count) and one BaggageAssociations per allowance, on the offer's journeys, for the adults and children. A brand whose allowance is not set sends none — read nothing into its absence, and never read an allowance out of the PriceClass benefit text. The same allowance comes back in OfferPriceRS and, once booked, in OrderViewRS (a service per passenger and segment naming it, and on each e-ticket coupon).
• Services with the offers. Add OfferCriteria/ServiceCriteria to ask for the airline's à-la-carte services at shop time: beside each offer comes its ALaCarteOffer (OfferID = the offer's id + -ALC) with the airline's own services exactly as ServiceListRQ lists them — same ids, orderable the same way in OfferPriceRQ / OrderCreateRQ. Ground transport and partner products are not included: ask ServiceListRQ for them. RFIC, RFISC and TaxonomyCode narrow the list (a parent taxonomy node includes the nodes below it). Services are listed for the first offers of the response only, and an offer whose services cannot be read comes back without them — a Warning says so: services_limited, services_unavailable (temporary) or services_refused (not temporary); ask ServiceListRQ for those.
• Excluding services. A ServiceCriteria with IncludeInd false removes the offers whose fare brand includes that service, and leaves it out of the à-la-carte list. The airline can judge this only for the bags a brand includes as data (a checked bag); other content a brand bundles is described only in its benefit text and is not filtered — every such response carries the service_criteria_partly_applied Warning.
• Conditions. Each fare-brand offer states its brand's conditions on its offer item (ChangeRestrictions / CancelRestrictions): whether it can be changed and whether it is refundable — the airline's own brand policy, the same terms it applies once the order is booked (a fare that is not changeable cannot be reshopped: fare_not_changeable). Change and cancellation fees and cutoffs depend on the time left before departure, so they are not on the offer: before booking, OrderRulesRQ with a FareRef answers a quoted fare's full rules. Send this airline's code, the OfferID the fare was quoted in as FareRefText, and its FareBasisCode with the Dep / Arrival of its outbound journey. The answer repeats the conditions the offer carries and adds the servicing terms per time-to-departure band (one Penalty per band and kind, in the order's currency); no Penalty states a fee for something the fare does not allow. Fares are priced per offer, not filed, so a fare basis alone names no fare. If the brand policy could not be read when an offer was priced, the offer carries the supplier's conditions and the fare_conditions_supplier warning says so.
• Language. Ask for a language with ResponseParameters/LangUsage/LangCode (or PayloadAttributes/PrimaryLangID), e.g. sv. The airline's content — fare-brand names and benefits, station, cabin, service and partner-product names, seat descriptions, promotion names, picture captions — comes back in it wherever the airline has translated it, and in English where it has not: Processing/LangUsage lists the languages the content is in (never one it is not in), and a content_language_fallback warning names what stayed English. The same applies to booked orders. Text the gateway composes (penalty, rule, ride and allowance descriptions, warnings, errors) is English; carrier, operator and aircraft names are proper names.
• Prices. TotalPrice is the airline's price: BaseAmount (the fare — the price point), any Discount (with the pre-discount amount and what it was), any Surcharge (one Breakdown line per surcharge, named, and its TotalAmount), fees, and TotalAmount. Each OfferItem/Price carries the same parts for that item. Taxes are not itemised yet — the offer engine carries tax as zero, so no TaxSummary is sent; TotalAmount is what you are charged. Prices are in your CurParameter currency when you send one.
• Price adjustments. The airline's NDC pricing rules adjust its fares automatically, on every shop: discounts down and surcharges up, by dates, route, cabin, fare brand, passenger type (your PTC, with ages) and the personalisation below. What applied is itemised as above and recorded on the order (OrderViewRS states the same breakdown). If the rules cannot be applied at that moment you get the unadjusted fares and a price_adjustments_unavailable Warning. A fixed amount the airline defined in another currency than your offers is not applied (never converted) — price_adjustment_currency_not_applied says so. Re-shopping a booked order (OrderReshopRQ) prices alternatives without these adjustments.
• Personalised prices. Send this airline's LoyaltyProgramAccount/AccountNumber on every fare-paying passenger, with the traveller's Individual/GivenName and Surname as the account holder's: the airline checks each account against its holder and looks up the tier itself (you never send a tier). Member prices apply only when all of them check out — otherwise the whole party is priced as travellers without accounts and member_pricing_not_applied says so (an unknown number is treated exactly like a wrong name). With member_pricing_applied, book the offer with the same accounts on the same travellers: OrderCreateRQ otherwise fails with member_pricing_not_eligible (753) and nothing is charged. Agreements are priced for you, the authenticated seller — never for a seller named in the payload — and, when your agreement covers a negotiated programme (for example a corporate contract), send its OfferCriteria/ProgramCriteria with ProgramOwner/Carrier = this airline and ProgamContract/ContractID (the schema's spelling). Other ProgramCriteria, and any ProgramAccount, are not applied and say so in a Warning. An offer priced for you can be booked by you only: another seller's OrderCreateRQ for it gets offer_not_found.
• Promotions. Send a code in OfferCriteria/PromotionCriteria/PromotionID. The airline validates and prices it; an applied code appears as Promotion and as the offers' Discount. A code that is invalid or does not apply is a Warning — the offers come back without it, never as an error.
• Pictures. Offers to destinations with airline imagery carry it as the offer item's RichMedia.
• Expiry. OfferExpirationTimeLimitDateTime — re-price (OfferPriceRQ) or re-shop after it.

AugmentationPoint — the extension mechanism

Most complex types carry an AugmentationPoint (an xs:any slot). It lets a participant add bilaterally-agreed data without breaking schema validity. It is always optional; the generated examples omit it. If you don't have a bilateral agreement that defines augmentation content, leave it out.

Correlation & idempotency

Use PayloadAttributes correlation identifiers to tie a response back to its request and to make retries safe. Treat order-mutating requests (OrderCreateRQ, OrderChangeRQ) as idempotent on your correlation id — a retry with the same id must not create a second order. See Authentication & connection for transport-level detail.

Versioning

This documentation covers NDC 24.4. The Payment Clearance family sits in the IATA 2022.1 namespace (above) but ships as part of the same 24.4 message set. The site is versioned: today there is a single published version, 24.4. When a future schema set lands, a new version is snapshotted and selectable from the version dropdown — existing 24.4 links keep working.