Cavuka: A Flight-Search
API Integration

A traveller marks two points on a map, Europe on one side, North America on the other, and a rough idea of when they want to fly. They do not want a hundred results to wade through. They want the two or three best direct business-class options and a button that books one. Cavuka is the search engine behind that moment, and it holds not a single flight of its own.

Put simply, Cavuka is a flight-search MVP built entirely on the TravelPayouts APIs. Every flight, price, airport and booking link comes from those third-party endpoints, so the product’s whole job is to orchestrate them cleanly. A Node.js and Express backend hides that complexity behind a deliberately simple, centred React front end, and the service runs on Azure with GitHub and CI/CD. Because there is no inventory of its own, this is an integration story first, so what follows is the integration problems we faced, how we solved them, and what shipped.

The Starting Point: A Search Engine With No Flights of Its Own

Cavuka searches direct, business-class flights between Europe and North America, and it owns none of that data. Every flight, price and schedule is served live by TravelPayouts. That single fact sets the whole engineering agenda: if the integration is solid the product works, and if it is not there is nothing to fall back on. Turning a casual route-and-date choice into a real-time, filtered, bookable, commission-earning result meant solving a handful of specific problems.

• No flight data of our own. Every flight, price and schedule comes from TravelPayouts, so the product only works if that integration holds.
• Friendly input, technical API. Users pick a continent or a country, but the flight API speaks in IATA airport codes, so the two have to be bridged.
• Two very different date modes. Searching by an exact date, with an optional tolerance or no preference across six months, and searching by a trip duration inside a window both have to become concrete queries the API accepts.
• The API returns too much. It hands back many flights, but Cavuka wants only direct business-class options and only the best three, so results have to be filtered and trimmed.
• Every result must earn. Revenue is affiliate-only, so each result needs a valid, tracked booking link generated per search.
• A slow upstream, a fast UI. Third-party calls add latency and carry limits, yet the search has to stay quick and stay standing when the upstream is slow.

The Build: Four TravelPayouts APIs Behind One Node.js Backend

The integration lives behind a Node.js and Express backend that hides every piece of third-party complexity from the screen. When a search comes in, the backend resolves the user’s continent or country selection to IATA airports through the TravelPayouts Airports API, expanding a region into the airports it contains. It translates whichever date mode the user chose, an exact date with an optional plus-or-minus three-day tolerance, no preference across six months, or a trip duration inside a window, into the concrete parameters the Flights Data API accepts. This orchestration of several endpoints into one clean pipeline is the heart of the API development and integration work, and keeping it all server-side is a deliberate Node.js development choice so the front end stays simple.

For a single search, that pipeline runs in order:

1. Resolve the chosen continent or country to its IATA airports through the Airports API.
2. Translate the selected date mode, exact date with tolerance or a trip-duration window, into concrete Flights Data API parameters.
3. Query the Flights Data API for real-time flights on those routes and dates.
4. Filter to direct business-class only, then sort by price or by duration depending on whether the user asked for cheap or fast.
5. Return the top three options and nothing more.
6. Generate an affiliate Book Now link for each option through the Affiliate API, so every result can earn a commission.

To keep the experience fast over a slower upstream, airport data is cached and third-party calls are guarded with timeouts and sensible handling, and the Prices API supplies latest prices for price-aware date selection. The complexity lives in the integration, not on the screen.

Technical Architecture

Under the hood, Cavuka is a React front end over a Node.js and Express backend that orchestrates four TravelPayouts endpoints, hosted on Azure. The architecture centres on a handful of subsystems, each tied to one of the problems above.

• Region-to-airport resolution. The backend expands a continent or country choice into IATA airports through the Airports API, so a friendly dropdown maps cleanly to the codes the flight API needs.
• Date-mode translation. Both search modes, exact date with tolerance and trip-duration window, are converted into concrete Flights Data API parameters by one query builder, so a single integration serves both journeys.
• Fetch, filter and trim. The backend queries the Flights Data API, filters to direct business-class, sorts by price or duration, and returns the top three, so the user sees a short, relevant list instead of a wall of options.
• Affiliate link generation. Each returned option gets a tracked link through the Affiliate API, so Book Now redirects to the partner booking site and can earn a commission with no payment processing of Cavuka’s own.
• Caching and resilience. Airport data is cached and third-party calls are time-guarded, and the Prices API backs a price-aware calendar, so a slow or flaky upstream never breaks the search that depends on it.

Challenges Solved

Each problem was met with a specific answer. Running with no inventory was solved by leaning fully on the Flights Data API for real-time flights, prices and schedules, so there is a complete search with nothing to hold or maintain. The gap between friendly input and a technical API closed once regions were resolved to airports server-side, giving users a simple dropdown that still produces valid, code-based queries. Two very different date modes were funnelled through one query builder, so search-by-date and search-by-window both work from a single integration rather than duplicated logic. An overwhelming response became a short list by filtering to direct business-class, sorting by price or duration, and stopping at three.

Revenue was handled by generating an affiliate link per result, so every Book Now can earn without Cavuka processing a payment itself, the model that suits affiliate-driven travel and booking platforms where the booking happens on a partner’s site. And the tension between a slow upstream and a fast interface was resolved by caching airport data and guarding calls with timeouts, so the search stays quick and resilient even when TravelPayouts is slow to answer.

The Result

The outcome is a focused flight search that runs entirely on third-party data and earns on every booking. A visitor picks a route and a rough date preference, and the backend returns the top three direct business-class flights, sorted the way they asked, each with a working Book Now link that redirects to the partner and can pay a commission. The friendly region choice resolves to the right airports, both date modes work from one integration, and the whole thing stays fast over a slower upstream because the upstream is cached and guarded. It ships as an MVP on Azure with GitHub CI/CD, with the complexity kept in the backend and the screen kept simple.

If you are building a product that lives or dies on a clean third-party integration, you can hire Node.js developers who have wired real-time search, filtering and affiliate revenue onto external APIs, or tell us about your integration and we will map your endpoints to a pipeline that stays fast and earns.

Frequently Asked Questions

Can you build a flight search without owning any flight data?

Yes. Cavuka holds no flights of its own. Every flight, price, airport and booking link is served live by the TravelPayouts APIs, and a Node.js and Express backend orchestrates those endpoints into a single search, so there is a full flight-search product with no inventory to hold or maintain.

How does Cavuka turn a country or continent choice into real flights?

The backend resolves the chosen region to its IATA airports through the TravelPayouts Airports API before querying flights. That way users get a simple continent or country dropdown while the Flights Data API still receives the exact airport codes it needs to return real results.

How do the two date modes work?

A single query builder handles both. An exact date can carry an optional plus-or-minus three-day tolerance or no preference across six months, and a trip can instead be searched as a duration inside a chosen window. Each mode is translated into concrete Flights Data API parameters, so both journeys run from one integration.

How does the search stay fast when it depends on third-party APIs?

Airport data is cached and every third-party call is guarded with timeouts and sensible error handling, so a slow or flaky upstream slows the search at worst rather than breaking it. The Prices API also backs a price-aware calendar, keeping date selection responsive.

How does an affiliate flight search earn revenue?

For each of the top three results, the backend generates a tracked affiliate link through the TravelPayouts Affiliate API. The Book Now button redirects the traveller to the partner’s booking site, where a completed booking earns a commission, so Cavuka never processes a payment of its own.