Rate Beacon

A free, self-hosted hotel rate intelligence dashboard — a lightweight Lighthouse/OTA-Insight-style tool. Track what competitor hotels charge night by night, spot high-demand dates, see where your own rate sits against the market, and watch how prices move over time.

Rate data comes from the free, keyless Xotelo API, which serves TripAdvisor's public meta-search prices across OTAs (Booking.com, Expedia, Agoda, …). Hosting fits entirely in Vercel + Supabase free tiers. No paid services, no API keys for the data source.

Originally built on the Amadeus Self-Service API, which was decommissioned on July 17, 2026 — Xotelo replaced it and is a better fit anyway: any hotel on TripAdvisor works, identified simply by its TripAdvisor page URL.

What it does

• Competitor rate grid — paste your hotel's TripAdvisor link, pick 5–10 competitors (from the same location or by pasting their links); see everyone's cheapest-OTA nightly rate for the next 7–120 days in a color-coded grid (blue = cheaper than that night's market median, red = pricier).
• Your rate vs the market — mark your own hotel, or type your rates directly into the grid if you're not on TripAdvisor; every night is banded well-below → well-above market.
• Advice column — ▲ Raise (at/below market on a high-demand night), ▲ Low? (far below market), ▼ High (well above a soft market).
• Demand signal (0–100) — built from how much of the comp set is sold out plus how fast the market median has been climbing for that date.
• Rate history — a daily snapshot job stores every rate; click any date to see per-hotel price-evolution sparklines, and hover any cell to see which OTA had the cheapest offer.

Try the data source first (10 seconds)

From any machine with Node 18+:

node scripts/test-xotelo.mjs "https://www.tripadvisor.com/Hotel_Review-g…-d…-Reviews-….html"

Paste your own hotel's TripAdvisor URL — it prints the live OTA offers for a night two weeks out.

Setup (~15 minutes, all free)

1. Supabase database (~5 min)

1. Create a free project at supabase.com.
2. In the project's SQL Editor, paste and run each file in supabase/migrations/ in numeric order, 001 first. The last one (008_tenant_isolation.sql) is what stops one customer's account from reading another's.
3. From Project Settings → API copy three values: the Project URL, the service_role key (server-only — never expose it in a browser), and the anon key. The anon key is what lets the app connect as the signed-in account, so the database enforces the separation instead of the application code remembering to. Reveal each value before copying — the masked display is bullet characters, not the key.

Already done for this repo's owner: the project rate-beacon (https://fcyghazlfnytejvdxkfk.supabase.co, us-east-1) exists with the schema applied — just grab the service_role key from its dashboard.

2. Deploy to Vercel (~10 min)

1. Import the repo on vercel.com. If it lives in a subfolder of a larger repo, set Root Directory to rate-beacon.
2. Add the environment variables from .env.example: SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY, SUPABASE_ANON_KEY, APP_SECRET (any long random string — it encrypts stored credentials and derives each account's database identity), and CRON_SECRET (another long random string — protects the daily job).
3. Deploy. vercel.json registers a daily cron at 06:00 UTC that snapshots all rates; Vercel authenticates it automatically with CRON_SECRET.
4. Open /api/system-check and confirm Tenant isolation reads "Enforced by the database". Without the anon key the app still runs, but on the service key with row-level security bypassed — acceptable for a single owner, not for a second customer.

Open the site → Create a profile (paste the hotel's TripAdvisor link, add competitors) → hit Refresh rates once. From then on the daily job keeps the history building automatically. Profiles are per-baseline-hotel: each one bundles a hotel, its market, notes, and its own competitor set, switchable from the dashboard header.

Local development

cp .env.example .env.local   # fill in your Supabase values
npm install
npm run dev                  # http://localhost:3000

Competitor discovery (no hand-curated lists)

Every competitor set is derived from public data by the same pipeline, so it works for any hotel anywhere — nothing is hand-authored:

1. List every hotel TripAdvisor knows in the hotel's location (Xotelo /list).
2. Geocode the ones not yet placed (OpenStreetMap Nominatim, ~1 req/s).
3. Rank by great-circle distance from the hotel and keep the nearest N as competitors; a few hotels around each competitor become map-only context.
4. Store the edges with their distance, so the dashboard can show why a hotel is in the set.

Run it from the dashboard (Find competitors), from the API (POST /api/discover?profileId=1[&baselineId=g..-d..]), or standalone:

SUPABASE_URL=... SUPABASE_SERVICE_ROLE_KEY=... \
  node scripts/discover.mjs 1            # all baselines in profile 1
  node scripts/discover.mjs 1 g34550-d10637341 15 3   # one hotel, 15 comps, 3 extras each

Adding a new hotel and running discovery gives that hotel its own nearest competitors rather than inheriting another hotel's set. Map-context hotels are priced over a short 7-night window so the extra coverage stays cheap.

Notes & limits

• Request volume: one Xotelo lookup per hotel per night — a daily snapshot of 6 hotels × 45 days ≈ 270 requests, spread over a couple of minutes with 4 concurrent workers and retry/backoff. Keep the horizon modest; be polite to a free service (there's a donate page).
• Hotel coverage: any property with a TripAdvisor page that shows prices. If your own hotel isn't listed, leave "mine" unticked and type your rates straight into the you column — comparisons work the same.
• Prices prefer the brand site's rate (IHG.com, Marriott.com, …) when TripAdvisor's compare list carries it, falling back to the cheapest seller; the cheapest quote and the full seller list are stored too (hover a cell). A superscript "D" marks brand-direct rates.
• Demand & advice are heuristics built only from observable signals (comp sold-outs, median momentum). They're a starting point for a pricing decision, not a revenue-management system.
• The snapshot route runs up to 300 s per invocation; for very large horizon × hotel combinations call POST /api/refresh?maxDates=30 in chunks.
• Xotelo is an unofficial free service — if it ever disappears, the data layer is isolated in src/lib/xotelo.ts and can be swapped for another provider without touching the dashboard, database, or insights.

Stack

Next.js 15 (App Router, TypeScript) · Tailwind CSS 4 · Supabase (Postgres) · Xotelo API (/api/rates, /api/list) · Vercel Cron.

Rotating credentials

Every secret this project uses has, at some point, been pasted into a chat window or a terminal. Before a second customer's data is in the system, rotate all of them. In order, because some depend on others:

1. APP_SECRET — generate a new 32+ character random string. This invalidates every stored mailbox password and every encrypted report text, and changes each account's derived Supabase credentials. After deploying: reconnect any mailbox from the reports tab (the password is re-encrypted under the new secret), and the app resets each account's auth-user password automatically on its next request.
2. CRON_SECRET — any long random string. The app rewrites it into api_settings on the next run, so the in-database scheduler follows.
3. INGEST_SECRET — set the same new value on Vercel and in the Cloudflare Worker (npx wrangler secret put INGEST_SECRET).
4. Supabase service role key — Project Settings → API → Rotate. Update SUPABASE_SERVICE_ROLE_KEY on Vercel and redeploy.
5. Third-party keys you have set (Gemini, Ticketmaster) — regenerate in each provider's console and update the environment variable.
6. App passwords — sign in as each account you control and change them; there is no shared admin password to rotate.

Then run /api/system-check. Every row should be green, and Tenant isolation should still read "Enforced by the database".