DEV Community: elliott maqy

How to build an Airbnb price tracker with Python

elliott maqy — Fri, 23 Oct 2026 18:51:52 +0000

If you rent out an apartment, the useful question is rarely "what is the average price in my city". It is "what are the listings a guest would compare with mine asking for the dates I still have open, and did they move overnight". An Airbnb price tracker answers that by repeating the same search every day and keeping only what changed. This tutorial builds one in Python with the Airbnb price tracker mode of the Airbnb Listings Scraper, an Apify Actor called through the official Python client: a daily search for one stay that flags every listing as new, changed or unchanged since the previous run, with the previous total and the difference.

What you need

An Apify account (the free plan is enough to try this).
Your API token, from Apify Console → Settings → API & Integrations, exported as an environment variable: export APIFY_TOKEN=...
Python 3 and two packages:

pip install "apify-client>=3,<4" pandas

Step 1: pick the stay you care about

Airbnb prices are prices of a stay, not of a listing: the same apartment costs one thing for a Tuesday in February and another for New Year's Eve. The Actor offers two ways to pin the stay.

Fixed dates (checkIn, checkOut): the tracker follows the total price of that exact stay until it happens. This is the right choice for peak dates you are pricing now.
A relative stay (checkInDaysFromNow, nights): each run searches the stay that starts N days later. The tracker follows the price at a constant lead time ("a 3-night stay starting in 30 days"), and the schedule never expires.

Without any date, Airbnb proposes its own stay for each listing and the prices are not comparable. For tracking, always give dates.

Step 2: the input

The public task "Monitor Airbnb prices in Lisbon daily" watches the 60 first Lisbon listings for two adults in euros, and its description says to add your own dates. Here they are, for three nights over New Year's Eve, with onlyChanges so that later runs return only what moved:

run_input = {
    "location": "Lisbon, Portugal",
    "checkIn": "2026-12-30",
    "checkOut": "2027-01-02",
    "adults": 2,
    "currency": "EUR",
    "maxResults": 60,
    "monitorPrices": True,
    "onlyChanges": True,
    # Closer to your competitors: "roomTypes": ["entire_home"], "minBedrooms": 2,
}

The fields not shown keep the Actor's defaults (airbnb.com, English). With monitorPrices on, maxResults is the number of listings compared by each run. "Lisbon" is a whole city; your competitors are a neighbourhood and a size. Add the Actor's own filters (roomTypes, minBedrooms, priceMin / priceMax per night), or set the map area on Airbnb in your browser and pass the search URL in startUrls: filters that have no field in the input are kept, and the dates, guests and currency of the input are applied on top.

Step 3: the tracker script

The Actor stores the total price of every compared listing in a key-value store of your Apify account (airbnb-price-monitor by default, set by monitorStoreName), one record per search. Because the reference lives in your account, the script below can run from cron on any machine. Save it as track_airbnb.py:

import os

import pandas as pd
from apify_client import ApifyClient

HISTORY = "airbnb-lisbon-nye.csv"

run_input = {
    "location": "Lisbon, Portugal",
    "checkIn": "2026-12-30",
    "checkOut": "2027-01-02",
    "adults": 2,
    "currency": "EUR",
    "maxResults": 60,
    "monitorPrices": True,
    "onlyChanges": True,
}

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("myth84/airbnb-listings-scraper").call(run_input=run_input)
status = getattr(run.status, "value", run.status)  # SUCCEEDED, FAILED, TIMED-OUT...
if status != "SUCCEEDED":
    raise SystemExit(f"The run ended as {status}: open its log in Apify Console.")
rows = list(client.dataset(run.default_dataset_id).iterate_items())

if not rows:
    print("Nothing moved since the previous run.")
    raise SystemExit(0)

for item in rows:
    if item["changeType"] == "price_changed":
        print(f'{item["title"]}: {item.get("previousPrice")} -> {item["priceTotal"]} '
              f'{item["currency"]} ({item.get("priceDeltaPercent")} %) {item["url"]}')
    else:
        print(f'new: {item["title"]}, {item.get("priceTotal")} {item["currency"]}')

