Hotel lookup fixed: Booking.com URLs and hotel names resolve through Booking's GraphQL AutoComplete. The old autocomplete endpoint started answering 403 to every caller on 2026-10-17, so URL and name inputs ended with no reviews (hotel ids were unaffected). Same inputs, rows and prices.
2026-10-16 — Keyword Planner and locale documentation
Validated search terminology against Google Ads Keyword Planner and Store shelves. Added localized usage guidance and bounded examples; retained existing English phrases. Clarified locale limitations where measured. No runtime, output fields, defaults, or pricing changed.
1.2 — sinceDate filter and Booking's overall score on the hotel row, 2026-10-12
Both came out of today's blind tests, where the two requests this actor lost to a rival were "only the new reviews since the last run" and "overall score and sub-scores, no review text".
sinceDate (new input, optional): an absolute date or a relative one ("1 day", "2 weeks", "12 months", "today"). Reviews published before it are never delivered or charged. In most_recent order paging stops at the first page that reaches past the date, so a daily feed reads a page or two instead of re-reading and re-billing the newest N. No memory between runs — dedupe on review_id.
Hotel row: now carries review_score (Booking's overall 1-10 score), stars and property_type, read from Booking's own property card with one free request per hotel (null when that request fails; the seven category scores and the review count are unchanged).
Everything else is unchanged: same inputs, same rows, same prices.
startUrls now accepts {"url": "..."} objects as well as plain strings (Apify's request-list shape, which agents and the Console editor produce); object entries were silently dropped before. Strings behave exactly as before.
Listing: six Sonnet testers read the card and the input form for six real requests — 4 of 6 picked this actor, 6 of 6 wrote a valid first call; the two losses went to a rival with a date cutoff and a summary-only mode. What they guessed at is now written down: the review row keys in the event text, the hotel row keys (and that the overall score is not on it) in includeHotelRow, "below 6" = maxRating 5.9, the 10,000-per-run reading limit, that there is no only-new or date filter (dedupe on review_id, cut on review_date), and that proxy and compute are included in the event price. Prices unchanged. Feature gaps the testers named, for a later release: a since-date / only-new mode and a hotel-row-only switch.
1.0 — listing and input form reworded, 2026-10-11
No behaviour, output or price changed; the same inputs return the same rows.
The input form is reordered: which hotels, how many reviews and in what order, then the two filters that cut the bill (maxRating, requireText) ahead of Booking's own filters (languages, travelerType, keyword), then the free hotel row, locale, pacing and proxy. Nothing was renamed or removed.
Every input now says what to pass, with an example, its default and what it costs.maxReviewsPerHotel states that the default 200 is up to $1 per hotel, that 0 can cost $10+ on a large hotel, that Booking's filters and maxRating apply before the cap and requireText after it; hotelIds says ids carry no name; locale says it is not a filter; includeHotelRow says how to get category ratings with one billed review.
The description names what one row is and the free hotel row's category ratings; the pricing text lists everything that is never charged, that there is no start fee, that about 4 reviews in 10 are score-only, and that a run stops at the maximum cost you set.
seo.json: native nouns (Hotelbewertungen, avis, opiniones, recensioni) in the meta description.
README: a section mapping common requests to the exact input, with the output row and the status contract.
2026-08-30
Reliability: a run that cannot act on its input — a URL from the wrong site, a name nothing resolves to, an empty target list, a number outside the documented range — now ends cleanly with the reason on the run card instead of as a failed run. Nothing is charged in either case; a blocked or throttled source still fails loudly.
Store listing: moved into the categories buyers actually browse (the old Business category has no Store page).
1.0 — 2026-08-29
First release.
Every guest review of any Booking.com property: the 1–10 score and the same score out of five, the title, what the guest liked and what they disliked (and both joined into one comment), the language it was written in, posting date, check-in and check-out dates, nights, room, traveller type, reviewer name and country, helpful votes, guest photos and the property's public reply.
Three ways in: Booking.com hotel URLs, hotel names, or Booking's numeric hotel ids. URLs and names resolve through Booking's own autocomplete and the resolved name comes back in every row; a URL, its name and its id count as the same hotel and are harvested once.
Order by most recent, oldest, highest rated, lowest rated or most relevant. Booking filters server-side by language, traveller type and keyword, so skipped reviews are never fetched or charged.
Two cost controls that filter before billing: maxRating keeps only reviews at or below a score — and reads the property lowest score first, stopping at the threshold, so a complaints feed reads only the pages that carry complaints — and requireText drops score-only reviews (about four in ten on Booking). Filtered reviews are never charged.
Free hotel row per property: name and location, Booking's seven category scores (staff, facilities, cleanliness, comfort, value, location, Wi-Fi), the review count and how many reviews each language, traveller type and season holds.
Billing: pay per delivered review row. Hotel rows, status rows, filtered reviews, properties with no reviews and failed lookups are all free.
Reliability: the actor never loads a Booking.com page (those sit behind a browser challenge); it calls the same review endpoint Booking's own review list uses, which answers plain requests on datacenter proxies. A refused or empty answer is retried on a fresh IP and, if it keeps failing, reported as an error rather than as "no reviews".
