Flight Aggregator API: Search Multiple Providers in One Call

A flight aggregator API fans out one search to multiple providers and returns comparable fares in a single response. You do not call five endpoints, normalise five schemas, and merge five result sets. You call one.

This page is the Ktemia contract for that job. POST /v1/flights takes origin, destination, and a depart date. It searches across airlines, OTAs, and metasearch sources. The response includes fares from each provider, carrier names, stops, durations, and booking URLs — ready to rank. One POST, many sources.

Key Takeaways

• A flight aggregator API searches many providers in one call. You send origin, destination, depart. You get fares from across the market.
• Ktemia returns provider names and booking URLs for every fare. You see where the price comes from.
• Required fields: origin, destination, depart date. If any is missing, the call rejects. The copilot asks. Neither guesses.
• Free: 50 API requests a month, $0. Pro: 20,000/month at 20 per second, $29.99. Business: 250,000/month at 250 per second, $299.

What is a flight aggregator API?

A flight aggregator API is a single endpoint that queries multiple flight sources — airline direct channels, online travel agencies (Expedia, Booking.com), and metasearch engines — and returns normalised fares you can compare. The aggregation is the product. You do not manage provider credentials, rate limits, or response schemas for each source.

The aggregation job is distinct from three things it gets confused with:

Aggregator

One call, many providers. Normalised fares out. No ticket.

Single-source search

One provider. One schema. Narrower coverage.

GDS / NDC

Airline inventory pipe. Enterprise gate. Booking capable.

Most teams typing flight aggregator api want the first row. They want to show users the cheapest LIS → LHR across every provider in one card, not wire Amadeus, Skyscanner, and Kiwi separately and reconcile the response formats in a cronjob.

Ktemia is an aggregator. The flight search API post covers the HTTP contract. This page covers why aggregation matters, how the Ktemia aggregator works, and what the response gives you that a single-source search does not.

Why not just call each provider yourself?

Because the integration tax is the product.

Wire Skyscanner and you get a create-and-poll loop with a Partnerships application. Wire Kiwi Tequila and you get fly_from, fly_to, dd/mm/yyyy dates, and a partner key. Wire Amadeus and — as of 17 July 2026 — the self-service portal is gone. Wire a Google Flights scraper and you get an extraction tool with no official API behind it.

Each provider has:

Dimension	What varies
Auth model	API key, OAuth, partner review, enterprise contract
Request shape	POST vs GET, ISO dates vs dd/mm/yyyy, IATA vs city names
Response schema	Nested legs vs flat rows, price as integer cents vs decimal string
Session model	Single-shot vs create-and-poll vs paginated cursor
Rate limits	Per key, per IP, per route, per month, metered

An aggregator absorbs that. You send one JSON body. The aggregator fans out, normalises, and delivers.

The real cost of multi-source flight search is not the HTTP calls. It is the schema reconciliation. A Skyscanner leg object, a Kiwi itinerary, and an airline NDC offer look nothing alike. An aggregator that returns carrier, stops, duration, price, and bookingUrl in the same shape for every provider is selling you the normalisation, not the network request.

How does Ktemia’s flight aggregator API work?

One POST. Three required fields. Many providers behind it.

import requests

response = requests.post(
  "https://api.ktemia.com/v1/flights",
  headers={"X-API-Key": "YOUR_KEY"},
  json={
    "origin": "LIS",
    "destination": "LHR",
    "departure_date": "2026-10-12",
  },
)

data = response.json()

The response includes fares from every provider that has availability for that route and date. Each fare includes:

• Carrier and flight legs — airline codes, departure/arrival times, layovers, and durations per leg.
• Price — the total fare as returned by the provider.
• Provider name — the source of the fare (airline direct, OTA, metasearch partner).
• Booking URL — a link to the provider’s booking page for that specific itinerary.
• Stops and duration — so you can sort by fastest, cheapest, or fewest connections.

You rank. You filter. You display. When the user picks a fare, you send them to the provider’s booking page via the booking URL. Ktemia searches. The provider books.

Optional parameters

Beyond the three required fields, you can pass:

requests.post(
  "https://api.ktemia.com/v1/flights",
  headers={"X-API-Key": "YOUR_KEY"},
  json={
    "origin": "LIS",
    "destination": "LHR",
    "departure_date": "2026-10-12",
    "return_date": "2026-10-19",
    "currencyCode": "EUR",
    "countryCode": "PT",
  },
)

• return_date — for round-trip searches. Omit for one-way.
• currencyCode — EUR, USD, GBP. Prices returned in that currency when available.
• countryCode — localise results to a market. Affects which providers and fares surface.

If origin, destination, or departure_date is missing, the API rejects the call and names the absent field. The copilot does the same. Neither invents Lisbon because the user said “somewhere warm.”

What does the aggregated response look like?

Each result in the response is a normalised fare from one provider. A search for LIS → LHR might return fares from five, ten, or fifteen providers in one response. Here is the structure:

