Same Room, Three Prices: How Travel and Real Estate Apps Finally See What the Market Sees

Hotel rates, nightly rates, listing prices — the numbers that travel and real-estate products display vary by market, device, and session, and the teams behind those products are tired of being wrong in production. Vertical scraper APIs for the major travel and property platforms changed the economics of getting this right: structured rates from maintained targets, billed on delivery. This is the field notes version — what varies, how to collect it honestly, and what the monitoring program costs.

The Variability Nobody Warns You About

A room-night price is not a number — it’s a function. Teams building travel and property products discover the inputs the hard way:

Products that collect through one fixed session from one location get a *specific* answer and display it as *the* answer. The fix is collection that varies with the display: geo-pinned, device-aware, session-coherent.

The Collection Architecture That Survives

The major platforms are maintained-target territory. Booking.com and the major travel/property platforms sit in Thordata’s 120+ maintained scraper targets — structured records (rates, availability, property attributes) delivered as JSON/CSV/XLSX at roughly $0.50–$1.00 per 1,000 delivered results, parser maintenance and CAPTCHA handling upstream, failures $0. Zillow and the major property portals are covered the same way for the real-estate side.

The session-dependent rates need sticky sessions. Member rates and multi-step rate discovery don’t survive per-request rotation. Thordata’s residential layer supports sticky sessions up to 90 minutes with country/state/city/ASN targeting on the published slider ($2.00/GB → $0.65/GB by volume) — the collection session behaves like one coherent user, which is what rate discovery assumes.

The regional long tail rides the same slider. Boutique hotel sites and regional portals — thousands of properties, individually simple, collectively the coverage that “compare everywhere” promises. Raw residential with geo pinning; no scraping code to maintain.

The Honesty Layer: Geo-Verified Collection

The travel-specific discipline: rates collected *as the market sees them*. A Berlin rate collected through a Berlin-pinned session, a mobile layout collected with a mobile device parameter — and every record stamped with the geo and device of its truth:

def collect_rate(property_id, market, device="mobile"):
    result = client.scrape(
        scraper="booking_hotel",          # maintained target, stable schema
        query=property_id,
        geo=market,                       # collected as the market's session
        device=device,
        output_format="json",
    )
    return {
        "property": property_id,
        "rate": result["price"], "currency": result["currency"],
        "availability": result.get("rooms_left"),
        "collected_as": {"market": market, "device": device},
        "seen_at": result["created_at"],   # freshness is a field, not a hope
    }

The collected_as block is the difference between rate data and rate *claims* — every number carries the conditions of its own observation, so downstream aggregation can weight, filter, or display by them instead of averaging the conditions away.

What the Monitoring Program Costs

A mid-size comparator — 30,000 properties, 10 markets, hourly on the top 5,000, daily on the rest:

The numbers scale with the promise on your homepage; the point of the table is that every line is knowable in advance, per delivered record, with failures costing nothing — the properties that made rate monitoring a procurement nightmare are gone.

FAQ

Why not an official partner API from the platforms?
Partner APIs are real and excellent — where you can get one, and for the coverage it includes. The vertical-scraper layer exists for the other cases: multi-platform comparison, coverage beyond one partner’s inventory, and markets where partner access doesn’t extend. Mature products run partner data where available and scraper data for the rest, one schema, provenance-tagged.

How do we handle FX honestly?
Collect the currency *as displayed* with the record’s timestamp, convert downstream at the same timestamp. Baked-in conversion is the classic travel-data bug — it makes historical comparison quietly wrong and turns a rate monitor into an FX monitor by accident.

Does the real-estate side differ?
The same architecture, slower clocks: listing prices change by the day rather than the hour, so the program is daily sweeps rather than hourly polling — and the geo discipline matters even more, since a “market” in property is a metro, and metro-level collection is what Thordata’s city/ASN targeting is for. Zillow and major portals in the maintained-target set; the MLS long tail on residential collection.

What about the search side — do travel teams need SERP data too?
The demand half of the business: which destinations and properties the market is searching, seasonality by query, and where your own pages surface in a results landscape that reshuffles with every season. Structured per-response collection prices that layer at roughly $0.70–$1.20 per 1,000 — and for teams building agent features (“find me a weekend trip under $300”), Thordata’s MCP server exposes live search, request history, and usage statistics as agent tools, with 500 free calls to test the pattern.

How do we start?
One market, one platform, the top 500 properties, hourly for a week — then diff your production rates against the collected ones. The differences you find (there will be differences) are the cost of your current blind spot, measured. Expand market by market from there, and bring the agent search layer along when the product starts answering questions instead of displaying numbers.