A recurring support conversation goes like this. Someone wants to show flight prices in their product — a budgeting tool, a relocation calculator, a corporate travel dashboard, a comparison widget on a content site. They look at Amadeus or Sabre, discover that the path runs through accreditation, contracts, certification environments, and a sales conversation, and ask whether there's something they can just call.
There is, and this post is about the line between the two. It is not a competitive comparison, because a fare search endpoint and a global distribution system are not the same category of thing. One shows you prices. The other sells tickets and settles the money. Confusing them wastes weeks.
The actual distinction: shopping vs transacting
Every flight commerce system does some subset of four jobs. Shopping is finding out what's available and what it costs. Booking is holding an itinerary and creating a passenger name record. Ticketing is issuing the ticket and moving money through the settlement system. Servicing is everything after — changes, cancellations, refunds, disruption rebooking.
A GDS does all four, plus the parts nobody mentions until you're in it: fare rules, ancillaries, seat maps, corporate negotiated fares, NDC content, queue management. That completeness is why the onboarding is heavy. You're being connected to airline inventory and to the money.
Our tickets endpoint does the first job only. It searches a city pair and returns priced itinerary options. It does not book, does not issue, does not hold inventory, and does not touch money.
If your product needs to sell a ticket, this post ends here and the answer is a GDS or a consolidator. If your product needs to show what flights cost, keep reading, because you probably don't need one.
What a fare search call gives you
One request, two required parameters:
import requests
BASE = "https://skylink-api.p.rapidapi.com"
H = {"X-RapidAPI-Key": KEY, "X-RapidAPI-Host": "skylink-api.p.rapidapi.com"}
r = requests.get(f"{BASE}/tickets/search", headers=H, params={
"origin": "LHR",
"destination": "JFK",
"date": "2026-05-01",
"passengers": 1,
})
data = r.json()
for f in data["flights"]:
legs = " -> ".join(l["departure_airport"] for l in f["legs"])
print(f"${f['price_usd']:>7.0f} {f['stops']} stop(s) "
f"{f['total_duration_min']}min {legs}->{f['legs'][-1]['arrival_airport']}")Results come back sorted cheapest first. Each itinerary carries a USD price, the original price and currency when the fare was quoted in something else, total duration, stop count, and a leg breakdown with flight numbers, airlines, airport names, and local departure and arrival times.
Two things to know before you build on it.
It takes IATA codes, not ICAO. LHR and JFK, not EGLL and KJFK. This is the opposite convention from most of the rest of the API, where positions and schedules work in ICAO, and it catches people. Resolve through airport search if you're holding ICAO codes.
Results are cached for an hour. That's what makes it cheap to call and it's also the constraint that defines what you may honestly do with the output. An hour-old fare is a good indication and is not a bookable guarantee. Label prices as indicative, and never render one as a firm quote a user could hold you to.
What you don't get, stated plainly
Since the whole value of this post is knowing where the edge is:
- No booking or ticketing. No PNR, no ticket numbers, no inventory hold.
- No fare rules. Change fees, refundability, and advance-purchase conditions are not returned. You cannot tell from this data whether a fare is refundable.
- No baggage or ancillaries. The price is the fare as quoted, not the total a passenger pays after bags and seats.
- No fare basis or booking classes. No RBD, no fare basis codes, so no way to reason about upgrade eligibility or corporate policy compliance at the class level.
- No negotiated or corporate fares. Those live in agreements between an agency and an airline and reach you through a GDS or NDC connection.
- No seat maps, no NDC content, no servicing.
If two or more of those are load-bearing for your product, you need the heavier integration. That's not a limitation we're apologising for — it's the trade that makes a single unauthenticated-shaped call possible at all.
What this is genuinely good for
Everything where the price is information rather than a transaction:
Content and comparison sites. "Flights from London to New York from $398" on a destination page. You need a credible current number, not inventory.
Budgeting and planning tools. Relocation calculators, conference cost estimators, travel budget apps. The user wants to know roughly what a trip costs.
Corporate travel dashboards. Showing what a route typically costs so a manager can sanity-check a submitted expense or a proposed trip, with booking happening through the company's existing agency.
Route economics and research. Tracking fare levels on a city pair over time, which is a different question from tracking capacity — that one is covered in aviation data for financial markets.
Prototypes. Validating that people want your travel product before committing to GDS onboarding. This is a big one. Accreditation is a serious commitment, and finding out first whether anyone clicks is worth doing cheaply.
The common thread: nobody's card is being charged as a result of what the API returned.
When you actually need Amadeus or Sabre
Be honest with yourself early, because migrating later is expensive.
You need a GDS or a consolidator if you are selling tickets, if you need to service bookings after the sale, if you need fare rules to enforce a corporate travel policy, if you need corporate negotiated rates, or if you need guaranteed real-time availability rather than an indicative price.
Between the two extremes sit the aggregators and booking APIs — Duffel, Kiwi, Travelport and others — which wrap some of the GDS complexity behind a more modern interface and lighter commercial terms. If you need to transact but the full GDS route is too heavy, that middle tier is usually where the answer is, and it's worth pricing before assuming Amadeus is the only option.
A pattern that works well
Fare search pairs naturally with the operational endpoints, and the combination is more useful than either alone.
Use tickets for what a route costs. Use schedules for what actually operates and how often. Use flight status for whether today's flights are running to plan. A route page carrying price, frequency, and reliability answers more of a traveller's question than a price alone, and none of it requires accreditation.
# Same route, three questions
fares = requests.get(f"{BASE}/tickets/search", headers=H,
params={"origin": "LHR", "destination": "JFK"}).json()
cheapest = min(f["price_usd"] for f in fares["flights"])
deps = requests.get(f"{BASE}/schedules/departures", headers=H,
params={"icao": "EGLL"}).json()
to_jfk = [d for d in deps.get("data", []) if d.get("arrival_icao") == "KJFK"]
print(f"LHR-JFK from ${cheapest:.0f}, {len(to_jfk)} departures in this window")Note the code convention switch in that snippet — IATA for the fare search, ICAO for the schedule lookup. It's the single most common bug in this integration.
Getting started
The tickets endpoint is available from the free trial up, and because results are cached hourly, a modest quota covers a lot of route pages if you cache on your side too.
If it turns out you do need to transact, nothing here is wasted — the shopping layer you built is the part you keep, and you swap the price source when you take on the heavier integration.