Booking.com Rate Calendar & Booking Curve

Turn any Booking.com market into a price-by-date matrix. Name a city — or a lat,lon point — pick a first check-in date and how far ahead to look, and every check-in date is measured separately: one row per property per date with its nightly rate, taxes and fees, total, refundability, board basis, the room that was matched, and where that price sits against the market median for that exact date. On top of that you get one market row per date with the median, the quartiles, the cheapest rate, the share of refundable offers and how supply moved against the day before — and, once the sweep finishes, a forward curve per property: date-over-date movement, weekend premium, minimum, maximum, median and rate volatility. It is built for revenue managers, short-let operators, travel analysts and anyone who needs to know what a market is charging on a given night. No Booking.com account, no login, no personal details — just run it.

What you can do with it

• Read the forward booking curve. Scan the next 90 check-in dates for your city and see exactly where the market firms up, where it discounts, and how far out prices start to climb.
• Rate-shop a comp set. Pin your competitors' property ids and get their nightly price on every date alongside your own, each one ranked and indexed against that date's market median.
• Quantify the weekend premium. Fri/Sat versus Mon–Thu, per property and per market, computed for you instead of eyeballed off a chart.
• Spot compression before it shows up in your rates. The market row tracks how much supply is on sale for each date, so the nights where inventory tightens stand out days or weeks ahead.
• Price events and shoulder seasons. Pass an explicit list of check-in dates — festival weekends, the first of each month, a race weekend — and skip everything in between.
• Feed a dashboard or a warehouse. Run it on a schedule; every row carries its check-in date, weekday, lead time and collection time, so a series appends cleanly and never needs a date guessed after the fact.

What you get

Two kinds of row, told apart by recordType. A property on a date:

{
  "recordType": "propertyDate",
  "hotelId": 1344239,
  "hotelName": "Austin Motor Inn",
  "hotelUrl": "https://www.booking.com/hotel/us/austin-motor-inn.en-us.html",
  "city": "Austin",
  "countryCode": "us",
  "latitude": 30.32271,
  "longitude": -97.70762,
  "starRating": 2,
  "reviewScore": 6.4,
  "reviewsCount": 1284,
  "checkIn": "2026-09-10",
  "checkOut": "2026-09-11",
  "nights": 1,
  "leadTimeDays": 42,
  "dayOfWeek": "Thu",
  "grossAmount": 41.99,
  "pricePerNight": 41.99,
  "taxesAndCharges": 7.64,
  "totalWithTaxes": 49.63,
  "currency": "USD",
  "originalAmount": null,
  "discountPercent": null,
  "freeCancellationUntil": "2026-09-09T05:00:00Z",
  "isRefundable": true,
  "mealPlanType": null,
  "mealPlanText": null,
  "scarcityMessage": null,
  "roomsMatched": "Double Room",
  "bedrooms": 1,
  "beds": 2,
  "bathrooms": 1,
  "priceIndexVsMarketMedianOnDate": 84.3,
  "priceRankOnDate": 1,
  "pricedPropertiesOnDate": 100,
  "dateOverDateDeltaPct": null,
  "weekendPremiumPct": 4.8,
  "minRate": 41.99,
  "maxRate": 43.99,
  "medianRate": 43.99,
  "rateVolatilityPct": 2.2,
  "datesObserved": 3,
  "datesMissing": 0,
  "isAvailable": null,
  "availabilityInferenceUnavailable": true,
  "notFoundOnDate": false,
  "pricingUnavailable": false,
  "destination": "Austin",
  "destinationType": "CITY",
  "scrapedAt": "2026-09-10T08:14:02.108Z"
}

And one market row per date:

