Booking.com Rate & Availability Event Monitor
Pricing
from $1.31 / 1,000 rate events
**Monitor hotel prices and availability on Booking.com — emit only acted-on events.** Detects price_drop, price_spike, sold_out, re_opened, rooms_left_low, new_listing, and Booking-vs-Kayak parity violations (≥5%). Stateful: remembers last-seen prices across runs via named KV store.
List of Booking.com hotel page URLs to monitor for price and availability changes. Example: ['https://www.booking.com/hotel/fr/paris-marriott.html']. Each URL must contain a valid Booking.com hotel ID. Monitored via AvailabilityCalendar GraphQL API — cheap (~6 requests per property per 365-day window).
List of destination+date search configurations to monitor for inventory events. Each item must have 'destination' (city or region name), 'checkin' (YYYY-MM-DD), and 'checkout' (YYYY-MM-DD). Example: [{"destination": "Paris", "checkin": "2026-07-01", "checkout": "2026-07-03"}]. Uses Booking.com FullSearch GraphQL — up to 1,000 results per search.
Default check-in date for property URL monitoring in YYYY-MM-DD format. Example: '2026-07-01'. Used as the start of the AvailabilityCalendar window. Individual searches in the 'searches' field can override this per search.
Default check-out date for destination search monitoring in YYYY-MM-DD format. Example: '2026-07-03'. Must be after checkin. Individual searches in the 'searches' field can override this per search.
Number of days to scan in the AvailabilityCalendar for each property URL. Default 61 covers ~2 months in ~1 API call. Set up to 365 for a full year (splits into ~6 API calls per property). Higher values cost more compute but give wider price monitoring coverage.
Apify proxy configuration for reliable access. REQUIRED for production use — Booking.com is not reliable from datacenter IPs. Use Apify Residential proxy (useApifyProxy: true, groups: ['RESIDENTIAL']). The buyer pays proxy costs separately from PPE event charges. Without residential proxy, the actor will be rate-limited on every run.
Minimum percentage price decrease to trigger a 'price_drop' event. Default 5.0 means a 5% or larger drop emits an event. Smaller values (e.g. 2.0) are more sensitive and emit more events; larger values (e.g. 10.0) only catch significant drops. Revenue managers typically use 5–10%.
Minimum percentage price increase to trigger a 'price_spike' event. Default 5.0. Useful for monitoring competitors repricing upward, which can indicate demand increases or inventory scarcity. Setting this lower (e.g. 3.0) gives earlier warning of price trends.
Emit a 'rooms_left_low' event when a property has this many rooms or fewer remaining. Default 3. Only emits once when rooms_left crosses below the threshold (not every run). Set to 0 to disable low-rooms alerts.
Minimum Booking.com vs Kayak price gap percentage to trigger a 'parity_gap' event. Default 5.0 matches standard rate parity contract terms. Hotel chains and OTA compliance teams typically flag gaps of 5% or more as contract violations. Set higher to reduce noise on volatile markets.
When true, fetches Kayak prices for each destination and emits 'parity_gap' events when Booking.com and Kayak prices differ by parityThresholdPct or more. Default true. Kayak is fetched without residential proxy (no extra protection). Disable if you only need Booking-internal price/availability events.
Maximum number of hotels to process per destination search. Default 100. Booking.com FullSearch returns up to 1,000 results total (25 per page); higher values increase compute cost and API calls. For narrow monitoring (a single hotel's destination), 25–50 is usually sufficient.
When true, runs a schema-drift canary check at startup that asserts the WAF gokuProps format, b_csrf_token regex, and GraphQL operationNames still resolve. Emits a maintenance warning if any check fails, but does NOT abort the run. Recommended: enable in scheduled daily runs to get early warning before the actor goes red.
