- Hotels can be given by Booking.com's own number (
hotelIds), which needs no lookup.
- A link is looked up with more care: a 25-row name search, Booking.com's autocomplete, a few phrases
made from the link's name, and the property number some pasted links carry. A candidate is accepted
only when its page name and country equal the link's. Measured on 150 hotels of 12 cities with
their numbers known, from a home address: the old five-row search found 55%, this finds 73%. On
the Apify platform, on 40 of them: 18 found before, 25 now. A link that is still not found says
so, is not billed, and points to
hotelIds.
- README: a link to the companion Booking.com Reviews Scraper.
- A hotel is no longer given up on one empty answer from Booking.com. Finding the property by
name now gets five tries, each from a fresh proxy address, and stops early only when the
answer lists other properties instead. One empty answer used to end the hotel, and with it
the whole run.
- A date whose answer was a challenge, a dropped connection, an error or an empty list is asked
once more from a fresh address before it is skipped, so such flukes no longer leave gaps in
the calendar.
First public release. Pay per event: $0.0015 per hotel and date on the free plan and on Bronze,
$0.00125 on Silver, $0.001 on Gold and above, plus the platform's $0.00005 per run and $0.00001
per stored row. The README shows what typical jobs cost with all three charges included.
First version. One row per hotel and check-in date from Booking.com's search endpoint over plain
HTTP: cheapest total and per-night price, sold-out flag, price before discount, tax-inclusion note,
rooms left, free-cancellation deadline and meal plan. Every answer is verified against the requested
property, dates and currency before it is billed.