There are two versions of our API, both using the IATA 17.2 standard.
V1 is based on Fare Families, an old concept used by our web whereby fares a grouped together in “Families” based on common criteria, such as changeability, refundability, etc….
V2 is based on Branded Fares, an industry standard way for airlines to clearly identify the Features and Attributes of different fare products.
We recommend that V2 is used from now on. We will continue to support V1 with bug fixes and new functionality when and where possible.
Please note that some functionalities and come message elements will only be released in V2. For example the BaggageAllowanceList, PenaltyList , together with various parts of the FareComponent are only included in V2.
The differences between V1 and V2 are highlighted in the tables that explain the message elements, and are identified as per the following legend:
|
Both versions include Fare/Product information in the PriceClassList section of the AirShoppingRS and OfferPriceRS messages.
The big difference is that the V1 information is free text maintained in an external database, whereas the V2 information is loaded in the Fares Distribution System (ATPCo) and is standard. This is clearly seen in the following examples:
V1 Fare Families | V2 Branded Fares | ||
|---|---|---|---|
|
|
Branded Fares are an industry standard way for airlines to clearly identify the Features and Attributes available as part of a fare product, some of which may be included in the price, and others that may be purchasable for an additional fee. It is also an industry wide solution, that allows Fares/Brands with similar features and attributes to be grouped together for comparison.
This allows us to promote Features and Attributes that differentiate one fare product from another, and gives travellers the opportunity to select the product that best fits their preferences and the purpose of their journey.
We use the the ATPCo Optional Services Industry Sub Codes, together with Iberia specific ones, to be able to offer products in a more structured and informative way.
This list of Attributes is dynamic and can and will change and grow over time, and includes things such as:
PREMIUM SEAT
BASIC SEAT
PRIORITY BOARDING
PRIORITY SECURITY
PRIORITY CHECK IN
The Branded Fares Fields that we return group each Brand/Product by a PriceClassID, this information is returned in the PriceClassList, and which represents the following elements:
ObjectKey - unique reference for internal Iberia use.
programCode - The owner airline CFF** (** = airline owner)
programText
The following two elements identify the Branded Fare/Product
brandText: The commercial name of the product (ie BUSINESS FLEXIBLE, or Basic, etc…) to be displayed to the customer.
brandCode: The code associated to the brandText - (BUSFLEX) - used to identify the product
The following are used to identify and group together the various Features and Attributes of the Product:
attributeGroup - The top level of grouping, such as Baggage, Meals, Frequent Flyer, In-flight Entertainment, etc., that uses the ATPCo Optional Services Industry Sub Codes “Group”.
attributeSubGroup - The second level of grouping, to group attributes within an attributeGroup, such as Sporting Equipment or Speciality Items within Baggage, using the ATPCo Optional Services Industry Sub Codes “Sub Group”.
Subcode - This is the industry, or airline specific, “Sub Code” used to identify each individual attribute (such as specific seat type, first bag, first bag at 15kg, etc) and may be taken from the ATPCo Optional Services Industry Sub Codes.
Description1 - description of subcode if applicable, to be displayed to the customer.
Description2 - additional description of subcode if applicable, to be displayed to the customer.
ComercialName - This is applicable to the Subcode if it has a specific name/identity, and should be displayed to the customer.
tierApplication - Describes whether the attribute is:
Free
Chargeable
Displayed but not offered (such as priority bags delivery on all fares except business) (can be used to compare products)
Not offered attribute that is not applicable to product, (ie. seating is not offered of products that include seats at sale).
Example 1:
<Description ObjectKey="CFFIB210210COMFORT0LF">
<Text>TS/PY/0LF///PRIORITY BAGGAGE/DISPLAYED-BUT-NOT-OFFERED</Text>
</Description> |
The above example is for:
TS - is the attributeGroup, which as per the ATPCo Optional Services Industry Sub Codes is “Travel Services”
PY - is the attributeSubGroup, which as per the ATPCo Optional Services Industry Sub Codes is “Priority Baggage”
0LF - is the RFISC (Reason for Issuance Sub Code) used to identify the individual attribute. If the service required the issue of an EMD this would be used for its issue.
Both Description1 and Description2 are empty
PRIORITY BAGGAG - is the ComercialName as per the ATPCo Optional Services Industry Sub Codes
DISPLAYED-BUT-NOT-OFFERED - is the tierApplication. In this case the feature could be diplayed greyed out as it is not offered with this product.
Example 2:
<Description ObjectKey="CFFIB210210NOBAGIC3">
<Text>ML//IC3///SNACK OR DRINK/CHARGE</Text>
</Description> |
The above example is for:
ML - is the attributeGroup, which as per the ATPCo Optional Services Industry Sub Codes is “Meal”
There is no attributeSubGroup for this feature.
IC3- is the RFISC (Reason for Issuance Sub Code) used to identify the individual attribute. If the service required the issue of an EMD this would be used for its issue. In this case the RFISC is specific to Iberia.
Both Description1 and Description2 are empty in this example.
SNACK OR DRINK - is the ComercialName given by Iberia to this feature.
CHARGE - is the tierApplication. In this case the feature is purchasable for a fee. As the service is not in our ServiceList API this is only purchasable at place of delivery.
In the following pages you have all the messages with the functionality our API supports with the message structure.
There are many examples with full end to end message flows that will help you. Messages for the same Order must be processed sequentially, the next message should not be sent until after receipt of the response to the previous message.
3-D Secure payment is being mandated in many markets and is ONLY supported in our 17.2 version using an augmentation point.
