Airbnb Market Tracker — Occupancy, ADR & Booking Pace avatar

Airbnb Market Tracker — Occupancy, ADR & Booking Pace

Pricing

from $3.00 / 1,000 tracked rows

Go to Apify Store
Airbnb Market Tracker — Occupancy, ADR & Booking Pace

Airbnb Market Tracker — Occupancy, ADR & Booking Pace

Track Airbnb markets over time. Diffs each listing's availability calendar day over day to surface booking pace, lead time, an occupancy proxy and true ADR from real quotes, per listing and rolled up per market. No browser.

Pricing

from $3.00 / 1,000 tracked rows

Rating

0.0

(0)

Developer

SignalBench

SignalBench

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

4 days ago

Last modified

Categories

Share

Listing scrapers tell you what exists. This one tells you what changed, and what it implies about the market.

Run it on a schedule. Every run reads each listing's availability calendar and diffs it against the last run. Nights that flipped from available to unavailable came off the market — and that single diff produces the numbers STR operators actually pay for.

What you get

Per listing, per day

FieldMeaning
nightsTakenSinceLastThe exact dates that came off the market since the last run
takeRatePerDayNights taken per day elapsed — booking pace
avgLeadTimeDaysHow far ahead those nights sit — are they filling next week or next season?
unavailableShare30/60/90Share of the forward window that's blocked — the occupancy proxy
adr, adrDelta, adrPctChangeTrue nightly rate from a real quote, and how it moved
nightsReleasedSinceLastCancellations, or a host reopening dates
reviewCountDelta, ratingDeltaReview velocity and rating drift
badgesGained / badgesLostSuperhost and Guest Favorite changes

Per market, per day

activeListings, newListings, delistings, medianAdr with adrP25/adrP75, medianUnavailableShare30/60/90, totalNightsTaken, bookingPaceIndex, medianLeadTimeDays, superhostShare, guestFavoriteShare, medianMinNights, and the day's topMovers.

Real output from a single run, two Tennessee markets:

MarketListingsMedian ADRP25–P75Blocked (30d)
Chattanooga, TN9$270$167 – $56863%
Gatlinburg, TN5$1,056$1,000 – $1,11287%

That contrast — a city market against a resort market — is the shape of the signal.

About that ADR

Airbnb publishes no per-night price anywhere on a listing page or in its calendar. The only honest nightly rate is one taken from an actual quote, so with pricing: "exact" the Actor prices a real stay and reads back the true nightly rate, the fees and the taxes a guest would pay.

Because it quotes a real stay, keep priceProbeStayNights and priceProbeLeadDays constant across runs — change them and your ADR time series stops being comparable. A fully-booked listing with no open window returns adr: null; listingsWithPricing tells you how many listings the market's ADR figures are actually based on.

The one thing you must not oversell

A blocked night is not proof of a booking. A host closing dates for their own use is indistinguishable from a guest booking them — Airbnb exposes nothing that separates the two. That's why every field here is named for what it measures: nightsTaken, not "nights booked"; unavailableShare, not "occupancy"; bookingPaceIndex, not "bookings per day".

Directionally these track real demand well, and across a whole market the host-blocking noise largely averages out. Just don't put "occupancy: 87%" in front of a client as a fact.

Cold start

The first run is worth nothing. It has nothing to diff against, so every delta comes back null and hasComparisonBaseline is false — deliberately null rather than zero, because zero would read as "nothing moved".

Value accrues from run two onward. Schedule it daily and let it build. Pickup curves and seasonal patterns need weeks of history that cannot be backfilled — Airbnb does not publish the past.

Cost control

Each tracked listing costs 2 requests (page + calendar), or 3 with pricing: "exact". Multiply that by your listing count and your schedule before pointing it at a whole city.

The levers that actually cut cost: forwardWindowDays (90 is plenty for near-term pace; 365 is for seasonality work), maxListingsPerMarket, and turning pricing off on runs where you only need availability.

A note on the ceiling: Airbnb publishes twelve calendar months starting from the first of the current month, so asking for 365 nights returns whatever remains from today — around 355 mid-month, rising back to 365 on the 1st. That is Airbnb's limit, not a truncation bug.

Measured throughput: 60 listings with pricing on (about 180 requests) completed in roughly three minutes with no rate limiting.

Stable cohorts

Airbnb reshuffles search results constantly. If the tracked set were re-derived from search every run, listings would drop in and out, day-over-day deltas would compare different properties, and ordinary ranking churn would show up as delistings.

So once a listing enters your tracked set it stays measured, whether or not today's search returns it (trackKnownListings, on by default). isDelisted is only ever set when the Actor asked Airbnb for that listing directly and got nothing back.

Storage

Alongside the run's own dataset, history is mirrored into named datasets that accumulate across runs — str-snapshots, str-movers, str-markets — and the diffing state lives in the str-state key-value store. Mirrored rows are never charged; only the run's own dataset is. Use separate stateStoreName values to track separate cohorts independently.

Comp sets

includeCompSet attaches the nearest similar-sized listings from the same tracked market, with their ADR and occupancy proxy.

To be clear about provenance: this is a comp set this Actor derives from your tracked market by proximity and bedroom count. Airbnb's own similar-listings carousel did not render on any listing sampled in September 2026, so there is no vendor comp set to read. The output labels it compSetSource: "derived-from-market" so nobody downstream mistakes it for Airbnb's opinion.

Keeping working when Airbnb deploys

Airbnb's internal API uses persisted queries whose hashes rotate on every deploy. Nothing here is hard-coded and trusted: at the start of each run the Actor re-reads the operation-name → hash map from Airbnb's own JS bundles and adopts what it finds. The run summary reports which hashes were confirmed, which had rotated, and which could not be verified. An operation that can't be resolved degrades to a null field rather than silently returning wrong data.

Pricing

$3.00 per 1,000 rows, pay-per-event. One stored row — a snapshot, a delta, or a market rollup — is one charge. Listings that return nothing are never stored and never billed.

Responsible use

Airbnb's Terms of Service prohibit scraping; read them and decide for yourself. This Actor stays off the paths robots.txt disallows — it never touches /calendar/, /book/, /manage-listing or the disallowed /rooms/*/ sub-pages, reading availability through the same public API the listing page itself calls. Note that robots.txt does disallow /s/*/*, the search path used to discover listings in a market; listingIds mode avoids it entirely.

Requests are paced and retried politely. Tracking runs are large and repeat daily, so raise politenessDelayMs rather than risk rate limiting.