How Vrbo iCal cleaning sync actually works (and where it breaks)

Short answer: Vrbo's iCal feed has the same shape as Airbnb's but breaks differently in five specific ways: silent cancellations (no STATUS:CANCELLED), UID rotation on date changes, host-created blocked dates mixed in with real reservations, no in-feed signal for the actual check-out time, and a stronger expectation of feed stability than Vrbo actually delivers. A cleaning sync that handles all five is the difference between Vrbo cleanings working invisibly and a cleaner showing up to a still-occupied house.

If you've set up an Airbnb-to-Jobber cleaning sync and added a Vrbo property thinking it'd "just work" — congratulations on hitting the same wall every operator hits. The iCal protocol is identical. The data shape is identical. But the way Vrbo uses the protocol differs from Airbnb in ways that quietly break cleaning automation.

This post covers what's actually different about Vrbo's iCal feed, the five Vrbo-specific quirks every cleaning operator runs into, and how a robust sync handles each. Pair it with The complete guide to scheduling STR cleanings with iCal if you want the protocol-level foundation; this post focuses on the Vrbo-specific divergences from that.

The Vrbo iCal feed at a glance

Every Vrbo listing exposes an iCal export under Calendar → Import & export → Export calendar in the host dashboard. The feed looks structurally identical to Airbnb's — a .ics file with VEVENT entries containing DTSTART, DTEND, UID, SUMMARY, and occasionally STATUS. A typical event:

BEGIN:VEVENT
DTSTART;VALUE=DATE:20260512
DTEND;VALUE=DATE:20260516
UID:vrbo-RES-A1B2C3D4-1@vrbo.com
SUMMARY:Sarah J.
END:VEVENT

Three things here are subtly different from Airbnb:

• SUMMARY contains the guest's first name (Sarah J.) — Airbnb says "Reserved." Useful for debugging but never assume your sync depends on it; Vrbo also has events labeled "Blocked" or "Owner stay."
• UID format includes "RES-" or similar prefix indicating a real reservation. Block-out events have different prefixes ("BLK-" or platform-internal).
• STATUS is almost always absent. Vrbo confirms reservations by including them in the feed and cancels by removing them. There's no in-feed cancellation signal in 95%+ of cases.

Everything else (the date format, the floating-timezone interpretation, the day-after-last-night DTEND quirk) is identical to Airbnb. Same protocol, same gotchas. The differences are operational, not structural.

The five Vrbo-specific quirks

These are the patterns that show up in production traffic on Vrbo properties that don't show up (or show up much less often) on Airbnb. A cleaning sync that doesn't handle them produces real-world failures: missed cleanings, ghost cleanings, duplicate cleanings, cleanings at wrong times.

1. Cancellations are silent UID drops, not STATUS:CANCELLED

When a Vrbo guest cancels through the platform, Vrbo might emit a STATUS:CANCELLED event in the feed for a brief window — but most operators see the booking just disappear on the next refresh. Same outcome from the cleaning operator's perspective: the UID was there yesterday, not there today.

The naive read: "the UID disappeared, so the booking was cancelled, so close the job." That's wrong, because UIDs disappear from feeds for non-cancellation reasons too:

• The fetch timed out and you got a partial response
• Vrbo's API had a hiccup and the feed served an empty calendar for 30 seconds
• The host accidentally toggled "share calendar" off and back on, briefly invalidating the URL

If your sync treats every missing UID as a cancellation, you'll mass-cancel real bookings whenever any of the above happens. The fix is a miss count + grace window: don't cancel until the same UID has been missing for at least 2 consecutive sync runs (so a one-off feed hiccup doesn't trigger it) AND at least 24 hours have passed (so a host re-saving the calendar doesn't get caught).

The exception is when an explicit STATUS:CANCELLED event does land in the feed. That's the host or guest confirming the cancellation in writing through the platform — bypass the grace window and cancel immediately.

2. UID rotation on stay modifications

If a Vrbo guest extends a stay by one night, Vrbo doesn't update the existing event with a new DTEND. It deletes the old UID and writes a brand-new event with a brand-new UID and the new dates.

A naive integration sees:

• Old UID disappeared → "cancellation"
• New UID appeared → "new booking"
• Cleaner gets two notifications back-to-back for the same property on overlapping dates
• One says "your clean is cancelled," the other says "your clean is scheduled"

This pattern shows up enough in Vrbo traffic to be a recurring source of confusion if your sync doesn't catch it. The fix: when a UID disappears AND a new UID with overlapping dates for the same property appears within the same sync window, treat it as a reschedule. Update the existing Jobber job's date in place; don't cancel-and-recreate. The cleaner sees one notification ("your Tuesday clean moved to Wednesday") instead of two contradictory ones.

This is the single biggest reason most STR cleaning sync tools that work fine for Airbnb-only operators start producing weird results when Vrbo enters the mix.

3. Block-out events mixed in with reservations

Vrbo hosts use the calendar for two purposes:

• Real reservations (a paying guest)
• Block-outs (host blocked dates manually for renovation, personal use, owner stays, etc.)

Both show up in the iCal feed. Both have UIDs. Both have DTSTART and DTEND. From the feed structure alone, they look identical.

If your sync creates a cleaning job for every event, you'll create cleanings for owner stays the host doesn't want — and the host will (rightly) be annoyed. The signal is usually in the SUMMARY field (real reservations name the guest; block-outs say "Blocked" or "Not available") or the UID prefix (RES- vs BLK- in older Vrbo formats).

