OR tracks the Guest Listing Site Fee (what Airbnb/Vrbo charge the guest) and shows it in the booking UI under Guest Balance -- but it's not available via the API.
Request: Add a read-only field like total_guest_listing_fee to the GET /v2/bookings/{id} response.
Why it's useful: Any integration doing booking analytics, revenue reporting, or direct-vs-OTA comparisons needs this number. Right now there's no way to programmatically get the full picture of what the guest actually paid.
Our specific use case is a "direct booking opportunity" report, but I'd imagine anyone building dashboards or guest-facing pricing tools would benefit.
- Jerry
Agreed!
Thanks for the suggestion! I'm curious, do you think this is useful even though Airbnb no longer charges a guest fee?
We could certainly add it and it has relevance to Vrbo for now, but not Airbnb. I do not know where the industry is going to go as a whole, but Airbnb's move to place the entire fee on the host might result in other channels doing the same which would make this obsolete.
Thanks for the response!
You're right that Airbnb's shift reduces the guest-fee side for one major channel. But Vrbo is still charging 6-15% to guests on top of the listing price -- on a $3,000 booking that's $180-$450 -- and there's no way to get the actual number through the API today.
Without it, integrations have to estimate. We use ~8% for Vrbo as a rough midpoint of their sliding scale, but the real fee varies per booking. That guesswork adds up across a portfolio and reduces the confidence we can put behind the numbers we show OR users. We end up labeling things "(est.)" throughout our UI and explaining the estimation methodology in our help docs -- all for a value OR already tracks.
The core issue is that anyone building financial reporting on top of the OR API can't answer "what did the guest actually pay?" with full accuracy. Whether that's us, another integration, or an owner pulling data directly -- the guest-facing fee is a gap in the picture.
To your point about where the industry is headed -- if every channel eventually goes host-only, the field just returns 0 for new bookings. No maintenance burden. But the historical data from the split-fee era will matter for YoY comparisons for a while, and Vrbo isn't there yet.
A read-only field on GET /v2/bookings/{id} would let any integration consuming booking data deliver more accurate reporting to OR users.