{
  "recordType": "marketDate",
  "destination": "Austin",
  "destinationType": "CITY",
  "checkIn": "2026-09-11",
  "checkOut": "2026-09-12",
  "nights": 1,
  "leadTimeDays": 43,
  "dayOfWeek": "Fri",
  "propertiesReturned": 100,
  "uniqueProperties": 100,
  "pricedProperties": 98,
  "pagesFetched": 1,
  "pagedToCompletion": false,
  "reportedMarketTotal": 298,
  "medianRate": 128.5,
  "p25Rate": 74.25,
  "p75Rate": 196.4,
  "minRate": 42.99,
  "maxRate": 612,
  "currency": "USD",
  "refundableShare": 0.75,
  "supplyChangeVsPreviousDatePct": -30.9,
  "scrapedAt": "2026-09-10T08:14:04.220Z"
}

That -30.9 is the real thing this actor is for: a live Austin sweep showed the number of properties on sale falling from 431 on the Thursday to 298 on the Friday to 268 on the Saturday, while the cheapest rooms rose. The market row makes that visible per date; the property rows tell you which properties did the moving.

Input reference

The fields below are the ones you fill in on the actor's input form.

Field	Type	Default	What it does
Destinations	list of strings	["Austin"]	Markets to measure. Place names (Austin, Lisbon) or coordinate pairs (30.2672,-97.7431). Up to 20 per run.
Destination type	select	CITY	How to read your place names: city, region, country, district, airport, landmark or coordinates. A coordinate pair is always read as coordinates.
First check-in date	date	empty	First check-in date to measure. Left empty, it starts seven days after the run begins, so a schedule keeps rolling forward.
Number of check-in dates	integer	30	How many consecutive check-in dates to measure, up to 90.
Specific check-in dates	list of strings	empty	An explicit list of dates (2026-10-31). When filled in, it replaces the first date and the horizon. Up to 90.
Lengths of stay (nights)	list of integers	[1]	Stay lengths to price, 1–14 nights, up to four of them. One night gives the cleanest nightly curve.
Only these check-in weekdays	list of strings	empty	Keep only these weekdays (Fri, Sat). Narrowing a 90-date scan to Fri/Sat leaves 26 dates and finishes far sooner.
Adults / Rooms / Children	integer	2 / 1 / 0	The party every rate is priced for. Keep it fixed between runs or the series is not comparable.
Children's ages	list of integers	empty	One age per child, 0–17. Booking.com prices children by age, so fill these in when children travel.
Result order	select	price (cheapest first)	Which slice of each market is measured. Cheapest first is pinned by default, because identical ordering on every date is what makes the curve comparable.
Properties per date	integer	100	How many properties to collect for each check-in date, up to 1,000.
Read each market to completion	boolean	false	Reads as much of the market as Booking.com will show for every date. This is what makes "sold out on this date" a sound answer instead of a guess, and it makes a run considerably longer.
Pinned property ids	list of integers	empty	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. Up to 200.
Add a market row per date	boolean	true	Adds the per-date market summary shown above.
Add forward-curve metrics	boolean	true	Adds the per-property curve figures: date-over-date change, weekend premium, minimum, maximum, median, volatility, dates observed and missing.
Maximum work per run	integer	400	A hard ceiling on how much scanning one run may do. The size of the job is worked out before anything starts, and a run that would exceed the ceiling stops immediately and names the setting to lower.
Dates at a time	integer	4	How many check-in dates are measured simultaneously. Higher is quicker but more likely to be throttled by Booking.com.
Currency	string	USD	Three-letter code every rate is reported in. Pinned for the whole run.
Language	string	en-us	Language for names and labels. Non-English languages are untested.
Country to appear to browse from	string	us	Two-letter country code for the market view to use. Rates can differ slightly by country, so keep it fixed between runs.

Output fields

Property-date rows (recordType: "propertyDate")

