UTAs

The Hub Backwards Compatible (UTAs and UPAs) endpoint is intended for users of the legacy Routehappy Hub API who are not yet prepared to migrate to the upcoming Routehappy API endpoint.

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.

The Hub Backwards Compatible (UTAs and UPAs) endpoint of the Routehappy API maintains the functionality of the legacy Routehappy Hub API while improving response speed. Users of the legacy Routehappy Hub API will be able to use the same request structure and can expect the same response structure from this newer, faster API.

UTA Category Definitions

1. Advance change policy – Does the fare allow a change to the flight itinerary? If so, are there any fees associated with this change?
2. Cancellation policy – Does the fare allow complete cancellation of the flight? If so, are there any fees associated with a cancellation?
3. Carry-on baggage allowance – Does the fare include carry-on baggage? If so, are there any fees associated with carry-on baggage?
4. Checked baggage allowance – Does the fare include any checked baggage? If so, are there any fees associated with checked baggage?
5. Same-day change – Does the fare allow a change to the flight itinerary within 24 hours of flight departure time? If so, are there any fees that would apply to this change?
6. Seat selection – Does the fare include the ability to choose a particular seat ahead of check-in? If so, are there any fees associated with selecting seats?
7. Check-in priority – Does the fare include a higher or lower check-in priority compared to a standard fare?
8. Boarding priority - Does the fare include a higher or lower boarding priority compared to a standard fare?
9. Upgrade eligibility – Does the fare include the ability to request an upgraded cabin selection?
10. Lounge access – Does the fare include access to a lounge? If so, is there a fee associated with this access?

Data Hierarchy

Advance change and Cancellation data in both the Routehappy API and Hub Backwards Compatible endpoints is sourced from Fare Rules. Fare Rules provides the most granular form of the data, which will be returned as a “policy” (e.g. “change_policy” or “cancel_policy”).

Carry-on baggage allowance and Checked baggage allowance data in both the Routehappy API and Hub Backwards Compatible endpoints are sourced from Optional Services.

For the remaining 6 categories, Same-day change, Seat selection, Check-in priority, Boarding priority, Upgrade eligibility, Lounge access, data will be sourced from Branded Fares for airlines who file these categories. Airlines are not required to file data across all categories, so coverage will vary by category by airline. For a full breakdown of UTA coverage by category and airline, please see our Coverage page. Additionally, Airlines can restrict who they share their data with by electing to only share with Channels using certain fare sources. For instance, an airline may choose to only share data if a Channel’s indicated fare source is Sabre rather than Amadeus or Worldspan. If the Coverage page shows that data are available for an airline, but you are unable to access data for that Airline, please submit a support ticket so we can help you resolve the issue.

Cancellation and Change precedence

The leg type structure part of the response is responsible for displaying what cancellation and advance change policies have been matched for this leg. A request may be composed of one fare across all segments or multiple fares from more than one segment.

When there are segments in a leg which are having different fares, then the leg object will get displayed as containing all matched fare IDs in the leg_fares field list. However, then the policies for this leg would be having precedence. This means that from all the fares that we've matched, in the cancellation_policy and change_policy we'll output only the most restrictive policies from both fares.

Precedence (priority is as listed)

1. Policy with assessment code Restriction or also known as R
2. Policy with higher fee (when possible for a fee)
3. Whichever policy was matched first

All other policies would still be displayed in the overall response, however they won't be directly referenced unless matching the above precedence. In case you still need to reach them, you'll need to parse the fare ID in order to match them.

Example:

Let's say we have two segments with two different fares:

• LAX-BOS with fare basis code ABCDEFGH which has fully refundable cancellation policy and change is not permitted.
• BOS-LHR with fare basis code IJKLMNOP which has non-refundable cancellation policy but change is allowed.

A similar output would be expected (note that irrelevant data is stripped):

{
	"data": {
		"id": "ab74b04c-617c-490e-9c73-e46582430a50",
		"relationships": {
			"legs": {
				"data": [
					{
						"id": "1",
						"meta": {
							"index": 0
						},
						"type": "leg"
					}
				]
			}
		},
		"type": "legs_search"
	},
	"included": [
		{
			"id": "1|711756",
			"type": "fare"
		},
		{
			"id": "1|711756",
			"relationships": {
				"fare": {
					"data": {
						"id": "1|711756",
						"type": "fare"
					}
				},
				"leg_fare_segments": {}
			},
			"type": "leg_fare"
		},
		{
			"id": "1|13457581",
			"type": "fare"
		},
		{
			"id": "1|13457581",
			"relationships": {
				"fare": {
					"data": {
						"id": "1|13457581",
						"type": "fare"
					}
				},
				"leg_fare_segments": {}
			},
			"type": "leg_fare"
		},
		{
			"id": "1",
			"relationships": {
				"cancellation_policy": {
					"data": {
						"id": "711472",
						"type": "cancellation_policy"
					}
				},
				"change_policy": {
					"data": {
						"id": "13471274",
						"type": "change_policy"
					}
				},
				"leg_fares": {
					"data": [
						{
							"id": "1|13471274",
							"type": "leg_fare"
						},
						{
							"id": "1|711472",
							"type": "leg_fare"
						}
					]
				}
			},
			"type": "leg"
		},
		{
			"attributes": {
				"assessment_code": "R",
				"description": "Non-refundable",
				"headline": "Non-refundable"
			},
			"id": "711472",
			"type": "cancellation_policy"
		},
		{
			"attributes": {
				"assessment_code": "B",
				"description": "Fully refundable ticket",
				"headline": "Full refund"
			},
			"id": "13471274",
			"type": "cancellation_policy"
		},
		{
			"attributes": {
				"assessment_code": "R",
				"description": "Change is not allowed",
				"headline": "Not Allowed"
			},
			"id": "13471274",
			"type": "change_policy"
		},
		{
			"attributes": {
				"assessment_code": "B",
				"description": "Change allowed for free",
				"headline": "Free"
			},
			"id": "711472",
			"type": "change_policy"
		}
	],
	"meta": {
		"not_matched_leg_indexes": []
	}
}

UTA Data Accuracy

UTAs return the most currently available data the airlines have provided to ATPCO. Any change an airline makes to their ATPCO fare filings should be reflected in UTA data within an hour of being updated.

Icons

Icons are generic and included in each UTA as a pointer URL. Partner can choose whether or not to utilize them for display.

Language Translation

The Routehappy UTA API display text is available for the following languages/regions.

Units of Measurement

Measurement is dictated by the language/localization indicated. For the U.S. English, all measurements follow the United States customary system (USCS) for units of measurement. For all other languages/localizations, measurements are provided in metric units.