Airbnb Listings Scraper — Fast Issue Response

Search a location on Airbnb, get structured listing data: price, rating, reviews, host, coordinates.

Why this exists

The most-used Airbnb listings scraper on the Store has 668+ monthly users and a 172-item closed-issue history, almost all of it one repeating pattern: Airbnb's page structure shifts, the scraper throws Cannot read properties of undefined (reading 'map'), and the fix lands roughly nine days later. Not a quality problem — a diagnostics and response-time problem.

Two things are built specifically against that pattern.

Every run tells you what it actually got. Airbnb's own search page states how many listings exist for a location. Every run in this Actor compares its scraped count against that number and reports the ratio — in the RUN_STATS record, per location. If a run returns 12 of a claimed 250, you're told, not left to notice the shortfall yourself. The incumbent's most common closed issue — "Only 41 results returned when Airbnb shows 478 listings" — is exactly the failure this is built to surface instead of hide.

When extraction breaks, it says what broke. Three independent extraction strategies run in order, and every failure is logged with which strategy failed and why — "selector [data-testid='card-container'] matched 0 elements," not a bare stack trace three layers deep. When Airbnb changes shape again, whoever is fixing it gets a diagnosis, not a mystery.

What you get

Per listing: listingId, url, title, priceText, currency, rating, reviewsCount, isSuperhost, latitude, longitude, plus which location it came from and which extraction strategy produced it.

On currency: Airbnb prices in whatever currency matches the residential proxy's exit region, and it can genuinely change between runs and even between locations in the same run - one run returned Moroccan Dirham for Vilnius, Trinidad and Tobago Dollars for Tallinn, and a bare $ for Riga, all in the same three-location call. priceText always carries whatever currency marker Airbnb actually showed rather than a bare number, and currency makes it explicit: an ISO-style code (TTD, MAD) when Airbnb showed one - authoritative, since several currencies share the same symbol - or a bare symbol when it didn't, which is honestly ambiguous rather than guessed as USD. To pin a consistent currency across runs, add display_currency=USD (or your preferred code) to a full Airbnb search URL and pass that URL directly in locations - passing a full URL instead of a bare place name is already supported.

Input

Scope, honestly

v1 covers one search results page per location — Airbnb's default load, roughly 18–20 listings. No pagination yet. That's a deliberate scope choice, not an oversight: this is a genuinely new engineering surface (real browser, anti-bot, a target site that reshapes itself), and the discipline that held up building the rest of this catalogue was proving something narrow works before expanding it. Pagination is a contained addition once this has real running history behind it.

Coverage is reported, never hidden. If a location returns fewer listings than Airbnb claims exist — because of the one-page limit, a partial load, or a shape change — that shows up in RUN_STATS as a coverage ratio, not as a silent shortfall.

A suspect result gets one retry with a fresh proxy before it's accepted. Confirmed live: a completely valid, unambiguous search returned scattered, unrelated content from all over the world when it landed on a proxy IP Airbnb's anti-bot evidently didn't trust — then worked perfectly when re-run alone. Two signals now trigger an automatic retry: a suspiciously low listing count (below 5, against a healthy ~10), or titles with no geographic coherence at all (Airbnb's generic fallback content looks like this; even a loosely fuzzy-matched real result clusters around a handful of nearby places). When a retry fires, RUN_STATS records why and which attempt was kept. This roughly doubles the time and proxy cost for the specific locations it triggers on — not every run, and not most locations.

Pricing

Pay per listing scraped. An empty result fails the run rather than billing you for nothing. A retried location may use roughly double the compute and proxy bandwidth of a normal one; this is absorbed the same way all platform usage is, not passed through as a separate charge.

Limits

• One results page per location in this version (see Scope, above).
• Needs a real browser and residential proxies; this is not a lightweight Actor.
• Airbnb's page structure changes periodically. This Actor is built to diagnose that quickly when it happens, not to be immune to it — nothing scraping this site can honestly claim immunity.

For maintainers: what's verified and what isn't

The extraction logic is tested against synthetic HTML fixtures (tests/test_smoke.py) that model Airbnb's known data shape from general knowledge of how the site is built. Those tests confirm the parsing logic is internally correct. They cannot confirm the selectors or JSON keys still match the real, current airbnb.com — this was built in an environment with no network path to Airbnb, so the very first live run against the real site is the real test, not a formality.

If the first live run returns zero listings for every location, read RUN_STATS.shapeDriftEvents first — it names the exact strategy and selector that failed, which is the fastest way back to a working extractor.