Expedia hotel inventory is one of the most valuable datasets in travel tech — covering 3+ million properties across 200+ markets with real-time pricing, availability calendars, and review aggregates — but scraping it in 2026 requires a specific setup to get past Akamai Bot Manager and Expedia’s layered fingerprinting stack.
What Expedia Serves and Why It’s Hard
Expedia’s property pages render server-side HTML for SEO bots, but pricing and availability load via a separate GraphQL API (/graphql endpoint under apim.expediagroup.com). This split means a naive HTML scraper will grab stale or placeholder data while missing the live rate grid entirely.
The anti-bot stack includes:
- Akamai Bot Manager with sensor data collection (JavaScript challenge on first load)
- TLS fingerprint matching (JA3/JA4 checks on API requests)
- Cookie integrity chain:
iEV,MC1, and session cookies must be sequentially issued by Expedia’s CDN - Behavioral rate limiting at roughly 60-80 requests per 10 minutes per IP on search endpoints
The GraphQL endpoint is the target for pricing at scale. The HTML property page is the target for metadata (amenities, descriptions, coordinates).
Stack Options: Browser vs. HTTP
There are two viable approaches in 2026.
Browser-based (Playwright / Puppeteer): Handles the JavaScript challenge natively, builds valid cookie chains, and mimics real user behavior. Slower (4-8 seconds per property) and expensive at scale, but the most reliable path for getting past sensor data collection.
HTTP client with TLS spoofing (curl-impersonate, httpx + JA3 rotation): Much faster (sub-500ms per request) but requires you to replay a valid cookie chain captured from a real browser session. The cookies expire every 2-4 hours, so you need a headless refresh cycle running in parallel.
For a dataset under 10,000 properties, browser-based is fine. At 100k+ properties, you need the HTTP path with a cookie refresh loop.
If you’re already running large-scale flight data pipelines, this pattern will feel familiar — the same architecture used for How to Scrape Skyscanner Flight Data at Scale (2026) applies here with minor cookie chain differences.
Proxy Requirements
Residential proxies are mandatory. Datacenter IPs are blocked at the CDN layer before any JavaScript runs. Mobile IPs get the best pass rates on Expedia’s US and EU endpoints, typically 92-95% vs. 78-85% for residential broadband.
| Proxy type | Pass rate (Expedia US) | Cost per GB | Best for |
|---|---|---|---|
| Mobile residential | 93-95% | $10-18 | Search + pricing API |
| Residential rotating | 78-85% | $3-8 | Property metadata |
| ISP (static residential) | 70-80% | $2-5 | Low-volume monitoring |
| Datacenter | <10% | $0.50-1 | Not viable |
Geo-match your proxy to the currency/locale you’re targeting. Scraping expedia.com with a UK IP will surface GBP pricing and different inventory than a US IP hitting the same URL. For Asia-Pacific inventory, you’ll want SG or JP exit nodes — the same consideration that applies when you’re running How to Scrape Trip.com (Asia Inventory) at Scale (2026).
Extracting Pricing Data from the GraphQL API
Once you have a valid cookie chain, the pricing data comes from a POST to apim.expediagroup.com/graphql. The operation name for hotel search results is HotelSearchListingsQuery. Here’s a minimal request skeleton:
import httpx
headers = {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ...",
"Content-Type": "application/json",
"client-info": "shopping-pwa,unknown,us.en_us",
"x-page-id": "Hotel:Search",
"Cookie": "<your_captured_cookie_chain>",
}
payload = {
"operationName": "HotelSearchListingsQuery",
"variables": {
"context": {"siteId": 1, "locale": "en_US", "currency": "USD"},
"destination": {"regionId": "6054439"}, # NYC region ID
"checkInDate": {"day": 15, "month": 8, "year": 2026},
"checkOutDate": {"day": 17, "month": 8, "year": 2026},
"rooms": [{"adults": 2}],
"sort": {"selected": "RECOMMENDED"},
},
"extensions": {"persistedQuery": {"sha256Hash": "<hash>"}},
}
r = httpx.post(
"https://apim.expediagroup.com/graphql",
json=payload,
headers=headers,
timeout=15,
)The sha256Hash for HotelSearchListingsQuery changes with front-end deploys. You’ll need to scrape it from Expedia’s webpack chunks periodically (every 1-2 weeks is usually safe). Store it alongside your cookie refresh timestamp.
Expedia returns paginated results in batches of 50 properties. Paginate via the paginationInput variable (startingIndex increments by 50).
Handling Rate Limits and Errors
The most common failure modes and how to handle them:
- HTTP 403 with
akamai-errorheader — Your cookie chain is expired or the TLS fingerprint failed. Trigger a browser-based cookie refresh and retry after 5-10 seconds. - HTTP 200 with empty
data.propertySearch.propertiesarray — Rate limited at the application layer. Back off 30-60 seconds and rotate proxy. - GraphQL error
INVALID_DESTINATION— Region ID is wrong or the destination has no inventory for those dates. Validate region IDs against Expedia’s typeahead API separately. - Sudden redirect to
/captcha— IP is flagged. Retire the session, rotate to a fresh proxy, and do not retry from the same IP for at least 4 hours.
Implement exponential backoff with jitter, not fixed delays. A fixed 2-second delay between requests is easy to fingerprint as bot behavior. Randomize between 1.2s and 4.5s.
The same backoff logic is directly portable to hotel scraping on other OTAs — How to Scrape Kayak Flight + Hotel Data (2026) covers Kayak’s equivalent rate envelope in detail, and How to Scrape Hotels.com Pricing Across Markets (2026) documents how Hotels.com (also Expedia Group) shares parts of the same API infrastructure.
Structuring Your Output Schema
Expedia’s response is deeply nested. Flatten it early — don’t store the raw GraphQL blob and parse later. A clean per-property record looks like:
property_id(Expedia internal ID, stable across requests)name,star_rating,coordinates(lat/lon)price_per_night(lowest available rate for the query dates)total_price(pre-tax and with-tax variants)availability_status(available / limited / sold_out)review_scoreandreview_countcancellation_policy(free_cancellation boolean + deadline timestamp)
For competitive intelligence or dynamic pricing models, you’ll want to snapshot the same property-date combination at least 3 times per day (morning, midday, late evening). Prices on Expedia can swing 15-40% intraday on high-demand dates.
The same snapshotting logic used for product inventory monitoring — as covered in How to Scrape Best Buy Product Inventory and Pricing in 2026 — translates cleanly to hotel rate tracking when you’re thinking about time-series storage and alerting on price deltas.
Bottom Line
Expedia hotel scraping in 2026 is a two-layer problem: break the Akamai cookie chain with a browser, then feed that chain into a fast HTTP client hitting the GraphQL API at scale. Mobile residential proxies geo-matched to your target market are non-negotiable — don’t waste time trying to make datacenter IPs work. For ongoing coverage of OTA scraping patterns and proxy infrastructure, DRT publishes tested, current walkthroughs across the major travel and e-commerce data sources.