df = pd.DataFrame(rows)
df.to_csv(HISTORY, mode="a", header=not os.path.exists(HISTORY), index=False)

The first run of a search is the reference: every listing comes back with changeType set to "new". From the second run on, with onlyChanges, the dataset holds only the listings that were not in the record and the listings whose total changed, with previousPrice, priceDelta and priceDeltaPercent. Only those rows are saved and charged. A morning where nothing moved gives a successful run with an empty dataset; every other empty run fails with an explicit message in its log, so a misspelt location never passes for a quiet market.

The compared price is priceTotal, the total of the stay shown on the card after Airbnb's discounts. On airbnb.com that total may exclude taxes; on European Airbnb sites (set domain to www.airbnb.fr, www.airbnb.de and so on) it is the regulated total including taxes and fees, itemised in taxesAndFees. Pick one site and keep it.

Step 4: what a host reads in the history

After a couple of weeks, the CSV tells a story. Count the moves per morning and put your own total next to the market:

import pandas as pd

MY_TOTAL = 620  # your own total for the same stay, in EUR

history = pd.read_csv("airbnb-lisbon-nye.csv")
history["day"] = history["scrapedAt"].str[:10]
history["move"] = "new"
history.loc[history["priceDelta"] < 0, "move"] = "drop"
history.loc[history["priceDelta"] > 0, "move"] = "rise"
print(pd.crosstab(history["day"], history["move"]))

first_day = history[history["day"] == history["day"].min()]
print("Market median on day one:", first_day["priceTotal"].median(), "| mine:", MY_TOTAL)
print(history[history["move"] == "drop"].nsmallest(5, "priceDeltaPercent")[["day", "title", "priceDeltaPercent"]])

The first day is the full reference set, so its median is the market level when you started. After that:

What you see	What it usually means
Several drops on the same morning, weeks before the stay	competitors cutting prices for dates that are not filling
Rises concentrated in the last days	the remaining supply is getting scarce
A steady trickle of `new` rows	listings appearing for those dates: new supply, or hosts opening those dates
`priceBeforeDiscount` on a changed row	the drop is a discount with a strike-through price, not a new base price

Step 5: schedule it

With cron, one line runs the script at 7:00 every day (make sure APIFY_TOKEN is set in the cron environment):

0 7 * * * cd /path/to/tracker && python3 track_airbnb.py >> tracker.log 2>&1

Without code: open the public task in Apify Console, add your dates, tick onlyChanges, save it as your own task and give it a daily schedule; the Changes view of the Output tab shows the change type, the totals and the difference. To watch several peaks, make one task or script per stay; they can share the same monitorStoreName, since each search has its own record.

Honest limits

The tracker watches a search, not a list of listings. The compared set is the first maxResults listings, and Airbnb reshuffles its ranking between sessions. A listing that drops out and comes back is not reported as new: its last price is kept for 90 days.
No "booked" signal. A listing that disappears produces no row; it may be booked or just ranked lower that morning.
Same stay and currency only. A total is compared with a previous total for the same dates and currency.
A bad run never erases your reference. A failed or interrupted run does not overwrite the record.
No personal data. Rows hold listing facts, the average rating and the review count; nothing about hosts or guests.

Pricing is pay-per-event: a fixed price per listing saved (see the Pricing tab of the Actor), and with onlyChanges only the new and changed listings count. Use the data for analysis, respect the platform's terms and local law, and do not republish listings.

Disclosure: I build these Actors and may earn a commission if you sign up to Apify through these links.

Compare hotel prices on Booking.com, Expedia and Agoda with Python

elliott maqy — Fri, 23 Oct 2026 06:44:28 +0000

You want to compare hotel prices on Booking.com, Expedia and Agoda for the same stay, and you want it in a DataFrame rather than in three browser tabs. The catch is not getting the data, it is that each site means something different by "price": Booking.com shows a total before the charges it lists as excluded, Expedia a total with taxes and fees included, Agoda both. This tutorial runs three Apify Actors that share one output schema, the Booking.com Hotels Scraper, the Expedia Hotels Scraper and the Agoda Hotels Scraper, then builds an all-in price per night and the cheapest site for each hotel in about forty lines of Python.

