The Vrbo API: how access works, and what you can build today

The confusion is worth naming, because it is where most of the bad information comes from. Vrbo sits inside Expedia Group, and Expedia Group runs several developer surfaces that are not the same thing. The one that matters if you manage or build software for vacation rentals is Vrbo's own connectivity — the integration a property manager's software uses to keep rates, availability and bookings in step with Vrbo. A page that tells you to go and get a Vrbo API key in ten minutes is describing something else.

• Listings — listing details, rental rates, lodging configurations and availability.
• Online booking — generate quotes, check availability, book reservations, update reservation records.
• Reviews — share property reviews for display on Vrbo.
• Inquiries — retrieve rental inquiries submitted through Vrbo.

Expedia Group describes the outcome plainly: with API connectivity, rates, availability and bookings update dynamically from your software to Vrbo, and pricing, calendars and cancellation policies are controlled from your software rather than from the Vrbo extranet. The direction of travel matters — Vrbo connectivity is built around your system being the source of truth and pushing, which is a different mental model from Airbnb's request-and-consent OAuth.

curl https://api.repull.dev/v1/channels/vrbo/listings \
  -H 'Authorization: Bearer sk_live_...'

# { "listings": [ { "id": "...", "name": "...", "status": "active" } ] }

curl 'https://api.repull.dev/v1/channels/vrbo/reservations?limit=50' \
  -H 'Authorization: Bearer sk_live_...'

# Page with the cursor from pagination.nextCursor.
# ?offset= is accepted as a first-class alias for shallow paging.

The channel endpoints answer “what does Vrbo have”. For anything you would put in front of a human — the guest, the payout, the policy the stay was booked under — read the cross-channel surface instead, where a Vrbo booking arrives in the same shape as an Airbnb one.

# The same reservation, with everything on it, from the
# cross-channel read — guest, price breakdown, policy code.
curl 'https://api.repull.dev/v1/reservations?platform=vrbo&limit=50' \
  -H 'Authorization: Bearer sk_live_...'

# Conversations and reviews take the same filter:
#   /v1/conversations?platform=vrbo
#   /v1/reviews?platform=vrbo
# Properties filters on the channel it is published to:
#   /v1/properties?channel=vrbo

• Freshness. Vrbo reservations come from the public booking feed and typically lag Airbnb and Booking.com by five to ten minutes. Build for eventual consistency, not for sub-second.
• Paging. Both endpoints are cursor-paginated; ?offset= is accepted for shallow paging and is mutually exclusive with cursor.
• Inactive listings. A deactivated listing keeps syncing but drops out of these reads, counts and cursors included. Find them with GET /v1/listings?status=inactive.
• Creating bookings. POST /v1/reservations is restricted to direct, website and owner. A Vrbo stay is owned by the channel and arrives through sync; minting one locally would only fight the next sync.

Full depth on the other two: the Airbnb API guide and the Booking.com API guide.

1. 1What exists. The activation connect flow and the two read endpoints. A workspace can hold a Vrbo connection, and Vrbo data flows into the cross-channel reads alongside every other channel.
2. 2What does not. Every write. Pricing, availability, content, mapping, messaging sends, review replies, and disconnect.
3. 3What that means for you. Vrbo is safe to design a reporting, CRM or reconciliation feature around today. It is not safe to design a rate-push feature around today.
4. 4What to do if you need more. Tell us what specifically you need and when. A dated, named requirement from a real build is what moves a channel up the queue — a general “do you support Vrbo?” does not.

It is worth being concrete about the gap, because “we'll just use iCal” is a decision teams regret two months in. A calendar feed gives you a date range and a label. It does not tell you who booked, what they paid, what they asked in the message thread, which policy applies if they cancel, or whether the price on the listing is still the price you meant to charge. Every one of those lives behind connectivity.

• A single reservation feed that is not missing a channel — Vrbo bookings land in the same normalised shape as Airbnb and Booking.com ones.
• Occupancy, ADR and revenue reporting where the Vrbo share is actually counted rather than estimated.
• A guest CRM that recognises the same guest across channels instead of creating a third profile.
• A cross-channel double-booking guard, which is exactly the job the Vrbo read is good at.
• Owner statements that reconcile, because the Vrbo stays are in the same ledger as everything else.

Start with the docs, or read how the same reasoning applies to the other two big channels in the Airbnb and Booking.com guides. If you are a SaaS platform planning to put this in front of your own customers, the commercial shape is covered in Repull for platforms, with the deeper technical version in the SaaS platform Q&A.