Version history for Trip.com Hotels Scraper. This is the changelog published on Apify Store.
Searches were quietly returning a fraction of what you asked for. This release fixes that.
- Search pages stopped returning results. Trip.com changed the markup of its hotel landing pages, which broke result extraction on every destination at once. A run asking for 100 hotels came back with 12 hotels and 3 error rows. Landing pages parse again, and results are now read from the page's structured data whenever the visual layout changes โ so the next redesign degrades instead of breaking.
- District pages counted as errors instead of results. Trip.com's per-district pages carry no visible hotel cards at all, so every one of them produced an error row. They now contribute their hotels. On a London test this took a single search URL from 50 hotels + 10 errors to 73 hotels and no errors.
- Duplicate hotels ate your item budget. The same hotel found through two different pages was written twice, and each copy counted against
maxItems. Results are now de-duplicated by hotel ID across every source.
- Results could come back in the wrong language. Some hotels were returned with Chinese names even on an
en-US run. Your chosen locale is now applied to every request.
city and country were empty on destination searches. Both fields are populated again, including in the Hotels output view.rooms and fullAddress were documented but never delivered. Both were listed in the output fields and shown in the example output, yet every row came back without them. Rich rows now carry the hotel's room types (name, occupancy, photo) and its structured postal address. Measured on a six-hotel London run: 6/6 hotels with an address, 53 room types, all with occupancy and 42 with a photo.
rooms entries no longer claim rate fields. basePrice, breakfastIncluded and cancellationPolicy were declared but never populated, because Trip.com loads rates separately for each set of dates rather than putting them on the page. They have been removed from the documented shape rather than left as promises. Room entries are now { name, occupancy?, photoUrl? }.
- Destination searches now reach your
maxItems. Above 20 items, a search by destination collects the full result set โ 100 requested returns 100. Below that, the run stays on the fast HTTP path, which tops out around 19 hotels for a city. The threshold used to be 50, which is what let a 100-hotel request silently return 15.
- Runs say when they cannot reach your limit. Instead of leaving you to count rows, a short run now states how many hotels it collected against what you asked for, and why.
- Higher memory requirement. Destination searches need at least 4 GB. Runs configured below that will not start.
First stable release.
- Output schema. The Output tab now shows your results directly in Apify Console, with two outputs: Hotels (successful rows) and Failed items (anything that didn't parse, with its reason). The run's API response also exposes these, so tools and AI agents calling the actor can discover what it returns.
- Documentation rewritten. Clearer explanation of how many hotels each mode actually returns, transparent per-mode pricing examples, a data-points table, and sections on legality and support.
- Corrected the documented hotel limit. Earlier docs said "10โ12 hotels per URL", which stopped being true when deep pagination shipped in 0.3.0. Actual yields: ~10โ12 per URL in lite mode, ~50โ90 for a filter search, and up to ~400 unique hotels for a large city when
scrapeDetails is enabled.
Minimum review score is now a labelled dropdown (Pleasant 6+ / Good 7+ / Very Good 8+) instead of a raw number field. Numeric values are still accepted if you call the API directly, so existing inputs keep working.
- The browser-based collector is now gated by a
maxItems threshold (default 50). Small runs skip the browser entirely and use the fast HTTP path (~10s, 50โ90 hotels). The browser only starts when the run actually needs deep coverage.
- Stealth-browser search collector (opt-in, self-hosted deployments only). Raises coverage for a large city from ~400 to 506 unique hotels in a single run. Hotel detail pages continue to use the fast HTTP path.
- Off by default: the Apify base image doesn't include the browser binary, so this is for custom-image deployments.
- Prices are now read from the correct field in Trip.com's search response, including the total price with taxes and fees. Hotel names now prefer the clean name over the parenthesised variant.
- Deep pagination without a browser. Trip.com's infinite scroll is gated behind a signed request token, so the actor works around it: it collects the 70โ110 extra hotel IDs that every search landing page already references, and explores per-district pages breadth-first.
- Geo-domain fan-out for filter searches, scaled to how many items you ask for. Different Trip.com domains return partly different hotel sets, so coverage grows.
- Raised the no-browser ceiling from ~12 hotels per URL to ~400 unique hotels for a city the size of London. Deep pagination requires
scrapeDetails to be enabled.
- Breaking input change: a top-level Search mode now selects between filter-based search and search by URL.
- Added Sort by, Meal plan and Payment option filters.
- Removed
breakfastIncluded, district, chains and landmarks โ Trip.com encodes these as city-specific IDs that change between destinations. Use search by URL mode with a URL copied from your browser instead.
- Interactive search URLs (
/hotels/list?cityId=โฆ) are now accepted.
- Filters are applied by Trip.com server-side rather than filtered after the fact, so results match what you'd see in the browser.
Initial release.
- URL-list and filter-based input.
- Lite output (search results) and rich output (detail pages).
- Pay-per-event pricing: search page + hotel detail.
- Residential proxy support, no browser required.