What you need

An Apify account and its API token, from Console → Settings → API & Integrations, exported as APIFY_TOKEN.
Python 3 and two packages:

pip install "apify-client>=3,<4" pandas

The three Actors return the same column names in the same order (title, pricePerNight, priceTotal, priceBeforeDiscount, taxesAndFees, rating, reviewCount, latitude, longitude, url…), with a platform column that says where each row comes from. That is what makes a single DataFrame possible.

Step 1: one stay, three inputs

Keep the stay identical everywhere: Lisbon, three nights starting in 30 days, two adults, one room, prices in US dollars. The inputs below come from three public tasks: "Hotels in Lisbon for a weekend, prices in EUR" on Booking.com (hotels only, through Booking.com's ht_id=204 filter), "Hotels in Lisbon for a long weekend, prices in USD" on Expedia and "Cheapest hotels in Lisbon next month, prices in USD" on Agoda. Two values are aligned on purpose: the Booking.com task uses two nights and euros, so the script sets three nights and USD on all three.

Relative dates (checkInDaysFromNow, nights) are convenient because a scheduled script never expires; for a one-off quote, replace them with checkIn and checkOut in YYYY-MM-DD on the three inputs.

Step 2: run the three Actors

import os
import re
import unicodedata

import pandas as pd
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])

stay = {"checkInDaysFromNow": 30, "nights": 3, "adults": 2, "currency": "USD", "maxResults": 60}


def fetch(actor, run_input):
    run = actor.call(run_input=run_input)
    return list(client.dataset(run.default_dataset_id).iterate_items())


booking = fetch(
    client.actor("myth84/booking-hotels-scraper"),
    {"location": "Lisbon, Portugal", "destId": -2167973, "filters": "ht_id=204", **stay},
)
expedia = fetch(client.actor("myth84/expedia-hotels-scraper"), {"location": "Lisbon, Portugal", **stay})
agoda = fetch(client.actor("myth84/agoda-hotels-scraper"), {"location": "Lisbon", "sortBy": "PRICE_ASC", **stay})

for item in booking[:3] + expedia[:3] + agoda[:3]:
    print(item["platform"], item["title"], item.get("priceTotal"), item["currency"])

Each call waits for its run to finish, then reads the run's dataset. The fields not given keep each Actor's defaults. Each row is one property with the stay dates, the prices, the rating on 10, the number of reviews, coordinates and a link that opens the property with those dates.

Step 3: what each site puts in the price columns

This is the part to read twice. Real rows from the three Actors for Lisbon, 20 to 23 November 2026, two adults (three different properties: the point is the conventions, not the amounts):

Column	Booking.com	Expedia	Agoda (default `priceView`)
`priceTotal`	637.43 EUR, before excluded charges	582 USD, taxes and fees included	84.06 USD, taxes and fees included
`taxesAndFees`	62.25 EUR, the excluded charges	`null` (not itemised)	17.43 USD, the difference for the stay
`pricePerNight`	212.48 EUR, average per night	174 USD, the card's nightly price	28.02 USD, cheapest offer per night
`priceBeforeDiscount`	strike-through total	`null` unless a deal	strike-through price per night

So the comparable number is an all-in total: priceTotal + taxesAndFees on Booking.com, priceTotal as is on Expedia, and priceTotal as is on Agoda with its default priceView (inclusive). Then divide by nights:

df = pd.DataFrame(booking + expedia + agoda)
df = df[df["priceTotal"].notna()].copy()

df["allInTotal"] = df["priceTotal"]
on_booking = df["platform"] == "booking"
df.loc[on_booking, "allInTotal"] += df.loc[on_booking, "taxesAndFees"].fillna(0)
df["allInPerNight"] = (df["allInTotal"] / df["nights"]).round(2)

print(df.groupby("platform")["allInPerNight"].describe()[["count", "50%", "min", "max"]])

