How calendar sync works

Rezi uses the iCal standard to read availability from booking platforms. It’s widely supported, but it has quirks worth knowing.

A mental model that makes everything else obvious: an iCal feed is not a live connection, it’s a document. Each platform publishes a file listing its blocked date ranges at a URL, updates that file on its own schedule, and anyone holding the URL can re-download it to see the current state. “Syncing” means re-downloading the document and comparing it to last time. Every behavior described on this page, the refresh cycle, the latency, the data that’s missing, follows from that one fact.

The sync cycle

Every connected feed is re-fetched roughly every 15 minutes. Rezi compares the latest data with what it has and updates blocks accordingly. You can also trigger a manual sync from the Calendars tab.

Note that there are two clocks in play, and Rezi only controls one. Rezi re-reads each feed every 15 minutes, but the platform also regenerates its published file on its own internal schedule, which you can’t see or hurry. End-to-end latency for a new booking is the sum of both: typically minutes, occasionally longer if the platform is slow to republish. The manual sync button skips Rezi’s wait, but it can only fetch whatever the platform has currently published.

What iCal is good at, and not

• Good at: blocked/available dates, reservation date ranges
• Not included: guest names, prices, or messages, iCal only carries availability
• Latency: depends on how fast each platform refreshes its own export, which Rezi can’t speed up

The missing data is a feature as much as a limitation: because feeds carry no guest names, contact details, or payment information, sharing a feed URL exposes nothing sensitive, and platforms are willing to publish them freely. It does mean Rezi learns *that* dates are booked, not *who* booked them, guest identity enters Rezi when the guest texts or calls your building number, not through the calendar.

How the merge resolves conflicts

Strictly conservatively: blocked-anywhere means blocked-everywhere, and no feed can release a block created by another feed or by a manual block. When a reservation is canceled on its platform, that platform’s next published file no longer contains the block, and Rezi frees the dates on its next read, cancellations propagate automatically, on the same two-clock timetable as bookings. Each feed’s blocks are tracked separately under the hood, which is why one platform’s hiccup never corrupts what Rezi knows from the others.

What this means for your guests’ questions

When a guest asks Rezi about dates, the answer reflects the merged calendar as of the last sync, accurate to within the latency window described above. For quoting, Rezi layers your rates and minimum-stay rules on top of raw availability, so “is it free?” and “what would 3 nights cost?” both get real answers. The one discipline the system asks of you: enter off-platform commitments, owner stays, direct bookings, renovations, as manual blocks the moment you make them, because no feed will ever report what only you know.