Is There an Airbnb API? How to Get Listing Data

You search "Airbnb API," and unlike most portals, you get a real hit. developer.airbnb.com loads. It says "Airbnb API Documentation." There's a Homes API, an Activities API, a quickstart, a sandbox, a changelog. For about ninety seconds it looks like the easiest integration of your week.

Then you read what the endpoints do, and the floor drops out.

The short answer

Yes, Airbnb has an official API. No, it will not do what you want.

Airbnb's API is a supply-side integration. It exists so property management systems and channel managers can push their own listings into Airbnb, sync their own calendars, and answer their own guests. There is no endpoint that searches the marketplace. You cannot ask it what a two-bedroom in Lisbon costs next October, because that question is about someone else's listing, and someone else's listing is the product Airbnb sells.

That distinction is the whole article, and almost nobody writing about the Airbnb API makes it clearly. So let's do the honest version: what the official API really is, why its own terms rule out the thing you were probably planning, and what you can actually run this afternoon.

What the official Airbnb API actually contains

The public documentation is genuinely public, which is unusual and worth a look. It splits into two programs:

• Homes API: manage listing descriptions, amenities and photos; confirm availability in real time during booking; retrieve and manage reservations.
• Activities API: the same idea for experiences, plus a Messages API for guest communication and ticket QR codes.

Read that list again with a data project in mind. Every verb is write or manage. It is a plumbing API for people who already own inventory on the platform. If you run 400 units through a PMS, this is exactly the API you want. If you are building a pricing tool, a market dashboard, a relocation site, or a travel comparison product, none of these endpoints touch your problem.

This short video makes the same point from the other direction, which is a good sanity check before you spend a week on a partner application:

The clause that ends most projects

Suppose you get in anyway. Airbnb's API Terms of Service spell out what you may do with the data, and section 2.2 prohibits using the API for the purpose of "retaining static copies or building databases," or of analyzing, deriving or optimizing demographic, pricing or financial data. A later clause also blocks using the API inside a product that competes with or duplicates Airbnb's own features.

Read plainly: the official API forbids the exact use case that sends people looking for it. Storing listings, computing comps, estimating revenue, benchmarking a market. That is a database and a pricing analysis, and both are named in the prohibitions. This is not a loophole anyone is going to negotiate away for a two-person startup.

And getting approved is a project of its own

Access is not a signup form. Airbnb's program requirements include signing its standard mutual NDA, agreeing to the API Terms plus partner-specific terms, passing a data security review, and committing to implement mandatory API features within six months of each release. That last one is easy to skim past and expensive to live with: you are agreeing to an ongoing engineering obligation to a company that can change the requirements. Partner access is designed for software vendors with a support org, not for a side project.

Airbnb is three marketplaces now, not one

Most "Airbnb API" articles still assume Airbnb means homes. That stopped being true on 13 May 2025, when the 2025 Summer Release launched Airbnb Services with 10 categories in 260 cities and relaunched Airbnb Experiences across 650 cities.

If you are building anything that models travel demand, that matters. A chef booking and a massage appointment now sit in the same app as the apartment, with their own hosts, their own prices, and their own availability. Any data layer that only understands stays is already describing two-thirds of a product. We will come back to this, because it is one of the places where hosted endpoints have quietly moved ahead of the articles.

Your four real options in 2026

Every route to Airbnb marketplace data is a trade between money, engineering time, and how often it breaks. The honest comparison:

Option	Pricing	Setup effort	Where it hurts
Official Airbnb API (Homes / Activities)	No fee, if you are approved	NDA, security review, partner terms, ongoing feature obligations	Supply side only. Nothing searches the marketplace, and the terms prohibit building databases or deriving pricing data from it.
DIY scraper (headless browser plus proxies)	"Free," plus proxies and your time	Days to build, forever to maintain	Airbnb's front end is a heavily instrumented single-page app. You are not parsing HTML, you are reverse engineering a GraphQL surface that changes without telling you.
Scraper marketplaces (e.g. Apify actors)	$1.00 per 1,000 listings on the popular actor	Hours	Cheap per row, and you still own schemas, dedup, scheduling and monitoring. Actors break when the site shifts, and a search returns roughly 240 results per location, so wide pulls need slicing.
STR analytics vendors (e.g. AirROI, AirDNA)	AirROI starts at $0.01 per call, pay as you go	Minutes	Excellent at market metrics, occupancy and revenue estimates. Modelled aggregates are not the same thing as the live listing objects a booking or search product needs.
Hosted REST endpoints (RealtyAPI)	Free tier of 250 requests a month, plans from $20/month for 20,000	Minutes	Live marketplace data only. No host-side writes, no booking, no messaging, and no invented history for dates you did not capture.

If you are still weighing build against buy, the general version of this trade-off is in web scraping vs. using an API, and the Airbnb-specific mechanics are in Airbnb web scraping. Short version: scraping wins when volume is tiny and nobody is paged when it breaks. It loses the week uptime starts mattering.