Robust syncs filter on both signals before creating jobs, with the option to opt-in for "even owner stays" if the host wants the property cleaned regardless. Default off; opt-in per property.

Airbnb has a similar pattern but the language is more consistent ("Airbnb (Not available)" for block-outs vs "Reserved" for real bookings) and the volume is lower because Airbnb hosts more often use the date-blocking UI than the calendar export.

4. No in-feed signal for actual check-out time

This isn't unique to Vrbo, but it bites Vrbo operators harder because Vrbo properties tend to vary check-out time more than Airbnb's standardized 11am.

The iCal feed gives you DTEND (the day) but not the actual time the guest is required to be out. That's a platform-level setting the host configures, and the host can override it per booking ("this guest paid for late checkout"). The feed doesn't carry that override.

Implication: your sync needs a per-property "cleaning window" stored alongside the iCal URL, and the host needs to communicate any per-booking exceptions to the cleaner directly (or update the property default if a pattern emerges). The default cleaning window typically reads "checkout day, 11:00 local, 3 hours" but should be customizable per property to handle Vrbo's looser conventions.

5. Vrbo URLs are mostly stable, except when they aren't

Airbnb iCal URLs invalidate when the host clicks "reset sync." Vrbo URLs don't have an explicit reset button — they're stable across normal use. But:

• Connecting then disconnecting a third-party PMS (Hospitable, OwnerRez, Lodgify) can invalidate the URL
• Migrating a Vrbo listing between accounts (rare, but happens) issues a new URL
• Vrbo occasionally regenerates URLs as part of internal migrations (extremely rare, but operators have reported it)

The implication is the same as Airbnb's: your sync needs to surface "this iCal feed returned 404 for the last N fetches" as an actionable error, not silently skip and pretend the property has no bookings. Operators who don't get this signal find out about a broken feed when a cleaner shows up at a property they thought was empty — and the host has a "but I told you about that booking three weeks ago" complaint.

What hosts need to provide for a Vrbo cleaning sync

Whatever workflow your operation uses to onboard a new Vrbo property, ask the host for three things:

1. The iCal export URL for the listing (one per Vrbo property — no shared URL across listings)
2. Their advertised check-out time (Vrbo defaults vary; don't guess)
3. Whether they cross-list on Airbnb / Booking.com / direct site — if yes, you need those iCal URLs too, or a unified PMS feed that consolidates them

Same as Airbnb: treat the iCal URL as a password, store it encrypted, and don't include it in spreadsheets you share with cleaners.

If the host cross-lists across platforms without a unified PMS feed, your sync layer needs to dedupe events across the multiple URLs — typically by booking date for the same property. Two iCal URLs that both report a checkout on May 7 should produce one cleaning job, not two.

Cross-platform deduplication in practice

The cleanest dedup logic: per property, collect events from all configured URLs, then dedupe by (propertyId, DTEND date). The first match wins; subsequent matches are flagged as duplicates and dropped without creating a second job.

If the same property has bookings on different dates across platforms, those are real distinct bookings — no dedup. The risk is when two platforms report the same booking (because the host accepts a booking on Vrbo and that booking syncs to Airbnb's calendar to block availability). Without dedup, you create two cleaning jobs and the cleaner shows up twice.

Most STR-specific cleaning tools handle this; most generic iCal-to-calendar tools don't. If you're rolling your own, this is the test case to write first.

Tools that handle Vrbo well

Reasonable options for STR cleaning sync that supports Vrbo's quirks:

• CleanSync — free, Jobber-native, syncs Airbnb + Vrbo + Booking.com + most other iCal sources. UID rotation and silent cancellation handling are built in by default. Disclosure: this is our product.
• Turno (formerly TurnoverBnB) — paid (~$5–8/property/month), runs its own marketplace + calendar. Vrbo support is solid but doesn't push into Jobber.
• Breezeway — property-management-focused, ~$20+/property/month, comprehensive Vrbo handling but priced for ops at 30+ properties.
• Operto — IoT + cleaning workflow, similar pricing to Breezeway, good fit if you also handle smart locks.
• Hospitable — guest-messaging-primary at $30+/property/month; supports a unified iCal export across a host's connected channels (Airbnb + Vrbo + Booking.com), which is the single best fix for cross-platform dedup.

The choice depends on whether your system of record is Jobber (in which case CleanSync is the no-cost path) or a separate cleaning silo (in which case Turno/Breezeway/Operto/Hospitable each have tradeoffs).

Where to go next

If you're building or evaluating a cleaning sync that includes Vrbo, the test cases in this post are the ones that separate "works on the demo" from "works at 30 properties on Memorial Day weekend." Specifically:

• Drop a UID from the feed mid-fetch and watch what your sync does
• Modify a stay's dates and see if you get one notification or two
• Add a block-out event and verify it doesn't generate a cleaning job
• Set the property's check-out time to 10am instead of 11am and confirm the clean schedules at the right time

For the protocol-level fundamentals (what iCal is, how DTEND works, why timezones bite), see The complete guide to scheduling STR cleanings with iCal. For the Airbnb-specific equivalent of this post (and the broader Jobber integration story), see How to sync Airbnb bookings into Jobber automatically. For the cancellation policy template that goes alongside the technical handling, see Handling Airbnb cancellations without losing money on cleaners — same template applies to Vrbo.

If you want it to work on Vrbo without you having to build the dedup + UID-rotation + silent-cancellation handling yourself, CleanSync is free in the Jobber App Store. If you're not on Jobber yet, start a 14-day Jobber trial — we earn a referral commission if you subscribe through that link, at no cost to you.