Is There a Vrbo API? How to Get Vacation Rental Data

Search for "Vrbo API" and you will find something genuinely confusing: a real developer portal, real documentation, real endpoint references, all of it run by Expedia Group and all of it apparently about Vrbo. So the answer looks like an easy yes. Then you read closely and discover the documentation is describing a door you probably cannot walk through, opening onto a room that does not contain the thing you came for.

Here is the honest version, sourced from Expedia's own developer hub and Vrbo's own terms, plus the part most articles skip: what you can actually run today.

The short answer

There is no public Vrbo API for reading listing data. There is no key to request, no sandbox, no self-serve signup that ends with you querying vacation rentals in Destin.

What exists instead is two official doors, both real and both well documented, neither of which is a market-data API. One is for companies that want to resell Vrbo stays. The other is for software that manages listings a host already owns. If you are building analytics, a rate tool, a market dashboard, or a competitor-tracking product, you are standing in front of a building with no entrance for you.

That is a more interesting situation than a flat "no," so it is worth understanding both doors properly before deciding what to do about it.

Door one: Expedia Rapid, the booking API

Vrbo has not been an independent company for a decade. Expedia Group acquired HomeAway, Vrbo's parent, in December 2015 for $3.9 billion. Expedia later made Vrbo the surviving brand and retired HomeAway as a standalone platform in 2020. Today Vrbo is an Expedia surface, and you can see it in places the marketing does not reach: pull up vrbo.com/robots.txt and you are reading Expedia's robots file, complete with disallow: /Flights-Search, disallow: /Cruise-Search, and disallow: /carsearch. A vacation rental site does not sell cruises. The shared platform underneath does.

So the official developer story lives at Expedia Group, in a product called Rapid. Expedia describes it as a way to "build a custom end-to-end booking experience," which is the whole thesis of this article in seven words. Rapid exists so that you can sell Expedia inventory. Everything about it follows from that.

Vrbo inventory rides along inside Rapid rather than getting its own API. You select it with a parameter:

supply_source=vrbo       # Vrbo properties only
supply_source=expedia    # conventional lodging only
                         # omit it entirely and Rapid defaults to lodging only

The documentation is direct about who may use it: "Partners using the Rapid Geography API who are enabled for Vrbo can also access Vrbo property IDs from all Geography APIs alongside conventional lodging properties." Enabled is doing the load-bearing work in that sentence. Vrbo access is an entitlement on your partner profile, not a scope you request in a dashboard.

And the failure mode if you are not enabled is worth committing to memory, because it will cost somebody a day. From the guide's own FAQ: "Yes, partners may filter by using supply_source=vrbo. If the profile is not allowed to access Vrbo supply no results will be returned." Not a 403. Not an error telling you that you lack permission. An empty, cheerful, perfectly valid response. You will assume your filters are wrong and go debug the wrong thing.

The one line that ends most projects

Suppose you clear the entitlement bar. You are a real booking partner, contract signed, Vrbo enabled. Now read this, from the Vrbo integration guide:

"Please note that we are unable to expose property street addresses until a booking has been made."

The official Vrbo data door does not give you an address until money changes hands. Think about what that removes. No geocoding to a parcel. No joining against tax records, permit databases, or short-term-rental registries. No "how many whole-home rentals are operating on this block." No de-duplicating the same house listed on three platforms. Address is the join key for essentially all property analytics, and the official channel withholds it by design, because Rapid is a booking pipe and a booking pipe only needs the address after there is a booking.

This is not an oversight or a gap someone forgot to fill. It is the correct design for what Rapid is. It just happens to be fatal for what most people searching "Vrbo API" actually want.

The rest of the Rapid vacation-rental surface is genuinely well built, for the record. Vrbo properties are single-unit and whole-property only, with no shared accommodations. Content comes back with vacation-rental-specific structures like vacation_rental_details, statistics for bedroom and bathroom counts, property_manager, and enhanced_house_rules. Premier Host properties carry attribute_id=1073745445, which you can also pass as a filter. Properties with refundable damage deposits have to be excluded with exclusion=refundable_damage_deposit unless you support them. And vacation_rental_details:registry_number is flagged as a required display field, which is Expedia pushing short-term-rental registration compliance down onto its partners. All of that is a thoughtful booking integration. None of it is a dataset.

Door two: the Connectivity Partner Program