Agoda returns properties sold out for the dates with isAvailable false and empty prices rather than dropping them; the filter on the second line sets them aside.

Step 4: match the same hotel across sites

The three sites use their own identifiers, so platformListingId does not join across platforms. Exact names after normalisation catch chains and most independent hotels:

def name_key(title):
    text = unicodedata.normalize("NFKD", title).encode("ascii", "ignore").decode().lower()
    text = re.sub(r"\b(hotel|hostel|lisbon|lisboa|the|by|and)\b", " ", text)
    return " ".join(re.findall(r"[a-z0-9]+", text))


df["nameKey"] = df["title"].map(name_key)
prices = df.pivot_table(index="nameKey", columns="platform", values="allInPerNight", aggfunc="min")
prices = prices.dropna(thresh=2)
table = prices.join(pd.DataFrame({
    "cheapest": prices.idxmin(axis=1),
    "spread": prices.max(axis=1) - prices.min(axis=1),
}))

print(table.sort_values("spread", ascending=False).head(15))
table.to_csv("lisbon-hotels-3-sites.csv")

For the rest, latitude and longitude are present on all three: two rows within about 50 metres with a similar name are almost always the same property. starRating is a useful sanity check where the site shows it (Booking.com and Agoda do; Expedia carries it on expedia.fr in EUR, not on expedia.com in USD).

The result has one line per hotel found on at least two sites, its all-in price per night on each, the cheapest site and the gap. For a traveller it is a shortlist; for a hotelier it is a rate-parity check of their own property against the three sites.

Without code

Each input is also a task in Apify Console: open the public task of each Actor, adjust the stay, save it, and add a Schedule that runs the three at the same hour. Each run's Output tab exports CSV, JSON or Excel with the same columns, so the matching above also works in a spreadsheet.

Honest limits

Several cities, one stay from the form. On each Actor, locations takes up to 50 destinations in one run, all with the same dates, guests and currency, and maxResults applies to each destination. Search URLs copied from the site (startUrls on Booking.com and Expedia, searchUrls on Agoda) are one search each and keep their own dates.
Different depths and filters. About 1,000 properties per search on Booking.com, about 500 on Expedia, thousands on Agoda. The Booking.com input keeps hotels only; Expedia and Agoda also list apartments and guest houses, which simply do not match.
Sort orders differ. Booking.com's price and Expedia's PRICE_LOW_TO_HIGH are exact; Agoda's PRICE_ASC sorts on the price before taxes.
Search cards are a subset. Amenities, room details and full cancellation terms are not in search results.
Currencies follow the site. Expedia is USD on expedia.com and EUR on expedia.fr. Never mix currencies in one column; filter or convert on currency first.
Rankings move between sessions on all three sites; use the sorted orders when position matters.
Property facts only. The rows hold the average score and the number of reviews, nothing about guests or reviewers.

Pricing is pay-per-event on each Actor, a fixed price per property saved; the Pricing tab of each Store page has the current rates. Use the data for analysis, respect the platform's terms and local law, and do not republish listings.

Disclosure: I build these Actors and may earn a commission if you sign up to Apify through these links.

A short-term rental market study for one city, from Airbnb search results to a spreadsheet

elliott maqy — Thu, 22 Oct 2026 06:40:32 +0000

You want to know what a two-bedroom apartment rents for in Lisbon in November, how entire homes compare with private rooms, and whether "Guest favorite" listings charge more. Airbnb shows you all of this, eighteen cards at a time, with a ranking that changes every time you reload. Reading it by hand does not scale past the first page. Here is how I do it with the Airbnb Listings Scraper, an Apify Actor that turns a search into one flat row per listing, without collecting anything about hosts or guests.

The question before the tool

A market study is only as good as its question. Three examples that work well with search data:

Benchmark for a host or property manager: what do comparable listings (same area, same size, same dates) charge per night, and where does my listing sit in that distribution?
Investor screening: how many entire homes are listed in a neighbourhood, at what price and with what review volume?
Seasonal pricing: how does the median nightly price for a fixed stay move when you run the same search every week?

