Skip to main content

IATA_OrderRulesRQ

Request · Order Management · Partial

Partially implemented

Delivers: SHPOR1 Offer conditions and restrictions (partial).

Limits today:

  • 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.

Request the fare, penalty, and change rules applicable to an order or offer.

When to use​

To surface change/cancel/refund conditions to the customer or agent.

Transport​

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

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_OrderRulesRQ 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>
    <RulesCoreRequest xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
      <FareRef>
        <AirlineDesigCode>X</AirlineDesigCode>
        <Arrival>
          <IATA_LocationCode>XXX</IATA_LocationCode>
        </Arrival>
        <Dep>
          <IATA_LocationCode>XXX</IATA_LocationCode>
        </Dep>
        <FareBasisCode>X</FareBasisCode>
      </FareRef>
    </RulesCoreRequest>
  </Request>
</IATA_OrderRulesRQ>

Response example​

Paired response: IATA_OrderRulesRS.

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

Key fields​

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

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

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

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