Airbnb calendar
Read an Airbnb listing calendar — day-by-day availability over a date window. Use when a user asks whether an Airbnb is open on specific dates. Powered by StayingAPI.From its SKILL.md
npx -y skills add stayingapi/airbnb-skills --skill airbnb-calendarAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT-0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.4 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it
Airbnb Calendar
The Airbnb calendar as data: day-by-day availability for a known listing over any window. (A keyword-friendly alias of the availability skill.)
Setup
If $STAYINGAPI_KEY is not set, read references/auth-setup.md and follow it to get and store the key. A stay_test_ sandbox key works for evaluation at zero cost.
When to use this skill
DO use when the user asks:
- "Show the Airbnb calendar for this listing"
- "Which August nights are open on this Airbnb?"
Do NOT use when:
- You do not have a listing id — search first
Required headers
Every request needs:
- Authorization:
Bearer $STAYINGAPI_KEY - User-Agent: your agent's name (e.g.
ClaudeCode/1.0).
Base URL: https://api.stayingapi.com/v1.
Tools
GET /v1/availability
Get day-by-day availability for a known listing (or a batch of listings) on one platform over a date window. Each day reports whether it is available, its minimum-night requirement, and whether check-in / check-out / booking is allowed.
Key parameters:
platform— Required. vrbo | booking | airbnb | google. Single platform (not a fan-out endpoint). Use the API value, not the brand name — "booking", not "booking-com"; "google", not "google-hotels".listingId— A single listing id on platform.listingIds[]— A batch of listing ids on platform.url— Full listing URL (alternative to an id).startDate— Required. YYYY-MM-DD; not in the past.endDate— Required. After startDate; window ≤ 365 days.
MCP (no key pasted into the agent)
On an MCP-capable runtime, connect https://mcp.stayingapi.com/mcp (OAuth 2.1 + PKCE) and use: check_availability.
Platform × endpoint support
Not every endpoint supports every platform. Verified:
| platform | search | availability | price | price-compare | listing | reviews |
|---|---|---|---|---|---|---|
airbnb | yes | yes | yes | yes | yes | yes |
booking | yes | yes | yes | yes | yes | yes |
vrbo | yes | yes | yes | yes | yes | yes |
google | yes | yes | yes | yes | no | no |
GET /v1/listing/google/… and GET /v1/reviews?platform=google return
400 platform_not_enabled ("google is not enabled for this endpoint"). Use booking,
airbnb or vrbo for listing detail and reviews; use google for search, price and
cross-OTA price-compare.
The cross-OTA advantage
StayingAPI is cross-platform: Airbnb data comes back in the same unified schema as Booking.com, Vrbo and Google Hotels, so one integration covers them all. /v1/price-compare resolves a property through the Google Hotels backbone and returns the offers it exposes plus a StayingAPI-computed min and median over those offers, as first-class fields.
Coverage varies by property and by what the backbone returns: some properties come back with several OTA offers, others with a single aggregated-lowest offer (in which case
minequalsmedianandoffershas one entry, sometimes a direct-supplier rate rather than an OTA). Readoffers.lengthbefore describing a result as a multi-platform comparison.
Async & partial failures
A live call that has to scrape returns 202 with data.jobId, data.pollUrl and
data.estimatedSeconds (the 202 itself charges 0). Poll GET /v1/jobs/{jobId} (free)
until data.status is TERMINAL — completed or failed.
completed→ the payload is atdata.result(the same schema the sync call returns;dataitself is just{jobId, result, status}).metacarriespartial,platformResults[]andwarnings[]. A completed job may still return an empty result (data.result: []) — the reason is inmeta.warnings[](e.g.no_results), and empty results charge 0.failed→ HTTP is still 200, not an HTTP error. The failure is nested atdata.error(code,type,message,retryable). Detect it withdata.status === "failed", not a top-levelerror.creditsChargedis 0, andmetacarries only{requestId, creditsCharged, platforms}— do not readpartial,platformResultsorwarningson a failed job.
Pace your polling: honour the Retry-After header, back off between attempts, and cap the
number of attempts. A tight loop hits 429 rate_limit_exceeded (120 requests/minute).
Known limitations
- Pagination:
limit/cursorare accepted where documented, but availability depends on the endpoint and the upstream source — treatmeta.paginationas authoritative and stop whenhasMoreis false ornextCursoris null. - Externally-sourced ids: a Vrbo id obtained somewhere other than
/v1/searchmay not resolve upstream and can produce a failed job (all_actors_failed). Prefer ids from/v1/search(platformListingId). - Platform gaps: see the support matrix above —
googlehas no listing or reviews endpoint.
Credits
Number-free by design — failed, empty and blocked calls are never billed, and stay_test_ sandbox calls are always free. Current costs: https://stayingapi.com/pricing · full contract: https://api.stayingapi.com/openapi.json.
Trademark
StayingAPI is an independent service and is not affiliated with, endorsed by, or sponsored by Airbnb. Airbnb is a trademark of its respective owner.
Get your free key → https://stayingapi.com/signup · Docs: https://stayingapi.com/docs
What ships with it: 1 file
1.9 KB alongside SKILL.md
references/
- auth-setup.md1.9 KB