flightpowers

n8n community node for the FlightPowers travel-data API: live flight fares with Google price insights, and live Booking.com hotel rates with per-country pricing. Independent API; not affiliated with, endorsed by, or sponsored by Google or Booking.com.

Package Information

Released: this month
Downloads: 0 weekly / 0 monthly
Latest Version: 0.2.4
Author: mtnrabi

Available Nodes

Documentation generating…

FlightPowers icon
FlightPowers
Search live flight fares and hotel prices with the FlightPowers travel-data API

Documentation

n8n-nodes-flightpowers

An n8n community node for the
FlightPowers travel-data API: real-time
flight fares and hotel prices from one vendor, one credential, one node.

One node, two resources, four operations: one-way flight search, round-trip
flight search, hotel destination search, and hotel-by-name lookup.

Not affiliated. This is an independent API that returns publicly
available flight and hotel pricing. It is not affiliated with, endorsed by,
or sponsored by Google or Booking.com.

Installation · Credentials ·
Operations · Working with the results ·
Compatibility · Development · License

Installation

Unverified community nodes install on self-hosted n8n only. They are not
available on n8n Cloud.

From the n8n editor

  1. Go to Settings > Community nodes.
  2. Select Install.
  3. Enter n8n-nodes-flightpowers.
  4. Agree to the risks of using community nodes and select Install.

Manually

cd ~/.n8n/nodes
npm install n8n-nodes-flightpowers

Restart n8n. The node appears in the nodes panel as FlightPowers.

Full n8n guide: https://docs.n8n.io/integrations/community-nodes/installation-and-management

Credentials

The node authenticates with a single FlightPowers API credential: your API
key, sent as the x-api-key header to https://api.flightpowers.com.

If you subscribed through the RapidAPI marketplace, use that RapidAPI key here
unchanged — the same key authorises both the flight and the hotel operations,
and your usage stays billed to that subscription.

Saving the credential calls GET /v1/verify, which validates the key and
reports remaining quota without running a billable search.

Get a key: https://api.flightpowers.com/docs

Operations

Flight → Search One-Way

POST https://api.flightpowers.com/v1/flights/oneway

Required: From Airport (IATA), To Airport (IATA), Departure Date
(YYYY-MM-DD).

Options: Airline Codes, Arrival Time Min/Max, Currency (default USD),
Departure Time Min/Max, Exclude Airline Codes, Limit, Max Price, Max Stops,
Passengers, Seat Type, Sort Type, Use External Proxy (default true), Use
Fallback.

Flight → Search Round-Trip

POST https://api.flightpowers.com/v1/flights/roundtrip

Required: From Airport, To Airport, Departure Date, Return Date.

Options: Currency, Limit, Max Departure Stops, Max Price, Max Return Stops,
Outbound Airline Codes, Outbound Arrival Time Min/Max, Outbound Departure Time
Min/Max, Outbound Exclude Airline Codes, Passengers, Return Airline Codes,
Return Arrival Time Min/Max, Return Departure Time Min/Max, Return Exclude
Airline Codes, Seat Type, Sort Type, Use External Proxy, Use Fallback.

The "Outbound …" options map to the API's departure_* parameters; the
"Return …" options map to the return_* parameters.

Hotel → Search Destination

POST https://api.flightpowers.com/v1/hotels/search

Required: Destination (free text — Paris, Tokyo Shibuya, Hilton NYC),
Check-in Date, Check-out Date.

Options: Adults (default 2), Budget per Night, Children (default 0),
Currency (default USD), Filters, Proxy Country.

Filters are picked from a fixed list: Accepts Online Payment, Adults Only,
Air Conditioning, All Inclusive, All Meals Included, Breakfast and Dinner,
Breakfast and Lunch, Breakfast Included, Free Cancellation, Free WiFi, Front
Desk 24h, Gym, Parking, Pets Allowed, Private Bathroom, Review Score 7/8/9,
Sauna, Stars 3/4/5, Swimming Pool, Very Good Breakfast.

Hotel → Get by Name

POST https://api.flightpowers.com/v1/hotels/by-name

Required: Hotel Name, Check-in Date, Check-out Date.

Options: Adults, Area (disambiguates generic names), Children, Currency,
Free Cancellation, Proxy Country.

When the property is sold out for those dates the API returns
available: false with null price fields. That is a valid answer, not an
error — branch on available with an If node rather than treating it as
a failure.

Field formats

  • All dates are plain YYYY-MM-DD strings.
  • Airline code fields take a comma-separated list (LH,BA) and are sent as
    a JSON array.
  • Passengers takes comma-separated type codes, one per traveller:
    1 adult, 2 child, 3 infant on lap, 4 infant in seat. Two adults and a
    child is 1,1,2.
  • Seat Type offers Economy (1) and Business (3).
  • Sort Type offers Overall, Price and Duration, and applies to both one-way
    and round-trip searches.
  • Use Fallback is accepted by the API but currently has no effect on a
    search. It selects a second, independent flight-data source, and that source
    is not switched on for this API, so none of its values changes anything today.
    Leave the option off.
  • Limit follows the n8n convention and pre-fills 50. Leave the option off
    entirely and the API applies its own default of 10.
  • The time-window options (departure_time_min, departure_arrival_time_max
    and friends) are passed through to the API unchanged. See the FlightPowers
    API docs for the format those parameters accept.

Working with the results

Fares go stale in minutes — never cache them

