Routehappy FAQs

  • Does the new Routehappy API use XML or JSON?

    The new 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

  • Can I request UTAs and UPAs via the new 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 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. The new Routehappy API will also provide a new consolidated endpoint that offers enhanced functionality. While all users are encouraged to use the new consolidated 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 new Routehappy API without having to change the way they handle requests and responses.

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

    You can access the latest schemas for the new 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, segments, and legs are each ways of grouping the stops of a journey. Let's assume we have a round-trip journey from Los Angeles (LAX) to Boston (BOS) with a stop in New York (JFK). We represent this journey as LAX-JFK-BOS-LAX.

    • An itinerary represents a single journey, including all points of travel. In our round trip, the itinerary is LAX-JFK-BOS-LAX.
    • 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.
    • A leg is the smallest unit of a journey, the transportation between two consecutive scheduled stops on any given flight. Our round trip has three legs: LAX-JFK, JFK-BOS, and BOS-LAX.

    In short, an itinerary consists of one or more segments, and a segment consists of one or more legs.

    Visit the ATPCO Glossary for ATPCO's definitions of itinerary, segment, leg, and other terms.


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

  • How do I include more than one leg key in my request?

    You can include up to 150 leg keys in a single request. Leg keys in the request should be separated by commas.

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

  • Does ATPCO have Wi-Fi equipment data (e.g. Gogo ATG vs. Gogo 2Ku)?

    While we technically do collect this data, it is not currently formatted for production. If you would be interested in us formatting this data for consumption, please reach out to your ATPCO Sales Channel Retailing manager to let us know.

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


  • 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. This includes new Reassurance UPAs that provide important messaging and graphics to communicate the significant measures more than 130 airlines are taking to protect passengers during the COVID-19 pandemic. UPAs are targeted by aircraft, cabin, route, fare and more, giving flight shoppers relevant and useful merchandising content while they shop. UPAs are coming soon to the new Routehappy API.


  • 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 new 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 Consolidated Endpoint or the Backwards Compatible Hub Endpoint.

    • If you're calling the Consolidated 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