Using a hotel API in n8n

The workflow this guide builds is a hotel rate monitor: every day, check a specific hotel's rate for your dates, and send yourself a message when the price drops below your threshold. Four nodes (schedule trigger → hotel search → IF → notification) and no state to maintain between runs.

The pattern scales to multi-market rate-parity checks (the same hotel priced from the US, Germany, and Israel) or comp-set tracking (your hotel plus three competitors on the same schedule).

What you need

• An n8n instance (cloud or self-hosted) where you can install community nodes, or failing that, use the HTTP Request variant below: it works everywhere, including instances where community nodes are disabled.
• A RapidAPI key for the Booking Live API. The free tier verifies your key works; a daily monitor on a handful of properties fits comfortably in the cheapest paid plan (current numbers on /pricing).

Route A: the community node

There is a first-party community node, n8n-nodes-flightpowers, which wraps the flight and hotel endpoints as a native n8n node: typed parameters instead of a hand-built JSON body, and your API key stored once as an n8n credential rather than pasted into every workflow. The full n8n integration page documents installation and setup.

Install it the way you install any n8n community node (from the community-nodes section of your instance's settings, by the package name n8n-nodes-flightpowers), then build the workflow:

1. Schedule Trigger. Once a day, at an hour you'll actually read the alert.
2. FlightPowers node. Choose the hotel search operation and set the destination and dates you are watching: for example "Rixos Sungate, Antalya" for check-in on October 5, check-out on October 10. Add your credential (the RapidAPI key) once; every later workflow reuses it.
3. IF node. Condition: the first result's price_as_number is below your threshold (say, 800 for $800). That single comparison is the entire alerting logic.
4. Notification node: whatever you already use (email, Telegram, Slack, a webhook). Include the price (price_string), the room type (room_type), the review score (review_score), and the booking_link, which opens that exact property and dates on Booking.com ready to book.

One handling note: when no rooms are available, available is false and price_as_number is null. Treat null as "no inventory," not as "zero price." If availability matters more than price, alert on available: true regardless of price.

Route B: the HTTP Request node

No community node required: n8n's built-in HTTP Request node can call the API directly. Configure it as a POST to:

https://booking-live-api.p.rapidapi.com/api/hotels/v1/hotel_by_name

with headers:

Content-Type: application/json
x-rapidapi-host: booking-live-api.p.rapidapi.com
x-rapidapi-key: YOUR_RAPIDAPI_KEY

and this JSON body (the exact shape from the listing's own documentation):

{
  "hotel_name": "Rixos Sungate",
  "area": "Antalya",
  "checkin_date": "2026-10-05",
  "checkout_date": "2026-10-10",
  "currency": "USD"
}

Store the key in an n8n credential (a header-auth credential works) rather than typing it into the node, so it stays out of exported workflow JSON.

The response is a JSON object with the headline rate for that property:

{
  "name": "Rixos Sungate",
  "price_string": "$750",
  "price_as_number": 750,
  "review_score": 8.9,
  "review_count": 1247,
  "room_type": "Deluxe Room",
  "available": true,
  "booking_link": "https://www.booking.com/hotel/tr/rixos-sungate.html?..."
}

Downstream, the workflow is identical to Route A: IF available is true and price_as_number is below your threshold, notify.

Set the node's timeout generously: this is a live search of Booking.com, not a cache read, and response time tracks property complexity. 60 seconds is a sane ceiling.

Variations that reuse the same skeleton

• Watch several properties. Put the hotels in a list (a Code node or a static data node), loop the search over them, and collect the hits below threshold into one digest message instead of N pings. Mind your plan's per-minute rate limit if the list is long: space the iterations rather than firing them all at once.
• Multi-market rate parity. Same hotel, three requests with different proxy_country values ("proxy_country": "US", "proxy_country": "DE", "proxy_country": "IL"), and you have the full competitive pricing picture. The pattern is written up in How to monitor hotel rate parity.
• Destination search instead of one property. Use the /search endpoint instead of /hotel_by_name: pass "destination": "London, UK" and you get a ranked list of properties. Filter by price_as_number, review_score, or both.
• Threshold + availability. The strictest trigger is an AND: available is true and price_as_number is under your budget. There is inventory, and it is cheap for you.
• Flights. The companion Google Flights API follows the same pattern: the scheduled version of a fare watch is written up in Using a flight API in n8n.

Related

• n8n integration: the full node installation and setup guide
• Booking Live API on RapidAPI: the API listing with pricing and documentation
• How to get a Booking.com API key: the full setup walkthrough
• How to monitor hotel rate parity: the multi-market pattern, documented and proven
• Hotel by name endpoint reference: the endpoint this guide uses