Airbnb Availability Calendar By Guest Count & Pets

Apify actor that fetches Airbnb listing availability — one row per check-in date per listing — for a party you name: adults, children, infants and pets. Instead of the anonymous two-adult / zero-pet answer every plain availability scraper returns, each date comes back with Airbnb's own booking answer for your party, plus the exact sentence and reason code Airbnb sends when a date says no: too many guests, no pets allowed, or the calendar itself is blocked.

What it scrapes

Airbnb listing pages (airbnb.com/rooms/<id> and country variants) via the same StaysPdpSections GraphQL endpoint the site itself uses. For every day in your date range you get:

• Whether the listing is open on that date for the default two-adult query the base always used (unchanged columns, kept for compatibility).
• Whether the listing is open on that date for the party you actually configured (Party Booking).
• Airbnb's own refusal sentence and machine-readable reason type when the answer is no (Unavailability Reason, Unavailability Reason Type).
• The listing's real guest cap, guest-count disclaimer, pet policy and instant-book flag, read straight off the booking sidebar.

New in this variant

Field	What it does
adults	Sets party size. Airbnb re-quotes the whole listing for this number — over the cap and the date comes back refused with Maximum number of guests is N.
children	Children aged 2–12; counted against the guest cap the same as adults.
infants	Infants under 2; Airbnb does not count them against the cap.
pets	Number of pets. On a no-pets listing the date comes back refused with This place doesn't allow pets. — a different problem than a booked-out calendar.
stayDays	Nights quoted per check-in date; check-out = check-in + this many nights. Lets minimum-stay refusals (Minimum stay is N nights) surface instead of being invisible.
explainUnavailableDates	On (default): ask Airbnb about every date separately, for your party, and keep its answer and reason for each one. Off: one call per listing, like the base — the single answer is repeated across every date.

Live-verified on real listings (2026-08-15): the same listing/date, adults: 2 → Available; adults: 7 → Unavailable, "Maximum number of guests is 4", GUEST. Same listing, pets: 0 → Available; pets: 1 → Unavailable, "This place doesn't allow pets.", OTHER. A 26-day sequential scan of one listing returned a genuine mix of Available / Unavailable — DATE days that changes across the range — proof explainUnavailableDates: true re-queries every date instead of copying the first answer.

Cost note — read before setting a wide date range

explainUnavailableDates: true makes one GraphQL call per date, per listing — a 31-day range on one listing is 31 sequential calls, not the base's 1. Requests are sequential (no concurrency knob, matching the base). Set explainUnavailableDates: false for the base's original one-call-per-listing behaviour when you only need the party-aware party-fields for the start date.

Input

Base fields (unchanged from airbnb-availability-calendar):

Field	Type	Default	Notes
urls	array of strings	["https://www.airbnb.com/rooms/860663943931949474"]	Room URLs or numeric listing IDs. Bulk supported.
listingUrl	string	—	Single URL/ID, alternative to urls.
startDate	string (YYYY-MM-DD)	2025-12-01	Stale on purpose — inherited from the base actor. Set your own dates.
endDate	string (YYYY-MM-DD)	2025-12-31	Same note as above.
enrichWithPricing	boolean	false	Adds 12 pricing/booking columns from the base's single startDate call (unchanged behaviour — see Caveats).
proxyConfiguration	object	{"useApifyProxy": false}	No proxy → datacenter → residential (3 retries), then sticky residential.

New fields (this variant):

Field	Type	Default	Notes
adults	integer	2	Minimum 1.
children	integer	0	Ages 2–12.
infants	integer	0	Under 2, not counted against the cap.
pets	integer	0
stayDays	integer	1	1–28 nights per check-in date.
explainUnavailableDates	boolean	true	See "Cost note" above.

"required": [] — nothing is schema-required (inherited from the base); the actor still needs urls or listingUrl at runtime and logs an error and exits if both are empty.

Output

One dataset row per check-in date per listing. The base's 40 columns (Listing URL, Listing ID, Check-In Date, Check-Out Date, Host, Overview, Title, Canonical URL, Room Info, Property Type, Room Rating, accuracyRating, checkinRating, cleanlinessRating, communicationRating, locationRating, valueRating, guestSatisfactionOverall, visibleReviewCount, reviewAccessibilityLabel, petsAllowed, Guest_Capacity, Location, Image URL, Meta Description, Price Breakdown Title, Price Breakdown Subtitle, Accessibility Label, Strike Through Price, Primary Price, Cleaning Fee, Service Fee, Taxes, Total Price, Booking, Bedrooms, Beds, Bathrooms, Cancellation Policy Name, Cancellation Policy Subtitles) are unchanged, plus 7 new columns:

Field	Type	Description
Party Booking	string	"Available" / "Unavailable" for this date, asked with your party (adults/children/infants/pets).
Unavailability Reason	string | null	Airbnb's own sentence, e.g. "Maximum number of guests is 3", "This place doesn't allow pets.", "Those dates are not available", "Minimum stay is 2 nights".
Unavailability Reason Type	string | null	"GUEST" / "DATE" / "OTHER" — the stable machine-readable half; use this to filter, not the sentence (Airbnb localises the sentence by market).
Max Guest Capacity	integer | null	The listing's real booking-widget guest cap.
Guest Disclaimer	string | null	Airbnb's guest-count disclaimer sentence for the listing.
Pet Details	object | null	The pet-policy object Airbnb serves for the listing (fields vary by listing — shipped verbatim, not flattened or invented).
Instant Book	boolean | null	Whether the listing supports instant booking.

When enrichWithPricing: false (the default), the base's own 12 pricing/booking columns (including Booking) are stripped exactly as they are on the base actor — but the 7 new columns above are not in that strip list, so Party Booking / Unavailability Reason remain the only availability signal on a bare run. This is unchanged from-the-base behaviour, kept intentionally.

Also written to the key-value store under OUTPUT: the same { "<listingId>": [entries...] } object the base writes, now carrying the 7 new keys inside each entry.

Dataset default view ("📅 By date") adds Party Booking and Unavailability Reason to the base's 8 columns.

Caveats (carried from the base, not fixed here)

• startDate / endDate default to December 2025 — already in the past. This is the base's own default; it is not corrected, only inherited. Set your own dates.
• The base's own Booking, Total Price, Primary Price, Cleaning Fee, Service Fee, Taxes etc. are the answer from the single startDate call, repeated on every row — they are not per-date truth despite sitting next to a per-date Check-In Date. Use the new Party Booking / Unavailability Reason columns for genuine per-date answers.
• No currency input — currency is inferred from the URL's country domain (.co.uk→GBP, .de→EUR, …), same as the base.
• Airbnb may localise or change Unavailability Reason's wording; Unavailability Reason Type is the stable field to filter on.

Proxy behaviour

No proxy by default. On a block: datacenter proxy, then residential (3 retries); once residential succeeds it is reused (sticky) for every remaining request in the run — identical to the base.

Pay-per-event

One charged row (row_result) per emitted dataset row — one row per check-in date per listing, same as the base.