Routehappy FAQs

• Does the Routehappy API use XML or JSON?

  The Routehappy API conforms to the JSON (JavaScript Object Notation) API specification which specifies how a client
  should request data and how a server should respond to those requests. This specification was designed to be readable,
  flexible and efficient. For more detailed information on the JSON API specification, please go
  to www.jsonapi.org.

• Can I request UTAs and UPAs via the Routehappy API?

  Currently, you can request UPAs mapped to cabin without any brand information via the Hub Backwards Compatible
  endpoint. We are actively expanding that endpoint to add the full UPAs and UTAs functionality found in the legacy Hub
  API.

• What is the maximum amount of itineraries that can be sent to the Routehappy API?

  An API request should have a maximum of 150 itineraries for our SLA commitments to be in place. Each itinerary should
  have up to 12 segments. There should be least 1 itinerary with at least 1 segment in an API request to be executed
  successfully.

• What does Amenities or Hub "Backwards Compatible" endpoint mean?

  The Amenities "Backwards Compatible" and Hub "Backwards Compatible" endpoints provide the same request and response
  structures as the legacy Routehappy Scores and Amenities (S&A) and Hub APIs, respectively. This is for users of the
  legacy Routehappy S&A and/or Hub APIs. We now also provide a new Routehappy API endpoint that offers enhanced
  functionality. While all users are encouraged to use the new Routehappy API endpoint, some users may not be ready to
  migrate their systems to use the new consolidated Routehappy endpoint. The "Backwards Compatible" endpoints allow
  those users to reap the performance benefits of the Routehappy API without having to change the way they handle
  requests and responses.

• Where can I find the latest schemas for the Routehappy API endpoints?

  You can access the latest schemas for the Routehappy API endpoints by clicking the following links:

Attention

The table below contains the URLs for the UPA Staging, Gold and Production environments of the Routehappy API endpoint's and schemas, respectively.

* DS - Data Source within ATPCO from which the system is processing the data it displays.

• What does the uuid field in the response represent?

  UUID stands for Universally Unique Identifier and is an attribute commonly used across APIs to make each request
  unique in order to distinguish between them easily. UUID serves as a helper between a request and response by
  connecting them, and allows for tracing issues that arise for specific requests within a system. The UUID is
  autogenerated on the API's side.

• What's the difference between itineraries, segments, and legs?

  Itineraries, legs, and segments are hierarchical groupings. Let's assume we have a round-trip
  itinerary from Los Angeles (LAX) to Boston (BOS) with a stop in New York (JFK). We represent this itinerary as
  LAX-JFK-BOS-LAX.

  • An itinerary represents the whole trip with all the outbound and inbound legs that you have, including all points
    of travel. In our round trip, the itinerary is LAX-JFK-BOS-LAX.
  • A leg is the part of itinerary that contains segments in specific direction (outbound/inbound), the transportation
    before and after the point of turnaround which in our case is JFK-BOS, as well as all the
    different fare break points. Our round trip has two legs, one fare each without stopovers: LAX-JFK (outbound) and
    JFK-BOS-LAX (inbound).
  • A segment represents the portion of the journey that is covered by a single ticket/flight coupon. Our round trip
    has two segments: LAX-JFK-BOS and BOS-LAX.

  In short, an itinerary consists of one or more legs, a leg consists of one or more fares and a fare consists of one or
  more segments.
  
  
  
  Visit the ATPCO Glossary for ATPCO's definitions of
  itinerary, segment,
  leg, and other terms.

Amenities

• What are "Amenities?"

  Amenities provide content that describes key aspects of the onboard flight experience, offering consumers targeted
  information while they are shopping for flights. Amenities data is matched to the global flight schedule, covering
  virtually every flight by cabin for approximately 500 airlines and nearly 100% of all flights worldwide and are
  translated into more than 25 languages.

• Does Amenities data cover 100% of an airline’s flight schedule?

  Amenities data covers virtually every flight by cabin for approximately 500 airlines and nearly 100% of flights
  worldwide. There may be rare cases when there’s a new subfleet that we’ve yet to research.

• Can I access Amenities via a flat file solution rather than by hitting the API?

  The vast majority of our partners access Amenities data via our APIs. There is a flat file solution available for
  Amenities; however, there may be commercial implications associated with getting access. Please contact your ATPCO
  Sales Channel Retailing manager for more information.

• What’s the difference between Routehappy Fresh Foods Amenity category and the information about meals that’s returned from OAG?

  The data from OAG includes only generic meal code information. Please see all information that’s included in Fresh
  Foods Amenity responses.