Field	Type	Description
hotelId / hotelName / slug	number / string	Booking.com's property id, its display name and its URL slug.
hotelUrl	link	Convenience link to the property page, derived from its slug and country.
city / countryCode / latitude / longitude	string / number	Where the property is.
neighbourhood / distanceText	string	Displayed area and distance from the search centre.
starRating / reviewScore / reviewsCount / reviewScoreWord	number / string	Star class, guest score, number of guest scores and Booking.com's word for the score.
accommodationTypeId / isNewlyOpened	number / boolean	Property type code and whether it is newly opened.
checkIn / checkOut / nights / leadTimeDays / dayOfWeek	date / number / string	The stay this price belongs to, and how far ahead of the run it is.
adults / children / rooms	number	The party the price was quoted for.
grossAmount / pricePerNight	number	Price for the whole stay, and per night — the figure that is comparable across dates and stay lengths.
taxesAndCharges / totalWithTaxes / includesTaxes	number / boolean	Charges shown as excluded from the headline price, the resulting total, and whether the headline price already includes them.
currency	string	The currency you pinned.
originalAmount / discountPercent	number	Only filled in when the pre-discount price is genuinely higher than the price charged.
priceSource	string	Whether the figure came from the property's stay price or from its cheapest matching offer.
pricingUnavailable	boolean	True when no price could be read for the property on this date. The amounts are then blank — never zero.
freeCancellationUntil / isRefundable	date / boolean	Free-cancellation deadline for the matched offer. A blank deadline means the offer is non-refundable.
mealPlanType / mealPlanText	string	Board basis included in the price.
scarcityMessage / scarcityTag	string	"Only 2 left" style badge when Booking.com shows one. Rare.
roomsMatched / roomTypes / bedrooms / beds / bathrooms	string / number	The room configuration that was priced for your party.
priceIndexVsMarketMedianOnDate	number	100 means exactly the market median for that date; 84.3 means 15.7% below it.
priceRankOnDate / pricedPropertiesOnDate	number	Where this price sat among the properties measured for that date, cheapest first.
dateOverDateDeltaPct	number	Change against the previous date on which this property was actually priced.
weekendPremiumPct	number	Fri/Sat mean against Mon–Thu mean for this property over the whole scan.
minRate / maxRate / medianRate / rateVolatilityPct	number	This property's own curve across every date scanned.
datesObserved / datesMissing	number	How many of the dates you asked for actually produced a price for this property.
isAvailable / availabilityInferenceUnavailable	boolean	Availability is only stated when the whole market was read for the date; otherwise it is blank and the second flag says so.
notFoundOnDate	boolean	True on a pinned property that did not appear in that date's results.
destination / destinationType / position	string / number	Which input produced the row and where it sat in that date's results.
actorRunId / scrapedAt	string / date	Run identifier and collection time.

Market-date rows (recordType: "marketDate")

Field	Type	Description
destination / destinationType	string	The market this row describes.
checkIn / checkOut / nights / leadTimeDays / dayOfWeek	date / number / string	The date this row describes.
propertiesReturned / uniqueProperties / pricedProperties	number	Rows seen, distinct properties among them, and how many carried a readable price.
pagesFetched / pagedToCompletion	number / boolean	How much of the market was read for this date, and whether it was read out fully.
reportedMarketTotal	number	The total Booking.com itself displayed for this search. A snapshot, not an audited figure.
medianRate / p25Rate / p75Rate / minRate / maxRate	number	Per-night rate distribution for the date.
currency	string	The currency you pinned.
refundableShare	number	Share of measured properties whose matched offer can be cancelled free.
supplyChangeVsPreviousDatePct	number	Movement in the displayed market total against the previous date for the same stay length.
actorRunId / scrapedAt	string / date	Run identifier and collection time.

Pricing

This actor is pay per event, with two charges.

• Rate row saved — $0.0004 each, $0.40 per 1,000 rows. The built-in per-result charge. It fires once for every row written to the dataset, whether that is a property on a date or a market summary for a date.
• Date scanned — $0.003 each. A charge applies each time one check-in date in one market is actually measured and its market-level summary is produced. This is the honest cost driver: Booking.com publishes no price calendar, so every check-in date has to be measured on its own, and a date costs the same work whether it comes back with a hundred properties or three.