All three need the same thing: a fixed stay (dates and guests), a fixed currency, and enough listings to compute a distribution rather than a handful of anecdotes.

Step 1: run the search

The input below is the one behind the public task "Entire homes on Airbnb in Lisbon". It asks for entire homes only, in euros, for two adults, and stops at 50 listings. Without dates, Airbnb proposes a one-week stay per listing, which is fine for a first look.

{
  "location": "Lisbon, Portugal",
  "adults": 2,
  "roomTypes": ["entire_home"],
  "currency": "EUR",
  "maxResults": 50
}

The fields not shown keep the Actor's defaults. For a real benchmark, add checkIn and checkOut so that every row describes the same stay, and raise maxResults to 300 or more. The Actor keeps one browsing session per search for a consistent ranking, removes duplicate listings, and stops exactly at the number you ask for, so the cost of a run is known before you start.

The Actor is pay-per-event: you pay a fixed price per listing saved, nothing else. A few hundred listings take a couple of minutes.

Step 2: look at one row

Every row has every column, in the same order, run after run. Here is a real row from a Lisbon search on airbnb.com (USD, 20 to 23 November 2026, two adults), shortened to the columns that matter for the study:

{
  "platformListingId": "29990558",
  "title": "Tram 28 - Marvelous Balcony & Tagus River Views 3D",
  "propertyType": "Apartment",
  "roomType": "entire_place",
  "city": "Lisbon",
  "latitude": 38.71785,
  "longitude": -9.12793,
  "checkIn": "2026-11-20",
  "checkOut": "2026-11-23",
  "nights": 3,
  "guests": 2,
  "currency": "USD",
  "pricePerNight": 135.45,
  "priceTotal": 407,
  "priceBeforeDiscount": null,
  "rating": 4.92,
  "reviewCount": 726,
  "bedrooms": 1,
  "beds": 2,
  "bathrooms": 1,
  "badges": ["Guest favorite"],
  "isSuperhost": false,
  "cancellationPolicy": "free_cancellation",
  "searchRank": 1
}

Two columns deserve a note. pricePerNight is the base nightly rate from Airbnb's price breakdown, before discounts, fees and taxes. priceTotal is what the guest pays for the stay. For an "effective nightly price" that includes everything, divide priceTotal by nights; that is the number a traveller actually compares.

Step 3: the analysis in a spreadsheet

Export the dataset as CSV or Excel from the run's Output tab (or pull it from the Apify API). With the columns above, a few pivot tables answer most questions:

Question	Columns to use
Price distribution for the stay	`priceTotal / nights`, grouped by `bedrooms`
Entire homes vs private rooms	`roomType` against the median effective nightly price
Does the badge pay?	`badges` contains "Guest favorite" vs the others, same `bedrooms`
Where are the listings?	`latitude`, `longitude` on a map, coloured by price
How established is the supply?	histogram of `reviewCount`; `isNew` for fresh listings
How many run promotions?	rows where `priceBeforeDiscount` is not null

A concrete reading from a Lisbon run: sort by effective nightly price and look at the 25th, 50th and 75th percentiles per bedroom count. That gives a host three reference points ("cheap", "median", "premium") that are far more useful than the average, because Airbnb search results always contain a few outliers at the top.

Step 4: make it repeat

A market study made once is a snapshot. Schedule the Actor on Apify (weekly is enough for a seasonal view, daily for revenue management), keep the same input, and append each run's rows to the same sheet with the scrapedAt column. Compare runs by platformListingId, checkIn and checkOut: a listing that appears in both runs with a different priceTotal has changed its price; a listing that disappears is either booked or delisted.

For a whole city rather than one search, the Actor splits the map area into quadrants when a search is saturated, so a maxResults of 1,000 is realistic for Lisbon. It just takes more requests.

Honest limits