• Do you support Amenities at the RBD or FBC level?

  Our experience thus far has shown that 99% of the time Amenities are based on the cabin, and not the fare brand.
  However, we are starting to see a few cases of Amenities by RBD, so the team is researching whether this is something
  we’ll need to support in the future, as we continue to evolve and improve our data.

UPAs

• What are "UPAs?"

  UPAs (Universal Product Attributes) bring unique airline fares, products and services to life with messaging, images,
  videos and cabin tours. UPA content can be highly targeted by aircraft, cabin, route, fare, and more, giving travel
  agents and customers time sensitive and relevant content as they shop.

UTAs

• What are "UTAs?"

  UTAs (Universal Ticket Attributes) are benefits and restrictions by fare, in plain, simple language that make it easy
  for travel agents and customers to understand. UTAs are sourced from airline ATPCO fare, branded fare and optional
  service filings and then processed into clear and concise merchandising content. UTAs are coming soon to the
  Routehappy API.

• What happens if I do not include Fare Source in my request?

  When airlines file their fare information with ATPCO, they also indicate which Fare Sources should have access to the
  content. If you do not indicate which Fare Source you have shopped a given fare from, we are only able to return data
  that airlines have marked as having no Fare Source restrictions. We strongly recommend that you indicate Fare Source
  in all UTA requests.

• Can I request branded fare name ONLY (without requesting all UTA content for those brands) by including ONLY legs.leg_fares.fare in the include portion of the request?

  No. Requesting ONLY legs.leg_fares.fare in the include will not return useful data. In order to get branded fare
  name, you need to also include legs.leg_fares.utas, though this will of course return all branded fare UTA data as
  well.

• What happens if I do not include fare basis code (FBC) in my request?

  Depends on whether you are calling the Routehappy API Endpoint or the Backwards Compatible Hub Endpoint.

  • If you're calling the Routehappy API Endpoint without FBC in your request, nothing fare-related will be returned.
    You can still get UPAs and Amenities in the response. However, you may not get all UPAs - those that are realated
    to a specific brand or optional service may not be returned.

  • If you're calling the Backwards Compatible Hub endpoint without FBC in your request, no data will be returned for
    legs.change_policy, legs.cancellation_policy, legs.leg_fares.utas, and legs.leg_fares.fare.

• I’ve included Fare Source and FBC in my request, but I am still not getting data back for legs.change_policy, or legs.cancellation_policy. Why?

  It is possible that we are unable to match the FBC to the appropriate fare on our side. Our ability to map FBC 1:1
  with a fare varies based on whether the fare in question is a Public Fare, Private Fare, or Fare by Rule. We have by
  far the most coverage for Public Fares, but coverage for Private Fares and Fare by Rule may be limited.

• Why am I seeing “not_matched_leg_indexes” at the beginning of every API response?

  This meta field will appear at the beginning of every API response, but will remain empty as long as all segment or
  leg keys provided in your request were able to be matched in the OAG flight schedule. If there are keys listed in
  this field, please check those keys to ensure that they have been entered correctly.

• What are the ID numbers that are included in API responses? Does each possible UTA response have an ID associated with it?

  These ID numbers are generated dynamically by the API as the response is sent. We do not recommend that you map IDs
  to UTA responses, since the IDs are dynamic and are subject to change.

• How many Threads Per Second (TPS) are supported?

  There is no limit on TPS.

• What is the “assessment” field used for in a UTA response? What does it mean when I get “assessment”: “neutral” returned for a particular UTA?

  Some partners choose to display UTA data on their site as a comparison grid. For instance, a partner may place a
  green checkmark next to all of the UTAs that are returned with “assessment”: “benefit” and place a red “X” next to
  UTAs returned with “assessment”: “restriction”. UTAs returned with “assessment”: “neutral” are not inherently
  positive or negative and therefore simply do not map cleanly to either a benefit or a restriction.

• Where in ATPCO does the data for change_policy and cancellation_policy come from?

  The data is extracted from Fare Rules CAT16 & CAT31.

• What’s the syntax for including multiple segment keys within one UTA Request body?

  Below is an example body with 2 segments:

{
  "data": {
    "type": "legs_search",
    "fare_source": "1S",
    "attributes": {
      "legs": [
        {
          "segments": [
            {
              "dep": "VRN",
              "arr": "AMS",
              "carrier": "HV",
              "flt_no": "5468",
              "dep_date": "2019-07-14",
              "cabin_id": 1
            }
          ]
        },
        {
          "segments": [
            {
              "dep": "VRN",
              "arr": "AMS",
              "carrier": "HV",
              "flt_no": "5468",
              "dep_date": "2019-07-21",
              "cabin_id": 1
            }
          ]
        }
      ]
    }
  }
}