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:

• 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
            }
          ]
        }
      ]
    }
  }
}