The complete guide to scheduling STR cleanings with iCal

Short answer: an iCal feed is a permanent URL each booking platform publishes per listing — Airbnb, Vrbo, Booking.com, Hospitable, and Houfy all expose one. Your cleaning automation reads the URL on a schedule (hourly is fine), parses the DTEND date as the cleaning day, and creates a scheduled job in your field-service tool. The four things every operator gets wrong on first try: missing-UID handling, UID rotation, the day-after-last-night DTEND quirk, and floating-timezone math.

You can scroll past every "what is iCal" intro on the internet — the short version: it's a 25-year-old plain-text file format that calendars use to talk to each other. The reason you care is that every booking platform an STR host uses already publishes the rental's calendar as an iCal feed, and once you have the URL, anything that can read calendars can read your bookings.

Used right, iCal is the cleanest way to keep a cleaning schedule in sync with reality. Used wrong, it's how you end up with a cleaner showing up to a still-occupied house at 6:30am.

This is the long version. We'll cover what an iCal feed actually contains, where to find the export URL on every major platform, the four data-modeling decisions that change how you build automation around it, and the timezone arithmetic that quietly causes 80% of "the schedule was off by a day" bugs.

What's actually in an iCal feed

An iCal export is a .ics file at a permanent URL. Your booking platform regenerates the file every time someone fetches it, so it's always current.

A single rental's feed looks like:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Airbnb Inc//Hosting Calendar 0.8.8//EN
BEGIN:VEVENT
DTSTART;VALUE=DATE:20260512
DTEND;VALUE=DATE:20260516
UID:abnb-9c4e8a1f3d-0192847@airbnb.com
SUMMARY:Reserved
END:VEVENT
BEGIN:VEVENT
DTSTART;VALUE=DATE:20260520
DTEND;VALUE=DATE:20260523
UID:abnb-77b2d54e88-9381027@airbnb.com
SUMMARY:Reserved
END:VEVENT
END:VCALENDAR

Two stays. The fields you care about:

• DTSTART — check-in date.
• DTEND — the day after the last night. If a guest stays Friday and Saturday, DTEND is Sunday. Cleaning happens on DTEND (Sunday morning).
• UID — the stable identifier. Same booking, same UID, every fetch — until it isn't. We'll get to that.
• SUMMARY — Airbnb says "Reserved." Vrbo says the guest's first name. Booking.com says "CLOSED - Not available." Don't depend on its content.
• STATUS (sometimes) — CONFIRMED (default), CANCELLED (the guest pulled out), or absent.

There's also a parallel "blocked dates" range that hosts use when they manually take dates off the market. Those have UIDs too, and they show up in the same feed. You usually want to ignore them — they're not bookings, no one's checking out, and there's no clean to schedule.

Where to find the export URL on each platform

This is the part most STR hosts can't do without help. The exact menu paths change a few times a year, but the general locations are stable.

Airbnb

Listing → Availability → Sync calendars → Export calendar. Click the URL to copy. There's one URL per listing, not one URL per Airbnb account — if a host has six listings, you need six URLs.

Airbnb regenerates the URL if a host clicks "reset sync" in calendar settings. If your old URL stops returning data, that's likely why.

Vrbo

Calendar → Import & export → Export calendar. Same model — one URL per listing. Vrbo URLs are stable across resets but invalidate if a host disconnects a third-party integration that touched the calendar.

Booking.com

Calendar & Pricing → Sync calendars → Export calendar. Booking shows the export URL alongside any imports. Same per-listing model.

Hospitable (formerly Smartbnb)

If a host uses a property management system like Hospitable, the PMS itself can publish a unified iCal feed across all of that host's connected platforms. This is the cleanest setup if available — one URL covers Airbnb + Vrbo + Booking.com for that property, and the PMS handles cross-platform conflicts. Hospitable's path is Properties → [property] → Channels → Export calendar.

Houfy

Listing → Calendar → Export Houfy calendar. Houfy's calendar export is per-listing and stable.

Direct-booking sites (OwnerRez, Lodgify, etc.)

Most direct-booking platforms publish iCal — check their Calendar Sync or Channel Manager settings. If a host runs their own site without a booking engine, they don't have an iCal feed to give you, and you're back to manual entry for that channel only.

What hosts actually need to send you

Whatever workflow your cleaning ops uses to onboard a new property, the host-facing ask should be three things:

1. The iCal export URL for each platform the property is listed on.
2. The check-in / check-out times the host advertises (so you know when "checkout day" actually means "11am" vs "10am").
3. A backup contact method for the guest in case you arrive and the door code didn't work — not for changing bookings, just for site-of-clean issues.

That's it. Don't ask hosts to "share their calendar" — that's a different feature in Airbnb (calendar collaboration) and they'll send you the wrong thing. Specifically ask for "the iCal export URL ending in .ics" and link to the right help article on whichever platform they use.

Treat the iCal URLs like passwords. Anyone with the URL can read every booking on that listing — dates, UIDs, sometimes guest first names. Store them somewhere encrypted. Don't paste them into spreadsheets you share with cleaners.

The four modeling decisions that determine how brittle your automation is

If you're building (or evaluating) an iCal-to-cleaning-schedule integration, these four decisions matter more than the rest.