The second official door faces the other way. Vrbo runs a Connectivity Partner Program for property management systems and channel managers, sorted into three tiers: Elite, Preferred, and Integrated. At the time of writing the directory lists 108 certified providers, with names like Guesty, Hostaway, OwnerRez, Lodgify, Escapia, Avantio, and Track in the Elite tier.

Crucially, certification happens between Vrbo and the software vendor, not between Vrbo and you. An individual host or manager does not get API credentials; they buy a channel manager that already holds certified status. If you have ever wondered why the vacation rental tooling market is so crowded with PMS products, this is a large part of the answer.

Now look at what a certified integration is actually allowed to do. These are the capability filters from Vrbo's own partner directory:

• Check compliance
• Retrieve and manage Vrbo traveler messages
• Access the status of a listing
• Manage Vrbo reviews
• Rate Vrbo travellers
• Supports Vrbo new listing discount
• Manage Vrbo seasonal cancellation policies
• Create and manage Vrbo promotions

Every single one is a management verb aimed at inventory you already control. Not one of them reads the market. There is no "search listings," no "fetch competitor rates," no "list properties in this region." The supply-side API is a write channel with a status light on it, which is exactly what a distribution platform wants and exactly what a pricing or analytics product cannot use.

This walkthrough shows what connecting that side actually looks like in practice, from a certified partner's setup screen:

What the terms say about the obvious workaround

Both doors closed, the obvious next thought is to read the public site directly. Vrbo's guest terms of service, last revised 26 March 2026, are unambiguous about it. You agree that "you will only use our Service for personal and non-commercial purposes," and you agree not to "access, monitor or copy any content on our Service using any robot, spider, scraper or other automated means or any manual process."

Note the tail of that clause. Or any manual process. As written, a summer intern with a spreadsheet is in the same category as a headless browser farm. There is a separate clause prohibiting you from violating "the restrictions in any robot exclusion headers on our Service or bypass or circumvent other measures employed to prevent or limit access," and Vrbo's robots file does disallow /search?, which is where the listings live.

We wrote up the broader legal picture in is website scraping legal? The short version has not changed: publicly visible data is not automatically off-limits in the US, terms of use are contracts rather than criminal statutes, and none of that ambiguity makes your pipeline survive a bot-detection change on a Tuesday. Most teams do not abandon scraping over a legal letter. They abandon it over maintenance.

Your four real options in 2026

Every route to Vrbo listing data trades money against engineering time against fragility. Honestly compared:

Option	Pricing	Setup effort	Where it hurts
Expedia Rapid (supply_source=vrbo)	Partner contract, not published	Weeks, plus commercial approval	Entitlement-gated, returns nothing at all if your profile is not enabled, and withholds street addresses until a booking exists. Built for reselling stays, not analyzing them.
Connectivity Partner Program	Cost of a certified channel manager	Certification is vendor-level, not yours	Only touches listings you already manage. Every capability is a management verb; nothing reads the wider market.
DIY scraper (headless browser plus proxies)	"Free," plus proxies and your weekends	Days to build, forever to maintain	Bot detection, layout drift, IP bans, and a terms clause that names both automated and manual collection. Every scraper is a maintenance contract you sign with yourself.
Scraper marketplaces (e.g. Apify actors)	Roughly $2.50 to $3.00 per 1,000 results, depending on the actor	Hours	You still own scheduling, schema drift, dedup, and monitoring. Actors break when the site shifts, and you find out from your data, not an alert.
Hosted REST endpoints (RealtyAPI)	Free tier, then metered per request	Minutes	Covers what is publicly visible on Vrbo. Not a booking channel: you cannot make a reservation through it.

If you are genuinely weighing building it yourself, we laid out the general trade-off in web scraping vs. using an API. Scraping wins when the data has no API at any price and your volume is tiny. It loses the moment uptime matters to somebody other than you.

What RealtyAPI's Vrbo endpoints cover

RealtyAPI runs hosted Vrbo endpoints as part of its real estate data platform. You call an ordinary REST endpoint with an API key, and proxies and anti-bot plumbing stop being your problem. Ten endpoints cover the surface:

Endpoint	What it returns
GET /autocomplete	Destinations matching a query, each with its region id, label, geo type, and coordinates
GET /search_bylocation	Listings for a free-text destination, with the full filter set below
GET /search_bycoordinates	Listings around a latitude and longitude
GET /search_bypolygon	Listings inside a polygon of three or more vertices
GET /search_byurl	Listings from a pasted Vrbo search URL, filters and dates included
GET /details_byid	Full property detail record: content, amenities, spaces, location, offers, policies, reviews overview, host
GET /details_byurl	The same detail record, addressed by listing URL
GET /reviews_byid	Paginated guest reviews with author, rating, body, stay length, and host reply
GET /host_details_byid	Host profile: display name, badges, average response time, tenure, and their other listings
GET /availability_byid	Day-by-day availability and nightly rate calendar

