Airbnb occupancy data: what a listings snapshot can and cannot tell you

Most people searching for Airbnb occupancy data want one number per city: what share of nights got booked. That number does not exist in scraped listings, including ours. The Airbnb Listings, 6 US Cities pack carries 90,169 rows in the Inside Airbnb summary schema, and no column in it records booked nights, an occupancy rate, or anything derived from bookings. Airbnb publishes no booking data, so every occupancy figure you have ever seen attributed to a scrape was an estimate built from proxies.

This page does the honest version of that search. It lists the exact availability fields the snapshot does contain, explains why occupancy resists measurement from public data, and separates the questions a snapshot answers from the ones it cannot.

The availability and calendar fields, verified

Each of the six city files keeps the same 12 columns: id, name, neighbourhood, latitude, longitude, room_type, price, minimum_nights, availability_365, number_of_reviews, reviews_per_month, last_review. Verified against the shipped headers and the column-by-column data guide. The fields that matter for occupancy work:

The third column is the whole point. One forward-looking counter (availability_365) and three review fields are what a summary snapshot gives you. Anything more granular lives in Inside Airbnb's detailed files, which run several gigabytes per city and include a per-night calendar. This pack normalizes the summary schema instead, which is what makes six cities comparable in one query.

Why real occupancy is so hard to get

Occupancy is booked nights divided by available nights. Getting it requires knowing which nights a listing actually sold, and that data lives inside Airbnb's systems. Three public routes exist, each with a catch:

• Per-night calendar scraping. Airbnb exposes future availability per listing, so a scraper can record which upcoming nights show as open. It never shows past bookings, hosts can block nights for reasons unrelated to demand, and scraping at this scale runs into rate limits and account bans.
• Inside Airbnb's modeled occupancy. They scale review counts up by an assumed booking-per-review rate, weight by each city's typical stay length, and cap the result. The method is documented on insideairbnb.com, and so are its limits: review rates vary by market, stay lengths shift, and the published figures get revised when assumptions change.
• Commercial trackers. Firms like AirDNA sell modeled occupancy with broader coverage. Their models face the same fundamental gap: no one outside Airbnb sees the actual booking ledger.

So a single snapshot is stuck by construction. It was taken on one day, it sees forward availability, and it cannot distinguish a booked night from a blocked one. Treat anyone quoting a precise occupancy percentage from one scrape with suspicion.

What each city snapshot contains

Rows and snapshot dates from cities-index.csv, the per-city index that ships free with the sample files.

One more thing the table cannot say: row counts per snapshot are market size, not occupancy. Austin going from 11,295 rows on one date to a different count three months later tells you about supply churn, entries and exits, and registration effects. It says nothing about how full the surviving listings were.

Proxies that do work with this data

Three honest approximations, each answering a different slice of the occupancy question:

Supply tightness at the snapshot. The share of listings with availability_365 at or below 30 days shows how much inventory is effectively out of circulation, whether through bookings, host blocks, or regulation. It is a relative measure, meant for comparing neighborhoods or cities against each other, not for stating a market-wide rate.

Demand ranking by review velocity. reviews_per_month is the input Inside Airbnb's own model starts from. You can rank ZIP areas or room types by review rate as a demand signal without committing to their booking-per-review multiplier. Higher review velocity means more stays, however you scale it.

Availability consumption across snapshots. Take two snapshots of the same city a month apart and diff the availability_365 values per listing ID. A listing that dropped 25 bookable days had those days consumed by bookings, blocks, or a window shift. That diff is the closest a public dataset gets to observed occupancy, and even it cannot label the reason.

import csv
rows = list(csv.DictReader(open("airbnb-austin.csv")))
n = len(rows)
tight = sum(1 for r in rows if int(r["availability_365"]) <= 30)
print(round(100 * tight / n, 1), "% of listings at 30 bookable days or fewer")

Run that against any city file in the pack for the first proxy. The free 20-row sample CSV carries the same 12 columns if you want to test the pipeline first, and Airbnb data by city shows per-city query examples over MCP.

What this snapshot cannot answer

Being concrete about the limits: no true occupancy percentage per city, no booked-nights count for any listing, no seasonal occupancy curve, no weekend versus weekday split, and no revenue-per-listing figure. A snapshot taken on 2026-06-22 sees the world of 2026-06-22 plus 365 forward-looking bookable days that any number of things can change.

Two cases show why interpretation needs care. A listing with 10 bookable days and 75 reviews has likely converted demand into bookings, but a host could also be blocking the calendar. A listing with 89 bookable days, a 30-night minimum, and zero reviews reads as regulated or seasonal rather than booked out. In markets like New York City, where 42 percent of rows are private rooms after the city's registration rules, regulation explains low availability more than demand does.

If you need modeled occupancy percentages, Inside Airbnb publishes its own estimates per city with the methodology attached, and the next step up is commercial trackers. This pack's job is the reproducible layer underneath: one clean schema, per-city files, verified snapshot dates, and enough structure to build your own proxy on top.

Get the snapshot data

Full pack: 90,169 rows, one CSV per city, data dictionary, methodology, source checksums. The availability fields above ship in every file.

More from the catalog

• Airbnb data by city: rows, snapshots, and room mix for all six markets, one query per city
• Airbnb price data: mean and median nightly rate per city, and why the two differ
• Inside Airbnb alternative: what the 6-city pack adds over the raw per-city files
• Airbnb rental analysis: a worked market screen with limits and disclaimers
• For agents: endpoint docs and worked examples

FAQ

Does this Airbnb dataset include occupancy data?

No. The 6-city pack ships the Inside Airbnb summary schema, 12 columns per listing, and none of them records booked nights or an occupancy rate. The one calendar field is availability_365, the number of bookable days for the next 365 days from the snapshot date. Occupancy has to be inferred from proxies or measured with repeated snapshots.

Can I estimate Airbnb occupancy from availability_365?

Only partly. A listing showing 10 bookable days out of 365 is either booked most nights, blocked by the host, or held back by rules like a 30-night minimum. One snapshot cannot separate those cases. What works: compute the share of listings with availability_365 at or below a threshold as a supply-tightness signal, and compare the same listing IDs across two snapshots of the same city to see availability actually being consumed.

How does Inside Airbnb estimate occupancy?

With a reviews-based model, documented on insideairbnb.com. Bookings leave reviews at an assumed rate, so they scale review counts up by a booking-per-review factor, weight by each city's typical stay length, and cap the result. Those assumptions are the model's weak point: the published occupancy figures carry real error bars and get revised when the assumptions change. This pack ships their summary schema without those estimates.