Booking.com Rate Calendar & Booking Curve
Pricing
from $0.40 / 1,000 rate row saveds
Build a price-by-date matrix for any Booking.com market: nightly rate, taxes, refundability and rank versus the market median for every property on every check-in date, plus per-date medians, quartiles and supply movement. Weekend premiums and the forward booking curve included.
Markets to scan. Type place names (Austin, Lisbon, Bali) or coordinate pairs (30.2672,-97.7431). Each destination is scanned across every check-in date you choose.
[ "Austin"][ "Austin", "Lisbon"]How to read your place names. City covers most needs; use Region for a state or province, District for a neighbourhood, and Coordinates when you pass lat,lon pairs. Coordinate pairs are always read as coordinates whatever you pick here.
First check-in date of the scan, as YYYY-MM-DD. Leave empty to start seven days from the day the run begins, which keeps scheduled runs rolling forward instead of drifting into the past.
How many consecutive check-in dates to scan, starting from the first check-in date. Each date is checked on its own, so this is the main thing that drives how long a run takes.
An explicit list of check-in dates as YYYY-MM-DD. When this is filled in it replaces the first check-in date and the horizon, which is handy for scanning only event weekends or the first of each month.
[][ "2026-09-11", "2026-09-12", "2026-10-31"]Stay lengths to price, in nights. Every extra length multiplies the whole scan, so up to four are allowed, each between 1 and 14 nights. A one-night stay gives the cleanest nightly curve.
[ "1"][ "1", "3", "7"]Keep only check-in dates that fall on these weekdays (Mon, Tue, Wed, Thu, Fri, Sat, Sun). Leave empty for every day. Narrowing to Fri and Sat cuts a 90-date scan to 26 dates.
[][ "Fri", "Sat"]Adults the rates are priced for. Party size changes which properties and rates qualify, so keep it fixed across scheduled runs.
Children travelling with the party. Add their ages below for accurate rates — Booking.com prices children by age.
One age per child, 0 to 17. When these are filled in they set the number of children too.
[][ "7", "11"]Which slice of the market each date returns. Cheapest first is the default and is pinned deliberately: the same ordering on every date is what makes the curve comparable.
How many properties to collect for each check-in date. Anything above 100 reads several slices of the market for that date.
Read as much of the market as Booking.com will show for every date. This is what makes "this property is sold out on this date" a sound answer instead of a guess — without it, a property missing from a date is simply not reported for that date. It also makes a run considerably longer.
Track a fixed comp set. Only these properties are saved, picked out of each market's results, and a date where one of them does not appear is saved with notFoundOnDate set so gaps in the curve are visible.
[][ "1344239", "517530"]Adds one row per market per date with the median, the quartiles, the cheapest rate, the share of refundable offers and how supply moved against the previous date. Costs no extra work.
Adds per-property curve figures once the scan finishes: date-over-date change, weekend premium, minimum, maximum and median rate, rate volatility, and how many dates were observed or missing.
A hard ceiling on how much scanning a single run may do. The projected amount is worked out and logged before anything starts, and a run that would exceed this stops immediately and names the setting to lower.
How many check-in dates are worked on simultaneously. Three is the balance point: higher is faster but more dates get turned away, and the run eases off automatically when that starts happening. Any date that is turned away is retried once before it is reported as missing.
Three-letter currency code every rate is reported in. It is pinned for the whole run, because a series priced in a shifting currency is meaningless.
Language for names and labels, such as en-us, en-gb, de or fr. Non-English languages are untested.