Auth is a single x-realtyapi-key header, responses are JSON, and requests are metered. Every response uses the same envelope, so failures arrive in a shape you can branch on rather than as an HTML error page:

{
  "message": "401: missing API key in the header",
  "source": "vrbo.com",
  "total": 0,
  "nextPage": false,
  "resultCount": 0,
  "searchResults": [],
  "detail": {},
  "reviews": [],
  "host": {},
  "availability": {}
}

The filters that make it feel like Vrbo

A generic listing API treats a beach house like a two-bedroom condo, which is how you end up unable to answer "hot tub, pet-friendly, sleeps eight, walkable to the sand, free cancellation." The search parameters worth knowing are the vacation-rental-native ones:

• checkIn and checkOut with adults and children (comma-separated child ages), because availability is the whole game in short-term rentals
• priceRange paired with pricingType, which switches between the nightly rate and the all-in total for the selected dates
• amenities: values like private_pool, hot_tub, air_conditioning, pet_friendly, washer, fireplace
• areaType and beach: lake, ski, waterfront, downtown, rural, plus on_the_beach and near_the_beach
• nearbyActivities: skiing, golfing, surfing, theme_parks, hiking, and friends
• rating floors (wonderful_9, very_good_8, good_7) and goodFor tags like cleanliness, families, location, value
• premierHost, freeCancellation, instantConfirmation, and onlyAvailable as booleans
• houseRules and accessibility, including step_free_entrance, elevator, and wheelchair_accessible
• discounts: weekly_discount, monthly_discount, last_minute_booking

The calendar endpoint is the one that matters

If you only integrate one endpoint, make it /availability_byid. It returns a day-by-day series of {date, available, rate} for a property, defaulting to a twelve-month window that you can narrow with startDate and endDate.

That single shape is the raw material for most short-term-rental analytics. Occupancy is the ratio of unavailable nights to total nights. Average daily rate is the mean of rate across bookable nights. Revenue per available night falls out of multiplying the two. Seasonality, weekend premiums, lead time, minimum-stay behaviour: all of it is derivable from a calendar sampled on a schedule. We go deeper on the modelling in short term rental analytics and on the data structure itself in the property availability calendar guide.

It is also precisely the thing neither official door will hand you for a property you do not own. Rapid prices a stay you are about to sell. The Connectivity Program shows you your own calendar. Reading the market's calendar is the gap.

Quick-start: Vrbo data in three requests

Base URL is https://vrbo.realtyapi.io, and your key goes in the x-realtyapi-key header. Vrbo is on the standard set, so the free tier reaches it; the docs cover key setup in a couple of minutes and pricing has the current request allowances.

1. Resolve the destination

curl "https://vrbo.realtyapi.io/autocomplete?input=Destin" \
  -H "x-realtyapi-key: YOUR_KEY"

Each suggestion carries a regionId, a label, a geo type (city, neighborhood, property), and coordinates. You can skip straight to search with a plain string, but resolving first is how you avoid quietly searching the wrong Springfield.

2. Search listings

curl "https://vrbo.realtyapi.io/search_bylocation?location=Destin,%20FL&checkIn=2026-11-06&checkOut=2026-11-10&adults=6&amenities=private_pool,hot_tub&beach=near_the_beach&sortOrder=Price_Low_to_High" \
  -H "x-realtyapi-key: YOUR_KEY"

Results land in searchResults. Page with page, size with resultCount (1 to 200), and keep going while nextPage is true.

3. Pull the rate calendar

curl "https://vrbo.realtyapi.io/availability_byid?propertyId=PROPERTY_ID&startDate=2026-11-01&endDate=2027-02-28" \
  -H "x-realtyapi-key: YOUR_KEY"

Entries come back as {date, available, rate}, where available: false means the night is booked or blocked by the host. Note that those two causes look identical from outside, which matters if you are computing occupancy: an owner-blocked week and a sold-out week are the same value in this field.

A production-ish Python loop

The same flow with pagination and the error handling you will want, since anything fronting live web data occasionally has a bad minute upstream:

