Flight Search API: Compare Fares for a Route

A flight search API is a fare comparison endpoint. You send origin, destination, and dates. You get offers you can rank. You do not get a ticket.

This page is the Ktemia contract for that job: POST /v1/flights, the same search in the UI, and a copilot that asks when a field is missing. The route is not live yet. The examples below are the payload we will accept, not a production response with invented prices.

Key Takeaways

• A flight search API returns comparable fares. It does not issue a ticket. FlightAPI’s own FAQ says you cannot book on its price API.
• Required fields: origin, destination, depart date. Do not guess.
• Ktemia Free: 50 API requests a month. One POST when the route is live.

What is a flight search API?

In August 2026, Ignav’s Best Flight APIs for Developers split vendors by workflow: fare search with a booking handoff, order creation, or Google Flights extraction. A flight search API is the first of those. It returns comparable fares. It does not create a PNR.

That split is the information most “flights API” roundups skip. Search, book, and track are sold under the same phrase. Teams then wire FlightAware into a checkout, or Duffel into a price-alert bot, and wonder why the quota and the compliance look wrong.

Search

Origin, destination, dates in. Comparable fares out. No ticket.

Book

Offer in. Order, payment, and a ticket out. GDS, NDC, or Duffel-style.

Track

Flight number or tail in. Status, delay, position out. Not a fare.

Ktemia is built for search and compare: flights with stays, cars, and homes, in the UI or through APIs. That platform job is search a trip or a move. A search is not a reservation. That is in the terms.

The commercial keyword flight search api is the one that matches this job. Flights api is a mixed SERP: docs, booking platforms, trackers, and listicles in one page. Ranking for the mixed head term without saying which job you do is how bounce rate kills a new domain.

A citation you can lift: a flight search API takes origin, destination, and dates and returns fares to compare. FlightAPI’s Flight Price API FAQ states, in those words, that you cannot book flights using that API; it only tracks prices. Different vendor, same boundary.

What does a flight search API need before it can return fares?

Three fields are required on Ktemia: origin, destination, and a depart date. That is the contract, not a live capture. If any of the three is missing, the call must fail and the copilot must ask. It must not invent Lisbon, London, or 12 October.

Optional later, when the route is live: return date, cabin, passenger counts. They do not replace the three. An agent that “helps” by filling LHR because the user said “weekend in Europe” is not being helpful. It is burning Free quota: 50 API requests a month.

Use a worked query everywhere: LIS to LHR, depart 2026-10-12. Same airports in the dashboard, the POST body, and the copilot. When we have screenshots, they will be this search, not a stock cabin photo.

The rule is the same for a human in the UI and for an MCP client. If the text is unclear, we tell you so and ask you to elaborate. That is already how the product describes the copilot. The API must not be laxer than the copilot.

How do you search flights with a POST request?

One POST, one JSON body, when https://api.ktemia.com/v1/flights is live. Skyscanner’s Flights Live Prices overview uses two calls: /create then /poll with a session token. That is a valid search API. It is a different shape. Do not copy their poll loop onto a single-shot contract.

Until the Ktemia route is live, treat this as the request we will accept. It is the same snippet the site already shows for agents. It is not a logged response.

import requests

requests.post(
  "https://api.ktemia.com/v1/flights",
  json={
    "origin": "LIS",
    "destination": "LHR",
    "depart": "2026-10-12",
  },
)

Authenticate with the dashboard key when keys exist. Do not put that key in frontend JavaScript. Skyscanner’s authentication docs say the same for x-api-key: HTTPS only, never in a public repo. We will publish the exact header name in docs with the route, not invent one here.

What the response is not

A successful search will return offers you can compare: carriers, times, stops, a price. It will not return a PNR, a ticket, or an aircraft position. It will not mean the fare is still for sale an hour later. Third-party supply moves. The terms already say prices and availability can change.

We are not pasting a fake JSON fare list. Invented TAP prices would look like a live test. They would be a lie. When the endpoint responds, this post gets a dated response example and a dateModified stamp.

As of September 2026, the Free plan includes 50 API requests a month as one shared pool across flights, stays, cars, and homes. That number is on the pricing page. Cached edge responses, when they exist, are documented as not counting. That behaviour is not live either; do not build billing assumptions on it yet.

