# Changelog of 🔥 Trip.com Hotels Scraper — Prices & Reviews (`bebity/trip-com-hotels-scraper`) Actor

- **URL**: https://apify.com/bebity/trip-com-hotels-scraper/changelog.md
- **Full Actor documentation**: https://apify.com/bebity/trip-com-hotels-scraper.md

## Changelog

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.
- Residential proxy support, no browser required.