π Scrape Trip.com hotels by city name or search URL: prices, star ratings, guest scores, reviews, rooms, facilities, photos, addresses. Deep pagination β ask for 1,000, get 1,000. π€ LLM- and agent-optimized: one uniform JSON row per hotel, priced per hotel, ready for RAG and MCP pipelines.
Version history for Trip.com Hotels Scraper. This is the changelog published on Apify Store.
1.6.2 β 2026-09-16
Fixed
scrapeDetails: true was returning plain search rows. Trip.com re-ordered the data blocks on its hotel pages and the actor stopped recognising the one that holds rooms, facilities, photos, description, FAQ and surroundings. Detail rows are rich again.
The detail add-on is only charged when the page actually enriched the row. A hotel whose page could not be read is billed as a plain hotel, not as a detail.
1.6.1 β 2026-09-16
Fixed
Destination searches were stopping at 12 hotels whatever maxItems said. Trip.com changed how its results list loads more hotels, and the actor was pressing the wrong "Show More" β one that opened the filter panel and froze the page. Searches now page through the full list again (100 of 100 and 1,000-hotel runs verified).
1.6.0 β 2026-09-16
Changed
Proxy settings are gone from the input. Residential rotation is built in and managed by the actor β there is nothing to configure and nothing extra to pay. The proxyConfiguration field is ignored if you still send it.
Runs can be started with 1, 2 or 4 GB of memory while smaller tiers are being measured. Keep 4 GB for destination searches; it is the only size the deep search has been validated on.
1.5.0 β 2026-09-15
Every hotel row now carries the coordinates, property type, review sub-scores and price details Trip.com already sends β and detail pages add the hotel's policies. No extra requests, no price change.
Added β on every search result
latitude / longitude (WGS84), propertyType (Hotel, Apartment, Hostelβ¦).
subScores (Cleanliness, Amenities, Location, Service), reviewSummary and reviewHighlights.
roomName and bedType of the room the price refers to.
priceBeforeDiscount, taxesAndFees, payAtHotelCharges, and a freeCancellation flag when the rate has it.
sponsored for paid placements, checkIn / checkOut / adults so every price says what stay it was quoted for, and videoUrl.
Added β with scrapeDetails: true
policies: check-in and check-out times, breakfast, pets, deposit and child rules, as plain lines.
zone, transit (nearest metro or station), openYear, brand.
reviewSnippets and recommendRate; each room in rooms now lists its in-room features.
Fixed
Deep searches were dropping landmarks, tags and awardRank that the README promised in both modes. They are back on every row.
The README's data table claimed room rates, breakfast and cancellation terms per room. Trip.com only prices rooms in the browser, per set of dates; the actor never returned them and the table now says so.
1.4.0 β 2026-08-01
Changed
Runs with scrapeDetails: true now produce results from the first seconds too. Detail pages are fetched as hotels are found, instead of after the whole search finishes. On a 1,000-hotel New York search the first row lands at 18 seconds instead of 5 minutes β sixteen times earlier β and the dataset fills steadily from there. This completes what 1.3.1 did for lite runs.
Note
This does not make runs shorter: total time is unchanged (5m48s vs 5m38s, inside normal run-to-run variation). What changes is that you can watch a run produce and start consuming rows immediately, rather than waiting for the whole search before seeing anything.
1.3.1 β 2026-08-01
Changed
Results now appear while the search is still running. With scrapeDetails: false, hotels are written to your dataset in batches as Trip.com returns them, instead of arriving all at once at the end. On a 1,000-hotel New York search the first rows land within seconds and the dataset fills steadily over the run, rather than staying empty for five minutes. You can watch a run produce, and start consuming results before it finishes.
scrapedAt is now stamped per batch rather than once for the whole run, so it reflects when each hotel was actually read.
Note
When Trip.com returns the same hotel on more than one page β about 17% of the time β the row you get is now its first appearance rather than its last. A row already written cannot be revised, which is the trade for not waiting until the end. The first appearance is also the one matching the ranking you asked for.
Runs with scrapeDetails: true are unaffected for now: those still collect the full list before fetching detail pages.
1.3.0 β 2026-08-01
Large searches are about twice as fast, and you can finally see them working.
Performance
A 1,000-hotel search went from 9m48s to 5m38s, returning the identical set of hotels. Measured end-to-end on New York, 10 nights, 4β5β , with detail pages on. Five sources of waste were removed: re-reading results already collected, a full-page scan that got slower as the list grew, fixed pauses that waited a set time instead of resuming when the next results arrived, a pause that was waiting for something that never arrives β and, the biggest by far, a search that kept going long after Trip.com had stopped returning anything new.
Detail-page fetching was already fast (592 pages in under a minute) and is unchanged.
Fixed
The run log went silent for minutes during a large search. It now reports progress every 15 seconds (π 245 hotels found so farβ¦), so a working run is distinguishable from a stuck one. A search that has to retry now says so, instead of looking like one slow attempt.
The log is no longer buried in internal chatter. Start-up banners, queue statistics and per-request bookkeeping have moved off the run log, leaving the progress narrative. Warnings and errors are untouched β anything that actually needs your attention still shows.
Note on result counts
Trip.com's own pacing varies between runs, so the same search can return a slightly different number of hotels minutes apart. Two runs of the identical build differed by 35 hotels in testing. This is the site's behaviour, not the actor's.
1.2.0 β 2026-07-31
New pricing: you now pay per hotel, and full details cost a fraction of what they used to.
Changed β pricing
Billing moved from search pages to hotels. The old serp-page event charged you per page of results, so your bill depended on how many pages the actor happened to walk β something you couldn't see or predict. There is now a single hotel event at $0.0015, charged once per hotel written to your dataset. Max items now tells you your maximum bill before you press Start.
Full hotel details are 65% cheaper. The detail add-on drops from $0.01 to $0.002 per hotel. A 100-hotel run with scrapeDetails: true goes from $1.05 to $0.35; 400 hotels goes from $4.20 to $1.40. Detail mode is now about 2.3Γ the lite price per hotel rather than 10Γ.
Volume discounts. Higher Apify plans pay less per hotel, down to $0.0008 β see the pricing table on the actor's Store page.
A new $0.00005 actor-start event, charged per GB of memory at launch β $0.0002 on a standard run.
Failed rows are still never charged, and neither are internal steps like resolving a city name.
Fixed
Hotels collected on the deep-search path with scrapeDetails enabled were never billed for the search itself, while the same hotels on the standard path were. Billing no longer depends on which path a run took.
Pasting hotel-detail URLs with scrapeDetails: false returned enriched rows without the add-on charge. The add-on is now billed whenever a detail page actually delivers the enriched fields, whatever the toggle says. If you pass detail URLs directly, expect $0.0035 per hotel rather than $0.0015.
Changed
Run memory is capped at 4 GB. The actor never needed more, and higher settings only made runs cost more without making them faster.
1.1.1 β 2026-07-31
Changed
The run log now reads as a clean progress narrative. Internal route names, page indexes, search URLs and collection counters have moved to the debug channel. What's left is what you can act on: the destination, hotels found, details queued, and how the run ended.
Quieter deep searches. A deep search reads many overlapping pages; those that contributed nothing new used to log a line each. They no longer do.
1.1.0 β 2026-07-31
Searches were quietly returning a fraction of what you asked for. This release fixes that.
Fixed
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.
Changed β output shape
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? }.
Changed
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.
1.0.1 β 2026-07-30
First stable release.
Added
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.
Changed
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.
0.4.1 β 2026-05-06
Changed
Deep collection is now gated by a maxItems threshold (default 50). Small runs take the fast path instead (~10s, 50β90 hotels); the deep path starts only when a run actually needs the extra coverage.
0.4.0 β 2026-05-06
Added
Deep search collector. Raises coverage for a large city from ~400 to 506 unique hotels in a single run. Hotel detail pages continue to use the fast path.
Fixed
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.
0.3.0 β 2026-05-05
Added
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.
Result
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.
0.2.0 β 2026-05-05
Changed
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.
0.1.0 β 2026-05-03
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.
![Expedia.com & Hotel.com [$2.5π°] Reviews/Ratings/Sentiment A. avatar](https://images.apifyusercontent.com/S3jQnQO1Qq7Evmm8G6HhWSwePurMx4mbNBaxjT2ShAg/rs:fill:76:76/cb:1/aHR0cHM6Ly9hcGlmeS1pbWFnZS11cGxvYWRzLXByb2QuczMudXMtZWFzdC0xLmFtYXpvbmF3cy5jb20vbmduOHZSRVNUa3NleVdFNnAtYWN0b3ItNkkxaEJLTk1nQk5IZVl4dUwtOXNoSm5hbnd2Ni1leC5wbmc.webp){kind=avatar}
