Hopper is a machine-learning bet on where fares are going, wearing the skin of a friendly app. Behind the push notifications telling you to buy now or wait is a fare-collection operation of staggering size: it reads hundreds of billions of prices a month and models them to forecast the next move. That matters to a data team in two ways. If you want to read Hopper, it is a mobile-first product with app-side defenses. And if you want to build anything like it, you have to solve the same problem Hopper solved first, which is getting continuous fare data from the sources, and that is exactly what proxies are for.
We run a proxy network, and this kind of work reaches us from fare-prediction startups, travel-data teams and analysts. This page covers what is specific to Hopper: the data engine underneath it, why building a rival is a collection problem, how to read Hopper itself, and which proxy setup fits. The sources you would actually collect are covered in proxies for Google Flights and proxies for Skyscanner, and the sector background is in travel fare aggregation.
What proxies are best for Hopper?
For reading Hopper, which is mobile-first, mobile and residential proxies with a mobile user agent match the app's own traffic. For building a Hopper-style dataset, rotating residential proxies pinned per market and driven by real browsers, because the value is in the underlying airline and OTA fares. Datacenter ranges are challenged on the sources that matter. A static ISP exit fits any logged-in flow.
The engine underneath the app
The number that explains Hopper is the volume of data it consumes. Hopper analyzes roughly 300 billion flight prices every month, using machine learning to forecast future prices, and claims its predictions are accurate to within a few dollars for flights up to a year in advance (Toolify, how Hopper predicts flight prices). It is a data-driven, mobile-first online travel agency that optimizes billions of price points daily across airlines, hotels and rentals (Little Hotelier, how Hopper works).
Hopper is a fare-collection operation first
- ~300B/month
- Flight prices modeled
- to within a few $
- Prediction claim
- mobile-first OTA
- Platform
machine learning
up to a year out
app-side defenses
Source: Toolify and Little Hotelier on Hopper's data and model
The takeaway is that Hopper is not magic, it is measurement at scale. The prediction quality comes from the size and freshness of the fare data feeding the model, which is the part a rival has to reproduce before any modeling starts.
Building a rival is a collection problem
If your goal is a price-prediction or drop-alert product of your own, the modeling is the visible part and the collection is the hard part. A model is only as good as the fares it learns from, and those fares live on the airline and OTA sites, priced by market and moving constantly. So the real project is a continuous, multi-market fare-collection pipeline: read the routes and dates you cover, from each market you serve, often enough to catch the movement, without the sources treating you as a bot.
That is the job we describe across the travel series, and it is why a prediction startup is a proxy customer before it is anything else. The sources are defended (Akamai on the airlines, PerimeterX on Skyscanner, the unusual-traffic wall on Google), the prices are geo-specific, and the volume is high, which is precisely the combination residential proxies exist to handle. Collect the raw fares the way travel fare aggregation lays out, and the dataset that feeds a model falls out of it.
Reading Hopper itself
If instead you want to read Hopper, remember it is mobile-first: its predictions are delivered through the app, so the traffic that looks native is a mobile connection with a mobile user agent. A mobile proxy plus a matching client reads that world more convincingly than a desktop browser pretending to be a phone. Bear in mind that Hopper's predictions are a product it sells, so reading them at scale runs against its terms and meets its app-side defenses, and the more durable path is collecting the underlying fares yourself rather than lifting Hopper's output.
Which proxy type fits: residential, datacenter, ISP, or mobile
Datacenter proxies are challenged on the airline and OTA sources and do not match a mobile app's traffic. Keep them for parser development on saved pages.
Rotating residential proxies are home connections from a pool, pinned per market, the workhorse for collecting the underlying fares (background in what is a residential proxy).
Mobile proxies are carrier addresses shared by many handsets, the right match for reading a mobile-first product like Hopper and for the most defended source runs.
ISP proxies are static residential addresses for any logged-in flow.
| Job | Proxy type | Why |
|---|---|---|
| Collecting the underlying airline and OTA fares | Rotating residential, market-pinned | The data a model needs; sources are geo-priced |
| Reading Hopper the mobile app | Mobile, mobile user agent | Matches the app's own traffic |
| Continuous multi-market refresh | Rotating residential at volume | Prices move; the pool spreads the reads |
| Parser development | Datacenter or free list | Saved pages, nothing at stake |
Free versus paid for Hopper
A free proxy is a shared datacenter address that neither survives the defended fare sources nor matches a mobile app. A single manual check is free to try on our free proxy list and proxy checker. For a continuous collection pipeline, paid residential and mobile are the floor; ours start at $0.44/GB pay-as-you-go with no KYC.
Setting it up
Decide which job you are doing. To build a dataset, stand up a continuous collection pipeline over the airline and OTA sources, rotating residential IPs per market behind real browsers (Playwright, Puppeteer), with a refresh cadence per date band because near-term prices move fastest. To read Hopper, use a mobile exit and a mobile user agent so the traffic matches the app. Hold a sticky ISP exit for logged-in flows; the split is in rotating vs static residential proxies.
How many IPs, and how fast
Sizing (a Hopper-style dataset, rotating residential):
searches/cycle = routes x dates x markets, across the source sites
cadence = near-term dates read far more often than far dates
per address = a few searches, then rotate
The collection is the product. The pool spreads the volume.
Our pricing is per gigabyte with no expiry, so a prediction pipeline pays for the fares it actually reads.
Staying effective with Hopper-style work
- Collect the sources, do not lift the output. A model on your own fares is durable; scraping Hopper's predictions is not.
- Match mobile with mobile. Reading a mobile-first app wants a mobile exit and user agent.
- Refresh by date band. Near-term fares move fastest; spend the reads there.
- Drive real browsers on the sources. Akamai and PerimeterX score the client, per avoiding IP bans while scraping.
- One search per address, then rotate.
The limits worth knowing
Proxies give a fare-collection pipeline trusted addresses in each market and spread the volume so the sources see travelers. They do not build the model for you, they do not make Hopper's proprietary predictions yours to take, and they do not change anyone's terms of service. The value a prediction product creates is in the data it collects and the model it trains, and proxies are what make the collection possible.
A one-off manual check runs free on our free proxy list and proxy checker. For a continuous fare-collection pipeline behind a prediction product, rotating residential at $0.44/GB pay-as-you-go per market, with mobile where a mobile app is the target, is what feeds it.
Sources
- Toolify, how Hopper predicts flight prices, on the ~300 billion prices a month and the prediction claim.
- Little Hotelier, how Hopper works, on Hopper as a data-driven, mobile-first OTA.