1. How you treat the missing-UID case

A UID disappears from a feed for one of three reasons:

• The host explicitly cancelled in their PMS (Airbnb usually emits STATUS:CANCELLED first, then drops the UID; Vrbo usually just drops it).
• The feed timed out mid-fetch and you got a partial response.
• The host disconnected and reconnected the calendar, which can briefly null out the feed.

If your integration cancels the corresponding clean the moment a UID disappears, you'll mass-cancel jobs every time the platform has a hiccup. The fix is a miss count + grace window: don't cancel until the same UID has been missing for at least N consecutive sync runs and M hours have elapsed. Two-and-twenty-four (2 misses + 24 hours) is a reasonable default; tighter if your sync runs more often than hourly.

The exception: an explicit STATUS:CANCELLED event in the feed should bypass the grace window and cancel immediately. The host has confirmed the cancellation in writing — you don't need to wait it out.

2. How you treat UID rotations on date changes

Vrbo, in particular, doesn't update events when a guest extends or shortens a stay. It deletes the old UID and writes a new one with the new dates. A naive integration sees this as "old booking cancelled, new booking added" and fires both notifications.

The cleanest fix: when a UID disappears AND a new UID with overlapping dates appears for the same property within the same sync window, treat it as a reschedule. Update the existing job in place; don't cancel-and-recreate.

3. How you compute the cleaning window

DTEND gives you the calendar day. Most cleans aren't scheduled at midnight on that day — they're at 11am, 1pm, whenever the host's checkout time is. So the integration needs a per-property "cleaning window" stored alongside the iCal URL, and it applies that window in the property's local time, not the server's.

If you're hand-rolling this, store the cleaning window as {startHour, durationMinutes} and the property's timezone as IANA name (America/Denver, Pacific/Honolulu, etc.). At job-creation time, take the DTEND calendar date, apply the property's startHour in the property's timezone, then convert to UTC for storage. Skip this and your Hawaii cleans will drift one day per sync run.

4. How you handle back-to-back checkouts

If a guest checks out on Sunday and another guest checks in the same Sunday, you've got a turnover window of a few hours and the cleaner needs to be there. iCal makes this easy to detect: two events where one's DTEND equals the next one's DTSTART. Most operators want a flag on the cleaning job ("Same-day turn") so the cleaner knows the deadline is real, not aspirational.

Worth noting: a calendar export will not tell you the actual check-out time and check-in time. Those are platform-level defaults the host can override per booking. If you need precise turnover timing, you need to ask the host directly — the iCal feed alone won't give it to you.

Timezones, the part everyone gets wrong

iCal lets you express dates three ways:

• Floating (DTSTART;VALUE=DATE:20260512) — no timezone. Means "May 12 in whatever timezone the reader thinks is the right one."
• UTC (DTSTART:20260512T140000Z) — explicit UTC time.
• TZID-referenced (DTSTART;TZID=America/Denver:20260512T100000) — explicit local time in a named timezone, with the timezone definition embedded earlier in the file.

Airbnb feeds emit floating dates. Vrbo emits floating dates. Most PMS feeds emit floating dates. Which means: your integration is responsible for picking a timezone and applying it consistently.

The right answer is "the property's timezone, not the server's." If your sync Lambda runs in us-east-2 (Ohio) and you naively interpret a floating 20260512 date as UTC, the property in Maui will show a check-out date that's a calendar day off depending on when the cron fires. Don't do that. Store the property's IANA timezone alongside its iCal URL and convert intentionally.

If you can't get the property's timezone from the host, default to the host's account timezone in your CRM, then to UTC. Both are wrong some of the time, but one of them is wrong less often.

A reasonable default sync cadence

For a cleaning operation:

• Hourly is plenty. Bookings don't change so fast that 15-minute polling buys you anything except CPU bills.
• Daily is too slow — a Saturday-morning cancellation that doesn't make it to the cleaner until Sunday afternoon is a wasted truck roll.
• The first sync after onboarding a property should pull the full forward window (3–6 months) so you don't miss a clean that's already 30 days out.
• After that, you only need the next 3 months unless the host books long-term stays.

If you're using a tool that polls more aggressively than hourly, ask why — it usually means they're charging per-property and want to look like they're doing more work for the money.

What to do with this

If you're a cleaning operator and a host hands you an iCal URL, you've got the source of truth. Whether you turn it into a Jobber job, a Google Calendar event, an entry in your cleaner-tracking spreadsheet, or a Slack message to the cleaner the night before — same input, different surfaces.

If you want it to land directly in Jobber as a scheduled job, CleanSync does exactly this and is free in the Jobber App Store — see How to sync Airbnb bookings into Jobber automatically for the step-by-step. If you want to build it yourself, this post has all the gotchas to dodge.

For Vrbo specifically (UID rotation, missing STATUS:CANCELLED events, and the differences from Airbnb that matter for cleaning automation), see How Vrbo iCal cleaning sync actually works. For the cancellation policy template that goes alongside the technical handling, see Handling Airbnb cancellations without losing money on cleaners.

If you're a host reading this because your cleaner asked: just send them the iCal URL from each of your listings, plus your check-in/check-out times. They'll handle the rest.