Booking Scraper
Pricing
$5.00 / 1,000 results
Booking Scraper
Scrape Booking with this hotels scraper and get data about accommodation on Booking.com. You can crawl by keywords or URLs for hotel prices, ratings, addresses, number of reviews, stars. You can also download all that room and hotel data from Booking.com with a few clicks: CSV, JSON, HTML, and Excel
4.4 (10)
Pricing
$5.00 / 1,000 results
68
Monthly users
283
Runs succeeded
>99%
Response time
1.4 days
Last modified
a month ago
Check-in date set to today fails due to UTC-based past date validation
Open
I set the check-in date to today using either the relative value of 0 or by selecting today’s date with the “Absolute” option. However, the run fails with the error: “INVALID INPUT: You can't use a date in the past: YYYY-MM-DD”.
This seems to be happening because the Actor is comparing the check-in date to UTC time, which means if I'm running the task in the evening (U.S. Central Time), it believes the date is already in the past.
Could this validation be adjusted to account for timezone or allow same-day check-ins at least through 23:59 UTC?
This issue is blocking same-day scrapes from functioning reliably.
Hi, thanks for opening this issue!
I will try to investigate as to how this is handled on Booking. It seems to be very confusing to me right now from my testing, because it also looks like they are using some hard-set timezone for the available dates.
Otherwise, the suggestion with providing same-day checking might work, but we want to make sure that it will still somehow disable providing actually incorrect dates if possible. The timezone per user account is not possible, because the scraper doesn't have access to such data. And yes, the scraper's input for the dates is in the UTC timezone.
I will keep you updated here, thanks!
JFLOW
Thank you!
Hi, just a quick update. I've set up a test tonight and found out that, indeed, Booking uses a universal timezone for the check-in dates, and it looks to be the UTC timezone. I will further test it tonight, for some more hotels in other parts of the world, because so far I just used one in Europe in UTC+2 timezone.
I will let you know tomorrow with my findings. If it's in fact the UTC timezone, then we might just want to add some warning messages to the validation step to inform our users about it + to the input schema. But the core logic would stay the same.
JFLOW
Hey Lukáš, thanks for the update!
That’s actually pretty funny, I had a feeling UTC might be involved so I already built a similar workaround into our webhook logic. If the scraper is triggered after 7PM CST/12AM UTC, our system prompts the user with a message explaining that the results will reflect the next day’s availability (due to UTC cutoff). We’re using “Relative 0” and “Relative 1” for the check-in date, so we don’t run into validation failures, it’s really just about making sure the user understands what they’re seeing. I've got it set up as a keyword trigger in one of our Slack groups, so when someone types “keyword” the system checks the time and prompts them (or not) accordingly.
Out of curiosity. is the scraper pulling from the front-end site or using any backend API's? Just wondering if there's any way this UTC-based restriction could be brought to Booking.com as a feature request if enough users are impacted.
Pricing
Pricing model
Pay per resultThis Actor is paid per result. You are not charged for the Apify platform usage, but only a fixed price for each dataset of 1,000 items in the Actor outputs.
Price per 1,000 items
$5.00