{
  "success": true,
  "data": {
    "results": [
      {
        "provider": "kiwi.com",
        "price": "45.00",
        "currency": "EUR",
        "legs": [
          {
            "departure": "2026-10-12T06:15:00",
            "arrival": "2026-10-12T08:40:00",
            "origin": "LIS",
            "destination": "LHR",
            "carrier": "TP",
            "carrierName": "TAP Air Portugal",
            "flightNumber": "TP350",
            "duration": "2h 25m",
            "stops": 0
          }
        ],
        "bookingUrl": "https://www.kiwi.com/booking/..."
      },
      {
        "provider": "expedia.com",
        "price": "62.00",
        "currency": "EUR",
        "legs": [
          {
            "departure": "2026-10-12T10:30:00",
            "arrival": "2026-10-12T12:55:00",
            "origin": "LIS",
            "destination": "LHR",
            "carrier": "BA",
            "carrierName": "British Airways",
            "flightNumber": "BA499",
            "duration": "2h 25m",
            "stops": 0
          }
        ],
        "bookingUrl": "https://www.expedia.com/..."
      }
    ],
    "airlines": {
      "TP": { "name": "TAP Air Portugal" },
      "BA": { "name": "British Airways" }
    },
    "airports": {
      "LIS": { "cityName": "Lisbon", "displayName": "Lisbon Humberto Delgado" },
      "LHR": { "cityName": "London", "displayName": "London Heathrow" }
    }
  }
}

Every fare in results has the same shape. You do not parse Skyscanner legs differently from Kiwi itineraries. That is the aggregation.

Flight aggregator API vs single-source flight API

The trade-off is coverage versus control.

	Aggregator API	Single-source API
Providers	Many, in one call	One per integration
Schema	Normalised by the aggregator	Provider’s native format
Integration effort	One endpoint, one auth, one schema	N endpoints, N auths, N schemas
Coverage	Wide — airlines, OTAs, metasearch	Narrow — that provider’s inventory
Booking	Redirect to provider	Provider-specific (some include booking)
Control	Aggregator decides provider mix	You pick the source

If you need a specific airline’s NDC content and you have an enterprise agreement, a single-source API makes sense. If you want “show me the cheapest LIS → LHR from everywhere,” an aggregator is the product.

Flight aggregator API vs GDS

A GDS — Amadeus, Sabre, Travelport — is the backbone of airline distribution. Travel agents and OTAs use GDS connections to access airline inventory, create bookings (PNRs), and issue tickets. That is a fundamentally different product from an aggregator search.

Amadeus self-service developer keys stopped on 17 July 2026. Enterprise Amadeus is a contract and a conversation. Sabre and Travelport are the same. These are not “sign up and search” products.

A flight aggregator API like Ktemia sits a layer above. It may search sources that themselves use GDS inventory, but you never touch the GDS directly. You do not need an IATA code. You do not need an enterprise agreement. You need an API key and three fields.

The aggregator-vs-GDS confusion is commercial, not technical. Teams search flight aggregator api because they want fare comparison in their app. GDS vendors appear in the SERP because they are the incumbent infrastructure. But a GDS integration is a months-long enterprise onboarding, not a REST POST. If you are reading this page, you probably want the aggregator.

How to use Ktemia’s flight aggregator in your product

1. Get an API key

Sign up on the dashboard. Free is $0: 50 API requests a month. The key goes in the X-API-Key header. Do not put it in frontend JavaScript.

2. Search flights

import requests

response = requests.post(
  "https://api.ktemia.com/v1/flights",
  headers={"X-API-Key": "YOUR_KEY"},
  json={
    "origin": "JFK",
    "destination": "CDG",
    "departure_date": "2026-11-05",
    "return_date": "2026-11-12",
    "currencyCode": "USD",
  },
)

results = response.json()["data"]["results"]

3. Rank and display

Sort by price, duration, stops, or carrier. Every result has the same schema.

cheapest = sorted(results, key=lambda r: float(r["price"]))
for fare in cheapest[:5]:
    print(f"{fare['carrier']} — ${fare['price']} via {fare['provider']} — {fare['legs'][0]['duration']}")

4. Send the user to book

Each fare includes a bookingUrl. Open it in a new tab. The user books on the provider’s site. You stay a comparison product, not an OTA.

window.open(fare.bookingUrl, '_blank');

That is the full flow. Search → Rank → Redirect. The aggregation, normalisation, and provider management are Ktemia’s job. The display and the UX are yours.

How to use the aggregator with an AI agent

Point the agent at the same contract. MCP, skills, and system prompts live on flights MCP, skills, and instructions. The wiring is different. The rule is the same: origin, destination, depart. Ask if unclear. Do not guess.

{
  "mcpServers": {
    "ktemia": {
      "url": "https://mcp.ktemia.com/mcp"
    }
  }
}

The agent calls the aggregator through the MCP server. It gets the same multi-provider response. It ranks by whatever the user asked for (“cheapest direct flight to Paris”). It does not invent a city or a date. If the user says “fly somewhere nice,” the agent asks where and when. That discipline is in the skill and the system prompt on the homepage.

Connectors — n8n, Zapier, Make — wire the same aggregator into workflows. A price-alert pipeline that checks JFK → CDG every morning and notifies when a fare drops below $400 is one POST in a scheduled workflow. The aggregation happens on every call.

What about stays, cars, and homes?

Ktemia is not flights-only. The same platform aggregates hotels, car rentals, and real estate. A relocation search — flight to Lisbon, a car at the airport, a short-term stay, and a rental listing — is four verticals in one dashboard or four API calls from one key.

That platform job is search a trip or a move. The flight aggregator is one vertical. The value of the platform is that the other three use the same key, the same copilot, and the same MCP server.

Start aggregating fares.

A flight aggregator API compares. One call, many providers, normalised fares. What that surfaces is not theoretical — we priced 1,703 flights across 57 booking sites and found a $970 median gap on the same seat. The Ktemia contract is three required fields, provider-level transparency, and a copilot that asks instead of guessing.

Start from product and the pricing caps. If you are building a comparison, not a GDS, you are on the right URL.