# Changelog of Booking.com Hotel Price Calendar Scraper (`aleksandrbooking/booking-rate-calendar`) Actor

- **URL**: https://apify.com/aleksandrbooking/booking-rate-calendar/changelog.md
- **Full Actor documentation**: https://apify.com/aleksandrbooking/booking-rate-calendar.md

## Changelog

### 0.1.0 (2026-09-03)

First public release.

- One row per hotel and check-in date: nightly price, total for the stay, strikeout
  (pre-discount) price, taxes and charges, room type, cancellation and prepayment
  policy, rooms left, plus every individual offer in `offers`.
- `roomsLeft` is `null` when the booking form is at its selection ceiling of nine,
  because nine would read as an exact remaining count and it is not one.
- Sold-out dates are detected and returned as `soldOut: true`. A sold-out verdict
  requires the page to echo back the check-in date that was asked for, so a
  bot-detection page can never be sold as "no rooms left".
- A page that answers for different dates than requested is rejected rather than
  delivered. Prices for the wrong period are the quietest way to be wrong.
- Check-in today is allowed. Booking.com sells same-day, and for price monitoring
  today is the most-used date.
- Currency and language are verified in every response; mismatches are rejected and
  not charged. Twelve currencies whose Booking.com price notation has been verified.
- Prices are pinned to the tax-inclusive regime and every row states it in
  `pricesIncludeTaxes`. Booking picks that regime from the country it reads off the
  exit address: measured at one Georgian property on the same date and room, 175 USD
  from one address against 207 USD from another, the full 18% VAT apart. Both are real
  Booking prices, so nothing looks broken, and a calendar that mixes them cannot be
  compared with itself.
- Bot-detection pages, challenge stubs, delisted properties and layout changes are
  recognised and never billed; a run that collects nothing fails instead of
  "succeeding" with an empty dataset.
- Dates rejected because of a blocked session are retried with a fresh session and
  proxy instead of being silently dropped.
- Children are priced by age (`childrenAges`), the way Booking.com does it.
- Verified on hotels, hostels and guest houses in Georgia, Czechia and India;
  on apartments (Spain) only the sold-out path is covered, because the snapshot
  taken there had no availability. Measured stable at 100 dates in one browser
  session.
- Selectors can be overridden per run through the `selectorOverrides` input field,
  so a layout change on Booking.com can be worked around without a new release.
  Overrides that are not valid CSS selectors are rejected and logged, never applied.
- Long runs survive being moved between machines: counters, failed chunks and the
  list of already-delivered dates are persisted, so a move can neither lose the
  final report nor charge twice for rows that were already delivered.