Is scraping Airbnb legal?

The quiet question. Scraping publicly visible data is not automatically illegal in the US, and courts have gone back and forth on it for years. Airbnb's terms prohibit it, Airbnb has real lawyers, and none of that ambiguity makes your Tuesday deploy survive a layout change. We cover the landscape properly in is website scraping legal? and how we source data in is RealtyAPI legal? The practical read: legal risk is genuine but blurry, while the maintenance cost is certain and arrives on schedule. Most teams do not quit scraping because of a lawyer. They quit in month four.

What RealtyAPI's Airbnb endpoints cover

RealtyAPI runs hosted Airbnb endpoints as part of its real estate data platform: normal REST, one API key, and the proxies and anti-bot plumbing stop being your problem. Twenty-seven endpoints in four groups:

Group	Endpoints	What they do
Search (9)	/search/homes/bydestination, /byplaceid, /bycategory, /bycoordinates, /byurl, /search/exp/*, /search/services/bydestination, /autocomplete	Find stays, experiences and services by place name, map bounds, category, or a pasted Airbnb URL
Details (10)	/home/details, /home/availability, /home/reviews, /home/extract, /experience/*, /service/*, /host/details	Full records for one listing, experience, service or host, plus reviews and open dates
Filters (4)	/filter/amenities, /filter/accessibility, /filter/host_language, /filter/property_types	The code lists the search filters expect, because Airbnb filters are numeric ids, not words
Tools (4)	/categories, /currencies, /language_codes, /	Reference data and a health check

The filters that make it feel like Airbnb

A generic listings API treats a stay like a row in a table, which is how you end up unable to answer "entire home, superhost, instant book, allows pets, under 180 a night." These are the Airbnb-native parameters on the search endpoints:

• typeOfPlace: Any_type, Room or Entire_home
• superhost, guestFavorite, luxuryHomes: the badge filters people actually sort by
• bookingOptions: comma-separated from instant book, self checkin, allow pets, free cancellation
• amenities: numeric ids such as 4, 8, 33, listed by /filter/amenities
• accessibilityFeatures and hostLanguages: same pattern, from their own filter endpoints
• flexibleDateFilters and goAnytimeMonths: the "I'm flexible" search, which is how a lot of real demand behaves
• resultsType: search_results, map_results, or both, so map-driven UIs get map-shaped data

Quick-start: Lisbon listings in three requests

Base URL is https://airbnb.realtyapi.io and auth is one header. Miss it and the gateway tells you immediately:

curl "https://airbnb.realtyapi.io/autocomplete?keyword=lisbon"

{ "error": "Missing API key in the header" }

Add the header and you are in business. Airbnb sits on the standard plans, so the free tier's 250 requests a month is enough to shape your integration before you pay anything, and the docs cover key setup in about two minutes.

1. Turn a place name into something searchable

curl "https://airbnb.realtyapi.io/autocomplete?keyword=lisbon" \
  -H "x-realtyapi-key: YOUR_KEY"

This mirrors the suggestion dropdown on Airbnb itself. Use it to resolve messy user input into a destination string, or to grab a place id for /search/homes/byplaceid when you want a stable identifier instead of a name.

2. Search stays

curl "https://airbnb.realtyapi.io/search/homes/bydestination?searchDestinations=lisbon,%20portugal&checkIn=2026-10-02&checkOut=2026-10-06&adults=2&typeOfPlace=Entire_home&priceRangeMax=180&superhost=true" \
  -H "x-realtyapi-key: YOUR_KEY"

Dates are YYYY-MM-DD and must be today or later. Skip them and you get the flexible-search behaviour instead, driven by months, flexibleStayPeriod or goAnytimeMonths. Pagination is a cursor, not a page number: the response carries a nextPageCursor (an opaque base64 token like eyJzZWN0aW9uX29mZnNldCI6MCwi...) that you pass back on the next call. Each call is one request against your quota.

3. Pull one listing in full

curl "https://airbnb.realtyapi.io/home/details?stayListingId=LISTING_ID&checkIn=2026-10-02&checkOut=2026-10-06" \
  -H "x-realtyapi-key: YOUR_KEY"

Note the required dates. There is no dateless "get listing" call, and that is not an oversight. An Airbnb listing has no single price. It has a price for a stay, which depends on the nights, the guest count, cleaning fees and the host's calendar rules. Asking what a listing costs without saying when is a question the platform cannot answer, so the API refuses to pretend it can.

The gotcha that will cost you an afternoon

There are two different listing identifiers, and they are not interchangeable. Search results and /home/details use stayListingId. /home/availability wants listingId, which you read out of the details response. Pass the wrong one and you get an empty answer rather than a helpful error, which is the sort of bug that eats a Thursday. Fetch details first, keep both ids on your record, and move on with your life.

A production-ish Python loop

Cursor pagination and error handling, because anything fronting live web data will have a bad minute upstream eventually:

import requests

BASE = "https://airbnb.realtyapi.io"
HEADERS = {"x-realtyapi-key": "YOUR_KEY"}

def get(path, **params):
    r = requests.get(BASE + path, params=params, headers=HEADERS, timeout=60)
    if r.status_code == 401:
        raise RuntimeError("Bad or missing x-realtyapi-key")
    r.raise_for_status()
    return r.json()

def search_stays(max_pages=10, **filters):
    cursor, pages = None, 0
    while pages < max_pages:
        params = dict(filters)
        if cursor:
            params["nextPageCursor"] = cursor
        data = get("/search/homes/bydestination", **params)
        results = data.get("searchResults") or data.get("search_results") or []
        if not results:
            break
        for item in results:
            yield item
        cursor = data.get("nextPageCursor")
        if not cursor:
            break
        pages += 1

seen = set()
for stay in search_stays(searchDestinations="lisbon, portugal",
                         checkIn="2026-10-02", checkOut="2026-10-06",
                         adults=2, typeOfPlace="Entire_home",
                         superhost="true"):
    listing = stay.get("listing") or stay
    if listing.get("id") in seen:
        continue
    seen.add(listing.get("id"))
    print(listing.get("id"), listing.get("name"))

The max_pages guard is not decoration. A cursor loop with no ceiling is one upstream quirk away from spending your monthly quota overnight, and quota bugs always happen on a Friday. Ask me how I know.

The part almost nobody covers: experiences and services

Since the 2025 relaunch, the interesting questions about Airbnb are not only about beds. Experiences and services have their own search endpoints, with filters that fit them rather than being bolted on from the stays model.

# Experiences: art and culture, for solo travellers, morning starts
curl "https://airbnb.realtyapi.io/search/exp/bydestination?searchDestinations=lisbon,%20portugal&experienceType=art&travelerType=Solo%20Travellers&timeOfDay=morning" \
  -H "x-realtyapi-key: YOUR_KEY"

# Services: private chefs, during a specific stay window
curl "https://airbnb.realtyapi.io/search/services/bydestination?searchDestinations=lisbon,%20portugal&checkIn=2026-10-02&checkOut=2026-10-06&typeOfService=Chefs" \
  -H "x-realtyapi-key: YOUR_KEY"

Services search requires a typeOfService, chosen from Chefs, Photography, Prepared_Meals, Training, Makeup, Hair, Spa_Treatment, Catering and Nails. There is no "everything" sweep, so a full picture of a city means one call per category. Both endpoints also take minDuration and maxDuration in minutes and pricePerGuest_min and pricePerGuest_max, which is enough to answer questions the stays data cannot touch. What does an hour of a local's time cost in Lisbon versus Porto? Which categories are thin in a market that has plenty of listings? That is short-term rental analytics with a dimension most datasets do not carry yet.

What you still cannot get

Honesty section, because a vendor that only lists strengths is telling you something.

• Host-side anything. These are read endpoints against the public marketplace. You cannot create a listing, accept a booking, or message a guest. That is the official partner API's job, and it is the one thing it does well.
• History you did not capture. The data is what Airbnb shows now. Price history means running the search loop above on a schedule and storing snapshots yourself. A cron job and a table gets you further than people expect.
• Modelled occupancy and revenue. Availability tells you which dates are open, not why. Turning that into revenue estimates is a modelling job, and vendors like AirDNA and AirROI have spent years on it.
• Exemption from thinking about dates. Every price you store is a price for a specific stay window. Cache it without the window attached and you have built a very confident liar.

Key takeaways

• Airbnb's official API is real, documented, and aimed at the other side of the marketplace. Homes and Activities let approved partners manage their own inventory. Neither one searches listings, which is what most people mean by "Airbnb API."
• Even approved partners are barred from the common use case. The API terms prohibit retaining copies or building databases and prohibit deriving pricing or financial analysis, so a market dashboard is out of scope by contract, not just by endpoint.
• Airbnb is stays, experiences and services now. Since May 2025 a data layer that only models homes is missing two of the three marketplaces, and most Airbnb API articles have not caught up.
• Marketplace scrapers are cheap per row and expensive per quarter. A dollar per thousand listings looks great until you own the schema drift, the dedup, the scheduling and the 3am page.
• Whichever route you pick, keep dates attached to prices and keep the integration one layer thick. When a source moves, you want to replace one client file, not re-derive an application's worth of assumptions.

If you want to know in ten minutes whether this data fits your product, run the three requests above against the free tier and point them at a city you know well. Two hundred and fifty requests is not a business, but it is more than enough to find out whether the answers are the ones your product needs, and that beats a six-week partner application that ends in a clause you cannot work around.

Same question, different portals: whether StreetEasy has an API, whether Redfin has one, what became of the Zoopla API, and which Rightmove APIs actually exist.