import requests

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

def get(path, **params):
    r = requests.get(BASE + path, params=params, headers=HEADERS, timeout=60)
    r.raise_for_status()
    data = r.json()
    # Upstream trouble arrives as a populated "message" with empty results
    if data.get("message") and not data.get("searchResults"):
        raise RuntimeError(f"Upstream error: {data['message']}")
    return data

def search(**filters):
    page = 1
    while True:
        data = get("/search_bylocation", page=page, resultCount=50, **filters)
        results = data.get("searchResults") or []
        if not results:
            break
        for listing in results:
            yield listing
        if not data.get("nextPage"):
            break
        page += 1

for listing in search(location="Destin, FL",
                      checkIn="2026-11-06", checkOut="2026-11-10",
                      adults=6, amenities="private_pool,hot_tub"):
    print(listing.get("id"))

From here it is your product. Snapshot calendars nightly into Postgres and you have occupancy curves nobody else in your market has. Diff rate day over day and you have a pricing-move feed. Join /host_details_byid across a region and you can separate the single-property owners from the operators running forty units. The point of an API over a scraper is that this loop is the entire integration, with no proxy pool underneath it for you to babysit.

Five things that will trip you up

1. A Vrbo URL contains two different ids. The canonical form is vrbo.com/<listingId>?expediaPropertyId=<propertyId>, and /details_byid, /reviews_byid, /host_details_byid, and /availability_byid all want the property id. Feed them the path number and you will get confident nonsense. When in doubt, hand the whole URL to /details_byurl and let it sort out which is which.
2. pricingType silently changes what your price filter means. nightly compares against the per-night rate; total compares against the all-in total for your dates, cleaning and service fees included. Mixing the two across a dataset produces a price distribution that looks bimodal for no reason.
3. Polygon search is really bounding-box search. /search_bypolygon takes your vertices and evaluates the rectangle around them, so listings outside the shape but inside its bounding box can come back. Filter point-in-polygon on your side if the boundary genuinely matters.
4. Bedrooms and bathrooms are floors, not ranges. The format is min:N only. There is no "exactly three bedrooms" and no upper bound, so trim the tail yourself.
5. radius on coordinate search affects ranking, not membership. Vrbo organises inventory by region rather than by point-radius, so treat the radius as a hint about ordering and do real distance filtering afterwards if you need a hard boundary.

What you still can't get

Honesty section. These endpoints return what is publicly on Vrbo now: active listings, their details, reviews, hosts, and forward-looking calendars. They are not a booking channel, so you cannot reserve anything through them, and they are not a time machine. Historical occupancy comes from you sampling calendars on a schedule and storing the result, which is why the boring cron job is the actual moat in short-term-rental analytics. Start snapshotting before you need the history, because you cannot backfill it later.

Nor will you get the guest side: no personal data about travellers, no booking records, no host payout figures. That information belongs to the parties to the transaction, and no amount of API surface changes that.

If your product needs breadth beyond vacation rentals, one source will not do it. That is the reasoning behind covering the whole map the same way, whether that is what Airbnb's official API can and cannot do, why StreetEasy has no API at all, why Domain.com.au's real public API still might not let you build, or the wider field in the best real estate listing APIs compared. And if you are building on the supply side rather than the demand side, the vacation rental channel manager guide covers the other half of this story.

Key takeaways

• Vrbo has official APIs, and neither one is a listings API. Expedia Rapid exists so partners can sell stays; the Connectivity Partner Program exists so certified software can manage listings a host already owns. Read the door labels before you build.
• The address restriction is the decisive detail. Rapid will not expose a street address until a booking has been made, which removes the join key that nearly all property analytics depend on. No amount of partner status changes that.
• Vrbo entitlement fails silently. Query supply_source=vrbo without an enabled profile and you get zero results rather than an error. Budget a day to discover this, or read this paragraph twice and save it.
• Availability calendars are the highest-value data in this vertical. Occupancy, ADR and RevPAR all fall out of {date, available, rate} sampled over time, and no official Vrbo channel offers it for properties you do not own.
• Whatever route you pick, keep the integration one layer thick. When a source changes, and it will, you want to swap a single client module rather than an application's worth of parsing assumptions.

If you are building for the short-term-rental market, the fastest way to find out whether this data fits is to run the three requests above against your own market, then leave the calendar loop running for a fortnight and look at what you have that nobody else does. The free tier is enough to prove the shape of it before you spend anything.