Description
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:
—
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:
—
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-DDstrings. - Airline code fields take a comma-separated list (
LH,BA) and are sent as - Passengers takes comma-separated type codes, one per traveller:
- Seat Type offers Economy (
1) and Business (3). - Sort Type offers Overall, Price and Duration, and applies to both one-way
- Use Fallback is accepted by the API but currently has no effect on a
- Limit follows the n8n convention and pre-fills
50. Leave the option off - The time-window options (
departuretimemin,departurearrivaltime_max - Sample each country more than once. Rates move between identical calls. A
- Pin the property and the currency. Use Get by Name with a fixed Hotel
- 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-workflowis a peer dependency supplied by - Tested n8n versions: none recorded yet. If you hit an incompatibility, please
a JSON array.
1 adult, 2 child, 3 infant on lap, 4 infant in seat. Two adults and a
child is 1,1,2.
and round-trip searches.
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.
entirely and the API applies its own default of 10.
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, priceasnumber,
duration, durationseconds, airline, stops, stopsinfo,
departuredescription, arrivaldescription, buy_link.
Round-trip items carry totalprice, totalpriceasnumber,
totaldurationseconds, totalstops, buylink, plus per-leg fields
prefixed departureflight / returnflight and the
departurestopsinfo / returnstopsinfo arrays. Stop entries look like
{"stopairport": "AUH", "stopduration_seconds": 5700} and the array is empty
for non-stop.
The fields worth building on: priceinsightslow, priceinsightshigh
and pricerangeinrelationtootherperiods (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, checkindate, checkoutdate, applied_filters,
budgetpernight, and properties — an array of
{name, pricestring, price, reviewscore, reviewcount, roomtype, location,. To get one n8n item per property, add a Split Out node on
image_url, link}
the properties field.
Get by Name returns one object: name, available, price_string,
price, reviewscore, reviewcount, roomtype, imageurl, 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:
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.
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/. 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
n8n itself.
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 YOURFLIGHTPOWERSAPI_KEY in docs, issues and screenshots.
—
Resources
