Build on the platform.
API reference, examples, and how to use the UI and the copilot alongside the endpoints.
These docs are the contract for search and compare. You send required fields. You get rows you can rank. You do not get a ticket, a hotel confirmation, a car voucher, or a lease. The UI, the APIs, and the copilot share that job. If they disagree, the docs are wrong.
Start with getting started if you have not used the dashboard. Read the flights API note if you are wiring POST /v1/flights. Read required fields if you are teaching an agent not to invent a city. Product shape lives on product. Caps live on pricing. The four verticals live on use cases.
Routes are not live yet. Examples here are the payload we will accept, not captured fares or live listing prices. When a route ships, the page for that route will say so. Until then, do not treat a snippet as a booked trip. Free includes UI search on every route and 50 API requests a month. Missing a field is not a retry with a guessed airport.
- Getting startedUse the Ktemia UI, call the APIs, or ask the copilot. Same compare job. Required fields. Routes are not live yet.
- Flights APIPOST /v1/flights with origin, destination, and depart. Compare fares. Not a ticket. The route is not live yet.
- Required fieldsIf a field is missing, the copilot asks and the API names it. Neither invents a city or a day.
How to read these pages
A docs page states the job, the required fields, and the booking boundary. Longer commercial context stays on the blog: the flight search API post for fare search versus booking, and the flights MCP post for Cursor or Claude. Use the docs when you are implementing. Use the blog when you need the argument.
Missing a field is not a retry with a guessed airport. The copilot asks. The API names the field. That is the whole platform rule, written once so the UI, the HTTP contract, and the agent skill cannot drift.