Airbnb data.
Without guessing what you missed.

A REST endpoint and MCP tool that returns public Airbnb data as structured JSON. You send a place name or a listing link with a Bearer token; you get back listings with structured prices, one listing in full with its host and per-category ratings, a listing's guest reviews, or its availability calendar night by night. No Airbnb account, no HTML to parse.

No. Everything returned is what Airbnb publishes publicly — the same listings, prices and reviews anyone can read without signing in. There is no login, no OAuth, and nothing to keep warm.

The response tells you. Every reviews response carries totalReviewCount — the listing's full review count as the source reports it — next to reviewCount, which is how many came back, plus hasMore and a note in plain words: "These are 10 of the 52 reviews the source reports for this listing." Pull the whole set and the same note reads "These are 52 of the 52 reviews". You never have to make a second call to find out which one you are holding, and an average over a sample is never mistaken for an average over everything.

Not by us. Each review's text is what the guest actually wrote, with a language code beside it, and translatedText carries the source's own translation only where one is published. The original is never replaced. Across 100 reviews measured on one Lisbon listing, 86 were English and the rest spanned nine other languages; 14 carried a published translation and 2 carried a host reply.

Yes. price is a structured object, not a display string: {total, perNight, nights, taxesAndFees, originalTotal, qualifier, note}, where each money value is {amount, currency, formatted}. A measured example returned a total of $940.47 against an originalTotal of $1,083.09 over 4 nights, with $36.70 of taxes and fees broken out rather than folded in. An originalTotal above total means a discount is applied; null means there is none to report.

No, and the two routes deliberately behave differently without them. Search always prices — it uses the source's own default stay window and reports that window straight back on the response, so a price is never silently for dates you did not ask about. Listing detail does the opposite: with no dates it returns price: null and a note saying to pass check-in and check-out to price a stay. A search has to price to be a search; a single-listing read will not invent a stay you did not ask about.

Yes. /airbnb/listing-availability returns the calendar night by night: every night in the range with available, bookable, availableForCheckin, availableForCheckout, and the minimum and maximum stay length the host enforces for a stay starting on that night. Up to twelve months in a single call — the source's own ceiling per request — and one credit whether you ask for one month or twelve. There is no per-night pricing on it; use listing detail with check-in and check-out for a priced stay.

Because that is usually the edge of the host's booking window, not a fully booked listing. Every availability response carries the note verbatim: "Dates beyond the host's own booking window come back marked unavailable rather than omitted — a long unbroken run of closed nights near the end of this window usually means the window, not a closure." The source answers every night you ask for, so a host who has opened four months still returns months five through twelve when you ask for twelve, marked unavailable and indistinguishable from a booked night. A solid block running all the way to the last night you asked for is the window. Scattered closed nights in the middle of an open range are real closures.

A closed night that still allows checkout is the far end of a booked stay. available: false with availableForCheckout: true and availableForCheckin: false means you cannot start a stay on that night, but a stay could end on it — it is somebody else's last night. Walk the nights and every place availableForCheckout flips true inside a closed run marks a departure. A 365-night pull on one measured listing had 19 of them.

A 404 with a message: {"error":"no listing was found for id \"1\""}. Not a 503 and not an empty 200 — a wrong id is a wrong request, so there is nothing to retry and nothing to mistake for a listing with no data.

Measured against production on 17 September 2026, three runs each: a one-page search of Lisbon answered in 1.6 to 1.9 seconds with 18 listings, one listing in full in 0.96 to 1.19 seconds, ten reviews in 0.53 to 0.58 seconds, three months of availability in 0.36 seconds with 91 nights, and resolving a link in about a tenth of a second.

One credit per page, reported on every response as pagesFetched. A search page is up to 18 listings and costs the same whether it comes back full or half empty. A review walk stops early once your limit is reached — asking for every page with a limit of 25 billed one page, not twenty. A full year of availability is a single page, the same one credit as the three-month default. Reading an Airbnb link is free and reports pagesFetched: 0.

Yes. All five routes are MCP tools on the same FetchLayer MCP server: airbnb_listing_reviews, airbnb_search_listings, airbnb_listing_detail, airbnb_listing_availability and airbnb_resolve_url. Tool calls use the same key and are billed exactly like REST, and the agent sees totalReviewCount alongside the reviews, so it can tell you when a rating is based on a sample instead of presenting it as the listing's score.