What the Airbnb API does and who it is for

The Airbnb API is a third-party wrapper that exposes Airbnb's accommodation data to developers without requiring a direct commercial partnership with Airbnb itself. It is distributed through API marketplaces and is aimed at developers building travel apps, price-comparison tools, accommodation aggregators, or any product that needs access to short-term rental listings.

Because Airbnb does not publish its own public API, this marketplace integration fills the gap. The upside is rapid access with a single API key; the trade-off is that the data pipeline depends on a third party remaining in sync with Airbnb's internal changes. With a 99% average success rate across production calls, the service appears stable — though a 1387 ms average latency is worth factoring into your UX if you are making synchronous calls in a user-facing product.

Endpoint walkthrough

All 25 endpoints use HTTP GET, which means requests are simple to inspect, cache, and debug. The endpoint surface breaks down into four functional groups.

Search

Three active search strategies are available:

  • Search by location name — /api/v2/searchPropertyByLocation and its v1 equivalents allow querying by a human-readable place name (city, neighbourhood, landmark).
  • Search by place ID — /api/v2/searchPropertyByPlaceId accepts a structured place identifier, useful when you already have a resolved location from a geocoding service.
  • Search by GEO coordinates — /api/v2/searchPropertyByGEO accepts latitude/longitude, making it natural to combine with a map interface.

Note that several v1 endpoints (/api/v1/searchProperty, /api/v1/searchPropertyByGEO, /api/v1/searchPropertyByLocation) are explicitly marked as deprecated. Use the v2 equivalents or the V2 suffixed v1 endpoints where available to avoid breakage.

Property data

  • /api/v2/getPropertyDetails returns full listing information. The v1 version of this endpoint is marked as deprecated.
  • /api/v1/getPropertyReviews retrieves guest reviews for a listing.
  • /api/v1/checkAvailability checks whether a property is bookable for given dates.
  • /api/v1/getPropertyCheckoutPrice returns the total checkout cost for a stay, which is particularly valuable because Airbnb's real cost (with cleaning fees and service charges) often differs substantially from the nightly rate.

Filter metadata

A rich set of filter-support endpoints lets you populate dropdown menus and filter panels in your UI without hardcoding values:

  • /api/v1/getAmenities — amenity filter options
  • /api/v1/getPropertyType — property type categories
  • /api/v1/getTypeOfPlace — entire home vs. private room vs. shared room distinctions
  • /api/v1/getCategory — listing categories
  • /api/v1/getAccessibility — accessibility feature filters
  • /api/v1/getTopTierStaysFilter — top-tier (e.g., Plus, Luxe-level) stay filters
  • /api/v1/getHostLanguage — host language filters

Utility

  • /api/v1/searchDestination — resolves destination names, useful as an autocomplete source.
  • /api/v1/getLanguages and /api/v1/getCurrency — return supported languages and currencies.
  • /api/v1/test — a lightweight ping endpoint to confirm the server is reachable before executing real requests.

Pricing breakdown

The API follows a freemium model with four tiers. "Basic" in the table refers to the monthly request quota for the core endpoint category.

Plan Monthly cost Rate limit Monthly requests Overage per request
BASIC $0 1 req/sec 10 —
PRO $7.99 1 req/sec 4,000 $0.0055
ULTRA $45 90 req/min 40,000 $0.0050
MEGA $200 — 700,000 $0.0045

The free BASIC tier gives you 10 requests per month — enough for initial integration testing but not for any real workload. If you are building a demo or proof of concept you will exhaust it almost immediately and need to move to PRO.

PRO at $7.99/month with 4,000 requests is a reasonable starting point for a low-traffic tool, a side project, or internal tooling. The 1 req/sec rate limit on both BASIC and PRO means burst-heavy patterns (loading a page that fires several parallel API calls) require careful queuing.

ULTRA raises the rate limit meaningfully to 90 requests per minute (~1.5/sec sustained but allowing short bursts), which is more practical for a live consumer app. At 40,000 monthly requests it equates to roughly 1,300 property lookups per day before overage kicks in.

MEGA, the marketplace-recommended tier, covers 700,000 requests monthly — suitable for aggregators or data pipelines ingesting a large slice of Airbnb's inventory on a recurring basis. The overage rate drops to $0.0045 per request, the lowest across all plans.

Practical use cases

Travel planning apps are the obvious fit. The combination of GEO-based search, availability checking, and checkout pricing gives you the data triangle you need to show users real options with real costs.

Price monitoring and alerting tools can periodically call checkAvailability and getPropertyCheckoutPrice for a watchlist of properties, notifying users when prices drop or dates open up. Keep the PRO rate limit in mind — 4,000 calls/month is roughly 130 monitored properties checked daily.

Map-driven discovery interfaces pair naturally with searchPropertyByGEO: as a user pans or zooms, the app fires new coordinate queries and plots results. This pattern burns through requests quickly, so ULTRA or MEGA is appropriate.

Content aggregation and analytics — researchers or data teams comparing short-term rental supply across cities can batch-collect listings and reviews. At MEGA volumes, a nightly crawl of multiple cities is feasible.

Limitations and things to check before integrating

No public documentation from the original provider. Airbnb itself does not offer this API, and the provider notes that public documentation is not available. This means you are dependent on the marketplace documentation and community feedback for schema details.

Latency. The 1387 ms average response time is on the higher side. For synchronous user-facing requests you should implement skeleton loading states and avoid chaining multiple sequential calls. Consider caching filter metadata responses (amenities, property types, currencies) aggressively since they change rarely.

Deprecated endpoints. Several v1 search and details endpoints are explicitly deprecated. Target v2 endpoints from day one to avoid a forced migration later.

Rate limits on lower tiers. The 1 req/sec ceiling on BASIC and PRO is a real constraint for any interface that fires multiple calls on page load. Design around it early — batch what you can, debounce search inputs, and cache results where TTL makes sense.

Overage costs. PRO overage at $0.0055/request adds up if traffic spikes. A sudden influx of users could turn a $7.99 month into a substantially larger bill. Set up usage alerts and consider the ULTRA tier once you have meaningful traffic.

Getting started

  1. Subscribe to the BASIC plan to get an API key at zero cost.
  2. Call /api/v1/test to confirm connectivity.
  3. Fetch filter metadata once (getAmenities, getCurrency, getLanguages, etc.) and cache locally — these rarely change and calling them repeatedly wastes your quota.
  4. Implement property search using /api/v2/searchPropertyByLocation or the GEO variant, then chain getPropertyDetails and checkAvailability for selected results.
  5. Once you have measured your monthly request volume in staging, choose the appropriate paid tier before going to production. The jump from 10 (BASIC) to 4,000 (PRO) is immediate and costs under $8/month.