Shop: Seat Options [SHPSTO]

Guidance for Schema Version:

21.3

Definition of Capability

Airline

Return seat maps, including:

  • seat type (exit row, upper deck, etc.) and/or

  • for a specified flight or route & cabin and/or

  • referring to an existing offer or order identifier (if applicable) for existing flight & ancillary offer

Seller

Request and display seat maps, including:

  • seat type (exit row, upper deck, etc.) and/or

  • for a specified flight or route & cabin and/or

  • referring to an existing offer or order identifier (if applicable) for existing flight & ancillary offers

NOTE: System Providers will use the above definition that pertains to their customers for Capabilities Verification.

Links to EASD Implementation Guidance

Related Concepts, Capabilities and Worked Examples:

NOTE: Retailing Capabilities Verification Guidance will align to the published EASD Implementation Guidance at all times. From time to time when new guidance is published this will be updated and supersede any Retailing Capabilities Verification Guidance listed below.

Retailing Capabilities Verification Guidance

For all capabilities, please also consult the list of general guidelines for adherence to best practices that span across several capabilities and messages: https://standards.atlassian.net/wiki/spaces/ARMI/pages/584318980/General+Guidance

The SeatAvailabilityRQ/RS message pair allows Airlines to send three different layers of seat-related information to the Seller - layout of seats in cabins, availability of seats, and price points for individual or groups of seats.

At the most basic level, the SeatAvailabilityRS message carries details of how the cabin is configured. In addition to the location of seats, other components of a cabin (e.g. lavatories, emergency exits, snack bars, etc.) can also be included, with their positions relative to the rows and columns typically associated with seat assignments. This allows the Seller to graphically render the layout of the cabin on their front-ends with a level of detail comparable to current booking platforms seen today.

Typically, the purpose of SeatAvailabilityRQ/RS is to allow the passenger make an informed decision on which seat to select and to be presented with differences in prices in terms of seat upgrades or seats of differing characteristics (e.g. extra leg room). However, in the case of this particular capability, the Airline can choose to implement only the details of the components of one or multiple cabins (i.e. without showing availability or pricing yet).

Airline

The SeatAvailabilityRQ message supports the following three ways of requesting seat maps. At least one must be supported by an Airline. If no CabinCode is provided in the Request (or no CabinCode is present in the context of the existing Offer/OfferItem or Order), the Airline is expected to return all cabin types for a given flight:

In the SeatAvailabilityRS, Airlines are expected to return seat layout information for at least one cabin for a specific flight segment or operating leg:

Optionally, characteristics of individual seats or entire rows of seats:

Minimum Requirements

SeatAvailabilityRQ/SeatAvailabilityRS

Seller

The Seller is expected to query the Airline for seat maps using at least one of the three available options listed above. In addition, screenshots will need to be provided of the travel platform showing the extent to which the seat map details are consumed and rendered for the end user.

Minimum Requirements

User Interface Screenshots

SeatAvailabilityRQ/SeatAvailabilityRS

NOTE: For all versions prior to that listed above (generally the most recent), the verification will be based on the guidance available for that version. In the case that no guidance is available, verification will be at IATA’s discretion.