How is a flight search API different from booking, tracking, and Google Flights scrapes?

In February 2026, PhocusWire reported that Amadeus would decommission its self-service developer portal on 17 July, with keys disabled that day, while Enterprise APIs stay. After that date, “just use Amadeus sandbox” is not a self-serve search plan. It is an enterprise conversation. The access comparison with Skyscanner Live Prices is Amadeus API vs Skyscanner API.

Job	What you send	What you get	Typical gate
Search / compare	Origin, destination, dates	Fares to rank	Self-serve or partner review
Book / ticket	Offer plus travellers and pay	Order, PNR, ticket	IATA, NDC, Duffel-style
Track / status	Flight number or tail	Delay, gate, position	ADS-B / status vendors
Google Flights extract	Google Flights query	Structured scrape of that UI	Scraper / SERP APIs

Ignav’s August 2026 comparison is blunt: Duffel is for creating orders; SerpApi is for extracting Google Flights; Ignav itself does not sell or issue tickets. Skyscanner’s live-prices docs require a Partnerships application before you get a key, then create-and-poll.

If your SERP tab is full of “google flights api”, you are not looking at an official Google product. That is the Google Flights API post. TechCrunch reported in November 2017 that Google would shut QPX Express on 10 April 2018, citing low partner interest. Wrappers that read Google Flights in 2026 are extraction tools. They are not a flight search API you control, and they are not this URL’s job.

Ktemia is the search row. Use-cases for getting there without the airline maze sit on flights search with AI. Do not call this a booking API in your README. Do not call it a tracker.

What should you do when the query is unclear?

Reject it. Name the missing field. Ask. Do not guess.

On Free, 50 requests a month is a small budget. One invented city spends a call on a trip nobody wanted. In production that is not a cute copilot personality. It is a billing and trust bug.

The intended API behaviour, not a captured 4xx: if origin, destination, or depart is absent, do not invent LIS. Return an error that lists the missing names. The copilot asks for the same names in a sentence. MCP skills for flights should load that rule (ask if unclear) instead of scraping a results page.

When we have a live error body, it goes here with a date. Until then, implement clients that treat missing fields as fatal, not as “pick a default hub”.

What does a free flight search API include?

As of 23 October 2026, the pricing page publishes four plans. Free is $0: dashboard, 50 API requests a month, and search in the UI for flights, stays, cars, and homes. Pro is $29.99 a month with 20,000 API requests at 20 requests per second. Business is $299 with 250,000 requests at 250 per second, plus MCP servers. Enterprise is a call.

Every plan counts the same unit: a monthly pool of requests shared across flights, stays, cars, and homes. The rate limit is the second cap — Pro stops at 20 calls a second, Business at 250, however much monthly quota is left.

“Free flight api” is a different keyword. Other vendors sell free credits too: FlightAPI advertises 20 credits free on its price API page. A free tier is a cap plus a dashboard, not unlimited live GDS. Ktemia can change some plan prices when demand is high. Read the page you bill against.

Paid plans are monthly. You can change or cancel from the dashboard when that dashboard bills. Refunds exist when it is fair; abuse or a terms breach can mean a cancel without a refund. That is the terms, not a slogan.

How do you put the same search in an agent?

Point the agent at the same contract, not at a scraped UI. Cursor, Claude Code, mcp.json, flights/SKILL.md, and the system prompt live on flights MCP, skills, and instructions. This page stays the HTTP job: POST /v1/flights, three required fields, ask if unclear.

When MCP is live, the client still sends origin, destination, and depart. It should not fill dates because the user said “soon”. Connectors (n8n, Zapier, Make) are for workflows you already run. They do not change the rule: no origin, no call.

Start with fares you can compare.

A flight search API compares. How much that is worth is measurable: across 57 booking sites, the identical seat on the identical flight carried a median price spread of $970. It does not ticket, and it does not track a tail number. The Ktemia contract is one POST, three required fields, and a copilot that asks instead of guessing. The endpoint is not live. When it is, this page will show a dated response, not a prettier fiction.

Start from product and the pricing caps. If you are shortlisting rather than building yet, best travel API compares eight options on access, coverage and what each returns. If you are building the trip, not the PNR, you are on the right URL.