270 listings per search. Airbnb serves at most 15 pages of 18 listings for one search. The area splitting works around it, but whole cities take many more requests than a neighbourhood. Narrow searches (a district, a map area pasted as a search URL) are cheaper and more precise.
Rankings move. Airbnb recomputes its ranking per session. searchRank is what one session saw, not a stable popularity score. Do not build a "top 10" on it; build distributions instead.
Search cards show a subset. Amenities, maximum guests, instant booking and detailed fees are not on search cards and come back empty. Bedrooms, beds and bathrooms are shown for searches with dates only.
Prices depend on the site. European Airbnb sites (airbnb.fr, airbnb.de) display a regulated total that includes taxes and fees, itemised in taxesAndFees; airbnb.com shows a total that may exclude taxes. Always compare rows obtained with the same domain, currency and dates.
No personal data, by design. Nothing about hosts or guests is collected: no names, no profile photos, no identifiers, no review texts. You get the listing facts, the average rating, the number of reviews and the badges. If your study needs host-level information, this is not the tool.
A run that finds nothing fails on purpose, with an explicit message (misspelt location, filters too strict), so that a scheduled study never silently produces an empty sheet.

Use the data for analysis, respect the platform's terms and local law, and do not republish listings.

Where to go next

Once the search export exists, the url column is the entry point for a second pass: the Airbnb Listing Details Scraper reads each listing page for amenities, house rules, category ratings and an availability calendar, and both Actors share their first columns so that the rows join on platformListingId. That is the subject of another article.

Disclosure: I build these Actors and may earn a commission if you sign up to Apify through these links.

From an Airbnb search export to amenities, house rules and an availability calendar

elliott maqy — Tue, 20 Oct 2026 09:06:18 +0000

Airbnb search results tell you the price, the rating and the size of a listing. They do not tell you whether it has a dedicated workspace, whether pets are allowed, what the check-in time is, how the cleanliness rating compares with the location rating, or which nights are free in the next three months. All of that lives on the listing page.

This is a two-step pipeline with two Apify Actors that share their output schema: the Airbnb Listings Scraper for the search, the Airbnb Listing Details Scraper for the pages. The rows join on platformListingId. Neither collects anything about hosts or guests.

Who needs the second step

Remote-work and relocation searches: filter on amenities (workspace, fast wifi, washer), quiet hours and minimum stay.
Family or accessibility needs: crib, high chair, step-free access, maximum guests, pets.
Hosts benchmarking their listing: the six category ratings of comparable listings (cleanliness, accuracy, check-in, communication, location, value) say where the gap is.
Occupancy estimates: the availability calendar for one to twelve months gives the available nights and minimum stays of competing listings.

Step 1: the search

Run the search Actor with dates, so that prices describe the same stay. The input below is the public task "Entire homes on Airbnb in Lisbon", plus dates:

{
  "location": "Lisbon, Portugal",
  "checkIn": "2026-12-01",
  "checkOut": "2026-12-03",
  "adults": 2,
  "roomTypes": ["entire_home"],
  "currency": "EUR",
  "maxResults": 50
}

Each row has a url column that opens the listing with those dates. Export the dataset, or read it from the Apify API, and keep the url (or platformListingId) column: that is the input of step 2.

Step 2: the listing pages

The details Actor takes listing URLs or bare numeric ids. This input is the Actor's validation input, with the same dates as the search and a three-month calendar:

{
  "listingUrls": [
    "https://www.airbnb.com/rooms/21607939",
    "https://www.airbnb.com/rooms/29990558",
    "https://www.airbnb.com/rooms/13376882",
    "1479864404418316543",
    "674363704654416995"
  ],
  "checkIn": "2026-12-01",
  "checkOut": "2026-12-03",
  "adults": 2,
  "includeCalendar": true,
  "calendarMonths": 3,
  "currency": "EUR",
  "locale": "en",
  "domain": "www.airbnb.com",
  "maxResults": 5
}

The fields not shown keep the Actor's defaults. In Apify, the simplest way to chain the two is to paste the url column into listingUrls; the more robust way is a small script that reads the first run's dataset through the API and starts the second Actor with those URLs. Duplicated URLs are fetched once.

What a detail row contains

Here is a real row from a Lisbon listing (English, EUR, two-month calendar), cut down to what the search did not have:

{
  "platformListingId": "21607939",
  "title": "Red Bridge Duplex close to LX Factory",
  "propertyType": "Entire rental unit",
  "neighborhood": "Alcântara, Lisbon",
  "rating": 4.96,
  "reviewCount": 658,
  "ratingCleanliness": 4.96,
  "ratingAccuracy": 4.97,
  "ratingCheckIn": 4.99,
  "ratingCommunication": 5,
  "ratingLocation": 4.78,
  "ratingValue": 4.93,
  "isGuestFavorite": true,
  "highlights": ["Top 10% of homes", "Self check-in", "Dedicated workspace"],
  "maxGuests": 5,
  "bedrooms": 2,
  "beds": 3,
  "bathrooms": 2,
  "sleepingArrangements": ["Bedroom 1: 1 double bed", "Bedroom 2: 1 double bed", "Living room: 1 sofa bed"],
  "amenityGroups": {
    "Internet and office": ["Wifi", "Dedicated workspace"],
    "Family": ["Paid pack ’n play/travel crib - available upon request", "Standalone high chair - always at the listing", "Children’s dinnerware"],
    "Parking and facilities": ["Free street parking", "Paid parking lot off premises", "Paid parking on premises"]
  },
  "unavailableAmenities": ["Exterior security cameras on property", "Dryer", "Essentials"],
  "checkInTime": "Check-in after 4:00 PM",
  "checkOutTime": "Checkout before 12:00 PM",
  "petsAllowed": false,
  "smokingAllowed": false,
  "eventsAllowed": false,
  "quietHours": "10:00 PM - 8:00 AM",
  "calendarStart": "2026-10-01",
  "calendarEnd": "2026-11-30",
  "calendarDays": 61,
  "availableDays": 7,
  "nextAvailableDate": "2026-11-13",
  "minNights": 1,
  "isAvailable": true
}

The full row also carries the complete flat amenities list (55 entries for this listing), the full amenityGroups object, the house rules as Airbnb prints them, the safety features, the description as plain text, the photos, and availability: one entry per day with available, checkInAllowed, checkOutAllowed, minNights and maxNights.

Joining and using the two datasets

Both Actors put the same first columns in the same order, so a spreadsheet join on platformListingId gives one wide row per listing: price columns from step 1, everything else from step 2. A few uses:

Goal	Columns
Shortlist for remote work	`amenityGroups["Internet and office"]` contains "Dedicated workspace", `quietHours` not null, `minNights`
Family stay	`maxGuests`, `amenityGroups["Family"]`, `petsAllowed`, `sleepingArrangements`
Where comparable listings lose points	`ratingCleanliness` … `ratingValue` against the search's `pricePerNight`
Occupancy indicator	`availableDays / calendarDays`, per listing, per month
Price per available night	step 1 `priceTotal / nights` next to step 2 `availableDays`

The Output tab of the details Actor has five views (Overview, Ratings, Amenities, House rules, Availability) for a quick look before exporting.

Honest limits

No prices on listing pages. Airbnb computes the price of a stay after the page loads; the details Actor reads the page only, so every price column is null. Prices come from step 1, which is why the pipeline has two steps.
The calendar starts on the first day of the current month, so past days count as unavailable in availableDays. There is no per-day price in it. isAvailable is null when your dates fall outside the fetched months.
Texts are Airbnb's texts, user-written and localised: descriptions, rules and amenity names come in the requested locale. The flags (petsAllowed, smokingAllowed, eventsAllowed) and the calendar are language independent, which is what to filter on.
Removed or private listings yield no row; the log names them. A run whose listings all fail ends as failed, never as an empty success.
Cost: one event per listing, plus one event per calendar month per listing when the calendar is requested. 100 listings with a three-month calendar are 100 listing events and 300 calendar events. A listing takes about two seconds, three with its calendar.
No personal data. The listing page names the host and shows reviews; none of it is read or stored. You get listing facts, the average and category ratings and the review count.

Use the data for analysis, respect the platform's terms and local law, and do not republish listings.

Disclosure: I build these Actors and may earn a commission if you sign up to Apify through these links.