A typical run — one market, 30 check-in dates, 100 properties per date — produces 3,000 property rows plus 30 date summaries and costs about $1.29. A 90-date year-ahead curve on a 25-property comp set costs about $1.21. Turning off the market row leaves only the per-row charge, so a pure rate feed is $0.40 per thousand rows flat.

If you set a maximum cost for a run, the actor stops cleanly as soon as that budget is spent rather than overshooting it, and it will not begin measuring a date it cannot bill for.

Limits & what this actor cannot do

• There is no Booking.com price calendar. Every check-in date is measured separately. That is why the horizon is capped at 90 dates, why each extra date and each extra length of stay makes a run longer, and why the size of the job is worked out and reported before anything starts.
• Booking.com shows at most about 1,000 properties for any one search. For a large market that is the ceiling per date, and past it Booking.com begins repeating properties it has already shown. Every date is de-duplicated, and a date stops as soon as it stops producing new properties.
• Booking.com's own market total moves between identical searches — a few units apart within minutes. reportedMarketTotal is a snapshot for comparing one date against another, not an audited count.
• "Sold out" is only reported when the whole market was read. A property that is missing from a date's results has usually just fallen out of the slice you asked for — in a live test, 12 distinct properties turned up across three consecutive dates and only 5 appeared on all three, almost entirely because the cheapest-first ordering shows a different set each day. Unless you switch on "Read each market to completion", availability is left blank and the row says so explicitly, rather than guessing.
• A named hotel cannot be priced on its own. Rates are only published inside a market's results, so a property is tracked by pinning its id and picking it out of the market. If it has no availability on a date it will simply be absent, and that date is saved with notFoundOnDate set.
• Booking.com shows one to two offers per property for your dates, not a full room list. Each row is that property's cheapest matching offer for your party, with its cancellation terms — not its room inventory.
• Prices are pinned to the currency you choose, and rates can differ slightly by the country the run appears to browse from. Keep both fixed between runs or a series is not comparable.
• Discounts are only reported when the pre-discount price genuinely differs. On live samples the two were equal on every property, so a 0% discount is never reported as a finding.
• Scarcity badges appear rarely. Treat them as a bonus signal, not a guarantee.
• A property with no readable price is saved with pricingUnavailable set and blank amounts, never a zero — a zero would read as a free room and would distort every median and index in the dataset.
• Speed depends on the size of the job and on Booking.com's own response times. No fixed throughput is promised.
• Booking.com's terms prohibit automated access. You are responsible for using the data lawfully and in line with the source site's terms.

FAQ

Do I need a Booking.com account? No. No account, no login, no personal details — enter a market and some dates and run it.

How far ahead can it look? Up to 90 check-in dates in one run, starting from any future date. For a longer horizon, run it more than once with different start dates and merge the results — each row carries its own check-in date, so a merge is trivial.

Can I run it on a schedule? Yes, and that is the intended use. Leave the first check-in date empty and it always starts seven days after the run begins, so a daily or weekly run keeps rolling forward on its own instead of drifting into the past. Keep the party size, the currency, the ordering and the country fixed and every run appends cleanly to the same series.

How do I track my own hotel and its competitors? Put their property ids in "Pinned property ids". Only those properties are saved, but each one is still ranked and indexed against the full market for that date, so you get both the comp set and its context. A pinned property missing from a date is saved with notFoundOnDate set, so gaps in the curve are visible rather than silent.

Is the data complete? For the dates and the depth you asked for, yes — but read the limits above. The big one: Booking.com will not show more than about 1,000 properties for a single search, and a property's absence from a date is not proof it sold out unless you switched on "Read each market to completion".

Why is there a market row as well as property rows? Because the market moves even when individual properties do not. The market row gives you the median, the quartiles and the change in how much supply is on sale for each date, which is what tells you a date is tightening before any single property's price has moved.

What happens if one of my destinations cannot be found? It is reported in the run log and skipped, and every other destination on your list still runs.