Do not store a fare and reuse it on a later run, and do not build a workflow
that reads a previous execution's price as if it were current. Re-run the
search, and always record and display when the data was fetched. A cached
fare is a wrong fare.

Flight responses

Both flight operations return a bare JSON array, so this node emits one n8n
item per itinerary. An empty result is [] with HTTP 200: zero output
items, not an error. Guard downstream branches accordingly (for example with an
If or No Operation path).

Zero items is not on its own proof that there are no flights. The API says which
it was in the X-Search-Status response header — ok, empty, partial or
degraded. empty means the search completed and there genuinely is nothing
for that route and date; degraded means the search did not complete, so the
empty array says nothing about availability and the run is worth repeating.
X-Search-Reason, X-Search-Results, X-Search-Attempts, X-Search-Retries
and X-Search-Combinations describe what the search did.

This node emits the response body, so those headers are not visible inside it.
Treat zero items as "no result on this run" rather than telling a user there are
no flights; a workflow that must tell the two apart can call the same endpoint
with an HTTP Request node and read the header.

Every one-way item carries, among other fields: price, price_as_number,
duration, duration_seconds, airline, stops, stops_info,
departure_description, arrival_description, buy_link.

Round-trip items carry total_price, total_price_as_number,
total_duration_seconds, total_stops, buy_link, plus per-leg fields
prefixed departure_flight_* / return_flight_* and the
departure_stops_info / return_stops_info arrays. Stop entries look like
{"stop_airport": "AUH", "stop_duration_seconds": 5700} and the array is empty
for non-stop.

The fields worth building on: price_insights_low, price_insights_high
and price_range_in_relation_to_other_periods (low | typical | high).
They are the historical price range for that route and period, which is what
lets a workflow say "$209 is typical for this route, don't rush" instead of
just quoting a number.

Hotel responses

Search Destination returns a single object per input item:
destination, checkin_date, checkout_date, applied_filters,
budget_per_night, and properties — an array of
{name, price_string, price, review_score, review_count, room_type, location, image_url, link}. To get one n8n item per property, add a Split Out node on
the properties field.

Get by Name returns one object: name, available, price_string,
price, review_score, review_count, room_type, image_url, link,
nights, adults, children.

Proxy Country, the option most people miss

proxy_country routes the request through a residential proxy in the country
you name (a two-letter code such as de, jp, il), so the same room on the
same dates is priced the way a resident of that country would be quoted it.
That is what makes rate-parity and geo-pricing monitoring possible, and it
is a business use case rather than a hobby one.

Two things to build into the workflow, or it will report gaps that are not
there:

  • Sample each country more than once. Rates move between identical calls. A
    workflow that makes one call per country and diffs the prices will find a
    difference nearly every time, and most of those are the rate moving rather
    than the country. Run the country list three times, treat the spread inside a
    single country as your noise floor, and only report a gap that is larger than
    that floor and points the same way on every pass.
  • Pin the property and the currency. Use Get by Name with a fixed Hotel
    Name and Area, not the first row of a Search Destination result: the order
    of properties is not stable across identical requests, so row 1 is a
    different hotel from one call to the next. Send the same Currency to every
    country, or you are measuring the FX rate instead of the hotel.

Real gaps are modest and depend on the property. In a controlled test on
2026-08-28, three independent Rome guest houses came back about 4% cheaper from
Japan than from Germany, holding across repeated samples, while a chain hotel
returned the same price from every country tried. "No gap" is a valid result,
not a failed check.

proxy_country is an input only. Nothing in the response says which country a
price came from, so carry the country code through the workflow yourself, for
example with a Set node alongside the FlightPowers node.

How calls are counted

Every request this node sends carries X-FP-Client: n8n-node/<version>. It
names the node as the caller so FlightPowers can tell n8n traffic apart from
someone calling the same API by hand, and it is the only thing the header does:
no search parameter changes, no request body changes, no response changes, and
nothing about your key, your workflow or your search terms is in it.

Before 0.2.3 the header was absent and every call from this node was counted as
an anonymous marketplace call.

Compatibility

  • Requires Node.js 20.15 or newer, matching current n8n requirements.
  • Built as a declarative-style node against n8n-nodes-api-version 1.
  • Zero runtime dependencies. n8n-workflow is a peer dependency supplied by
    n8n itself.
  • Tested n8n versions: none recorded yet. If you hit an incompatibility, please
    open an issue with your n8n version.

Development

npm install
npm run lint      # eslint-plugin-n8n-nodes-base, community ruleset
npm run build     # tsc + gulp build:icons -> dist/
npm test          # builds, then checks the X-FP-Client client name

npm test guards the one thing here that can rot without failing anything else:
the client name in nodes/FlightPowers/attribution.ts has to match the version
in package.json, has to stay a value the FlightPowers front accepts, and has
to actually be attached to both the node and the credential test. Bump it in
the same commit as the version.

To try it in a local n8n instance:

npm run build
npm link
cd ~/.n8n/nodes && npm link n8n-nodes-flightpowers

Publishing is handled by .github/workflows/publish.yml, which runs on a
GitHub release and publishes with --provenance. Register that workflow as a
Trusted Publisher in the npm package settings; no npm token is stored in the
repository. Do not publish by hand — n8n's verification process requires a
GitHub Action with a provenance statement.

Never commit a real key. The credential field is the only place an API key
belongs; use YOUR_FLIGHTPOWERS_API_KEY in docs, issues and screenshots.

Resources

License

MIT

Discussion