Description

n8n-nodes-flightpowers

An n8n community node for live flight prices and hotel
rates: real-time Google Flights fares (one-way, or a round trip priced as one
request, with Google’s own low / typical / high verdict), Booking.com hotel
prices by destination or hotel name, and Airbnb stays by destination with
Airbnb’s own filters, inside any n8n workflow. Built by
FlightPowers, a travel data API: one vendor, one
credential, one node (API docs).

Where to get a key: subscribe to the
Google Flights Live API, the
Booking Live API and/or the
Airbnb Live API on RapidAPI (flights and
Booking: a free pack of 10 searches a month, then PRO is $10 for 2,500 flight searches or 2,000
hotel searches; Airbnb: BASIC is free for 100 searches a month, then PRO is $10 for 10,000) and
paste the key into the FlightPowers credential.

One node, three resources, five operations: one-way flight search, round-trip
flight search, hotel destination search, hotel-by-name lookup, and Airbnb stay
search.

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

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. One key works for every operation, provided it is subscribed to the
listing behind that operation, and each call is billed to that subscription:

| Resource | RapidAPI listing the key must be subscribed to |
|—|—|
| Flight | Google Flights Live API |
| Hotel | Booking Live API |
| Airbnb | Airbnb Live API (BASIC is free, 100 searches a month) |

Saving the credential calls GET /v1/verify, which validates the key without
running a billable search. It checks the flights and Booking listings only: a
key subscribed to the Airbnb Live API and nothing else shows as failing that
test, yet its Airbnb searches work. Save the credential anyway in that case.

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.

Airbnb → Search Stays

POST https://api.flightpowers.com/v1/hotels/search with provider: "airbnb"
in the body (the node adds it). Billed to your Airbnb Live API subscription.

Required: Destination (Rome, Italy, Lisbon), Check-in Date, Check-out
Date. A place Airbnb does not recognise returns no listings, not an error.

Options: Adults (default 2), Children, Infants, Pets, Currency (default
USD), Min Price per Night, Max Price per Night, Min Bedrooms, Min Beds, Min
Bathrooms, Room Types, Min Rating, Sort.

• Prices are per night. Min / Max Price per Night bound the nightly price

in the selected currency, and Airbnb applies them itself.

• Room Types are Airbnb’s own four: Entire home/apt, Private room, Shared

room, Hotel room.

• Min Rating is 0 to 5 (Airbnb rates out of 5); listings with no rating yet

are left out when it is set.

• Sort offers Price low to high, Price high to low, and Rating high to low.

Airbnb has no sort of its own, so these order the page of results the search
returned (and Min Rating filters that page); leave Sort off for Airbnb’s
relevance order.

• The Booking.com Filters list is not offered here: it is Booking-only, and

the API refuses it on an Airbnb search rather than silently widening the
results. Use Max Price per Night where you would use Budget per Night.

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 (departuretimemin, departurearrivaltime_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, 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,
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, reviewscore, reviewcount, roomtype, imageurl, link,
nights, adults, children.

Airbnb responses

Search Stays returns a single object per input item: provider
(airbnb), destination, checkindate, checkoutdate,
destinationmatched (the place Airbnb resolved your text to), searchstatus,
filters_applied (each filter you sent, and whether Airbnb or the API applied
it), and properties, an array of listings with, among other fields, name,
pricetotal, pricepernight, currency, rating, reviewcount,
bedrooms, beds, baths, roomtype, latitude, longitude, imageurl
and link. Add a Split Out node on properties to get one n8n item per
listing.

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/. 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 and the required-field hooks

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

• n8n community nodes documentation:
• FlightPowers API docs:
• Buy a key on the RapidAPI marketplace — flights:
• Buy a key on the RapidAPI marketplace — hotels:
• Buy a key on the RapidAPI marketplace — Airbnb:

License

MIT