Last updated: June 5, 2026
iCal sync in WordPress connects your booking calendar to OTA platforms like Airbnb, Vrbo, and Booking.com by exchanging .ics feed URLs, the same standard your phone uses for calendar subscriptions. The mechanism is a pull protocol, not a push one. Each platform fetches the other’s feed on its own fixed schedule, so an updated booking is only visible after the next scheduled poll, never the instant it happens. That gap between polls is a real window, and two guests can book the same dates on two different platforms inside it, even when your ics calendar sync is configured perfectly. This is why double booking prevention with iCal alone is never absolute. A WordPress booking plugin with a native database calendar, such as WPRentals, removes this lag for direct bookings because the database itself is the record, though OTA-side bookings still arrive on a poll cycle. This article explains the mechanism, the official intervals, and why the window exists.
What the .ics File Format Actually Contains
The format is defined by RFC 5545, the iCalendar standard the IETF published in September 2009. On a rental feed, each blocked period is a single VEVENT entry. It carries a check-in date in the DTSTART field, a checkout date in the DTEND field, a label in the SUMMARY field (typically just “Reserved”), and a UID the platform uses to update or remove that block later. That is essentially all of it.
What is not in the file matters more. There is no guest name, no nightly rate, no cancellation policy, no payment data, and no minimum-stay restriction. As GleamSync notes, “Airbnb does not include guest names in iCal exports for privacy.” A Bookster explainer puts it plainly: “iCal connection shares booked dates only.”
GleamSync offers the clearest analogy: think of it as an RSS feed for your calendar. The publisher (Airbnb) updates the feed when a booking lands; the subscriber (your WordPress site or another OTA) checks it periodically and pulls in what changed. The format was built for personal appointments, not rental booking data, which is why it carries so little.
Why iCal Sync Is Not Real-Time
iCal sync works by having each platform periodically fetch a .ics feed URL from the other. This is a pull model. The platform doing the fetching decides when to check, and because the iCalendar standard has no notification or webhook, an update is only visible after the next scheduled poll.
That is the root cause of every sync problem that follows. The platform publishing the feed cannot tell anyone something changed; it updates the file and waits, and the subscriber reads it on its own schedule. You have no way to call it and say a booking just landed.
The standard does include one related property. A later extension to the standard, RFC 7986, added a REFRESH-INTERVAL property described as a suggested minimum interval for polling. The RFC states its value “SHOULD be used by calendar user agents to limit the polling interval.” That wording is advisory, not mandatory, and no platform is required to honor it.
By contrast, an API integration pushes a notification to every connected platform the moment a booking is confirmed. iCal has no equivalent, so the result is a gap, and each platform polls on a schedule that is not synchronized with the others.
How Often Airbnb, Vrbo, and Booking.com Actually Sync
Each major OTA publishes how often it polls connected calendars. The numbers come straight from their own help pages.
| OTA | Official sync interval | Source |
|---|---|---|
| Airbnb | Every 3 hours (automatic); manual refresh is rate-limited | Airbnb Help Article 99 |
| Vrbo | Every 30 minutes; initial import may take up to 20 minutes | Vrbo Help |
| Booking.com | Up to every 2 hours; manual “Import now” available | Booking.com Partner Help (updated May 15, 2026) |
Airbnb’s Help Center states that “your Airbnb calendar automatically updates every 3 hours, and pulls in information from the other calendars you’ve connected.” Manual refresh exists, but Airbnb caps it: “if you exceed that amount of updates, you’ll need to wait until the next automatic update.” Airbnb also imports up to 2 years of calendar data from a connected feed.
Vrbo is the fastest of the three. Its help page says “calendars sync every 30 minutes. You can also manually refresh at any time,” and notes that “imported events may take up to 20 minutes to appear.” Vrbo also limits you to five imported calendars per property.
Booking.com states its interval twice on the same Partner Help page: “our platform automatically imports any connected calendar every two hours, but you can manually update the imported data by clicking Import now,” and, in its FAQ, “calendars aren’t synced in real time and can take up to two hours to refresh.”
There is also an eligibility limit: a property must be small and single-unit-per-room-type, with “no more than 20 different room types, and each of those room types can only have one bookable space in them.” Large operators cannot use iCal with Booking.com at all and must arrange availability sync through an alternative method; Booking.com’s help page directs them to contact its team. The same FAQ calls a double booking from sync lag something that, “while this is rare,” can happen. Hold onto that word; a later section weighs it against the data.
How a Double Booking Happens Despite Correct Setup
Two reservations that should never coexist can coexist, because each platform is acting on a snapshot of the calendar that may be hours old. This is a race condition, and it does not require any mistake on your part. Walk through a single Saturday with a property listed on both Airbnb and Booking.com, iCal sync correctly configured in both directions.
- 2:00pm: Guest A books the property on Airbnb for the upcoming weekend. Airbnb blocks the dates immediately, and its iCal export feed updates immediately.
- 2:00pm: Booking.com last polled the Airbnb feed at 1:00pm, because it polls every 2 hours. Its next scheduled poll is at 3:00pm.
- 2:45pm: Guest B books the same dates on Booking.com. Its calendar still shows them as available, because it has not polled Airbnb’s feed since 1:00pm.
- 3:00pm: Booking.com polls the Airbnb feed and discovers the block. But Guest B’s booking is already confirmed.
The result is a double booking. The sync was correct, the feeds were working, and there was no user error. The dates were simply exposed for the 45 minutes between the Airbnb booking and the next Booking.com poll. The maximum exposure window equals the receiving platform’s polling interval: up to 2 hours for Booking.com, up to 3 hours for Airbnb, up to 30 minutes for Vrbo.
Esther Flak of Guesty frames the everyday version: “if a guest books your property on Airbnb and a different one books the same dates on Vrbo before your calendars sync, you’re left with two reservations for the same stay.” This is not a bug. iCal is doing exactly what it was designed to do. The gap exists because polling is not real-time notification.
The Real Cost of a Double Booking
Any operator who has watched a “Reservation confirmed” email arrive for dates a guest already booked elsewhere knows the sync window is not theoretical. It carries a direct financial and reputational cost when it fires. Guesty, citing Booking.com, reports that 25% of property managers and hosts experience a double booking in their first year on the platform, an attribution chain that sits oddly against the “while this is rare” language on Booking.com’s own page.
When you cancel to resolve a double booking, the penalties are concrete. Airbnb’s host cancellation policy, effective October 9, 2023, imposes a minimum fee of $50 USD. The fee scales by timing: 10% of the reservation amount if you cancel more than 30 days before check-in, 25% between 48 hours and 30 days out, and 50% of the nights not stayed if you cancel 48 hours or less before check-in or after it.
The fee is only part of it. A host-initiated cancellation costs Superhost eligibility for a year, triggers an automated review on your public profile, and, as Hosthub documents, tends to demote the listing in search.
One honest caveat: for an operator with very low booking velocity, a single property taking a few bookings a month, the odds of two bookings landing in the same gap are low. The risk scales with booking volume and the number of channels you run.
Common Workarounds and Why They Only Reduce the Window
Operators reach for several mitigations once they understand the gap. Each one helps; none removes the underlying vulnerability.
Buffer days are the first move. Blocking a day before and after each booking shrinks the window where two adjacent stays collide, but it does nothing about two guests booking the same peak weekend on two platforms during a 2-hour poll gap, and it costs you bookable nights.
Manual updates after every booking work, technically. Block the dates by hand the moment a reservation confirms and you close the window for that booking. But that only holds when you are at your desk; it fails overnight, during travel, and when two bookings land seconds apart.
Running fewer channels reduces the number of concurrent poll cycles in play, yet the remaining two-platform exposure still exists.
More frequent manual refreshes hit a wall the platforms built. Airbnb rate-limits them, warning that “if you exceed that amount of updates, you’ll need to wait until the next automatic update.”
The Bookster team describes why none of this is a fix. As they put it, “The Channel chooses when to do this, and ranges from once every couple of hours, to once a day. This means there may be times when a guest makes a booking but the Channel doesn’t ask for blocked dates immediately. This leaves opportunities for double bookings.” Each workaround changes how often the window is populated with concurrent bookings, not whether it exists.
How WPRentals’ All-in-One Calendar Eliminates Direct-Booking Lag
Disclosure: WPRentals is our own WordPress rental theme, so read this section as a vendor describing its own approach. Everything above comes from the platforms’ own documentation and the iCalendar standard, not from us.
The whole problem above comes from lag between a booking and the calendar that records it, and for direct bookings on a native WordPress calendar that lag drops to zero. When a guest books directly on a WPRentals site, the dates are blocked in its own database the instant the booking confirms, not on a poll or cron cycle. The all-in-one calendar feature treats that database as the single source of truth for direct bookings, so the iCal export URL reflects the block right away. The next time Airbnb or Vrbo polls your WPRentals feed, the dates are already marked. Because the WPRentals database is the source of truth for direct bookings, two direct bookings on the same site cannot race against each other the way polled feeds can, because the first booking blocks the dates immediately, before any second request is processed. For a full walkthrough of how to sync Airbnb and Vrbo calendars with WPRentals, the dedicated guide covers the connection steps.
WPRentals does not make iCal real-time, and the inbound direction still lags. When a guest books on Airbnb, WPRentals does not know until its next cron fires, which by default runs every 3 hours. The documentation states it plainly: “By default, the iCalendar feed sync runs every 3 hours. If you need to change the recurrence time, you can use the WP Crontrol plugin and edit the iCalendar cron job.” A second guest could book those same dates on your direct site during that window.
One caveat the docs omit: WordPress cron is pseudo-cron, firing only when the site receives a page request, so on a low-traffic site the effective interval can run longer than the configured 3 hours. Treat that as inferred WordPress behavior, not a vendor-stated figure.
Two more limits round it out. OTA-to-OTA sync (Airbnb to Booking.com) is not mediated by WPRentals at all. And when an Airbnb listing is controlled through Airbnb’s API, Airbnb may not allow iCal syncing for that listing.
WPRentals itself draws the boundary: “iCalendar synchronization is availability sync. It is not the same as a full API/channel manager integration.” The docs add that iCalendar “does not import full booking details, payments, guest messages, or reservation management data.” For a comparison of WordPress availability calendar options beyond plain iCal, the deeper guide weighs the trade-offs against a full channel manager.
Key Takeaways
- Airbnb, Vrbo, and Booking.com poll external iCal feeds on fixed schedules, every 3 hours, 30 minutes, and up to 2 hours respectively, not in real time.
- A double booking can occur within a correctly configured iCal setup whenever two guests book the same dates on two platforms during the same polling gap.
- Guesty, citing Booking.com, reports that 25% of property managers and hosts experience a double booking in their first year, a figure that sits oddly against the “while this is rare” language on Booking.com’s own page.
- A native WordPress calendar like WPRentals eliminates sync lag for direct bookings because the database is the source of truth, not a polled feed.
- No workaround, buffer days, manual refreshes, or fewer channels, removes the polling window; each only lowers the odds of it being exploited.
Frequently Asked Questions
Does iCal sync prevent double bookings?
No. It reduces the risk for low-volume operators but does not prevent double bookings structurally. Because each platform polls external feeds on a fixed schedule rather than in real time, there is always a window between a booking being confirmed on one platform and others learning about it, and a second guest can book the same dates elsewhere inside it. The structural fix is a native booking system like WPRentals or a real-time API channel manager.
How often does Airbnb sync its iCal feed?
Airbnb’s Help Center states that it automatically polls connected external calendars every 3 hours and imports up to 2 years of calendar data. Manual refreshes exist but are rate-limited: trigger too many and Airbnb pauses them until the next automatic cycle. That 3-hour interval is the maximum window for a booking made elsewhere to appear as blocked on Airbnb, and it matches the default inbound interval WPRentals uses for its own cron sync.
Why am I getting double bookings even with iCal sync set up correctly?
Correctly configured iCal sync reduces double bookings but does not prevent them, because iCal is poll-based. Each platform only sees updates when it actively fetches the feed. If a booking lands on Airbnb at 2:00pm and Booking.com’s next poll is at 3:00pm, Booking.com shows those dates as available until 3:00pm, and any booking in that gap creates a conflict. A native calendar such as WPRentals removes this lag for direct bookings, though OTA bookings still arrive on a poll cycle.
Is iCal sync real-time?
No. Booking.com’s own help page states that “calendars aren’t synced in real time and can take up to two hours to refresh.” Airbnb polls every 3 hours and Vrbo every 30 minutes. The iCalendar standard, RFC 5545, has no push or webhook mechanism, so the subscribing platform decides when to fetch. Real-time availability sync requires an API integration through a channel manager, not an iCal feed exchange; tools like WPRentals use iCal for availability and are clear about that boundary.
iCal is not broken. It was built for personal calendar subscriptions, not rental booking volume, and that gap is the whole story. The risk comes from expecting real-time behavior from something that was never real-time. Once you understand how iCal sync in WordPress really works, you can decide what exposure is acceptable for your booking volume.
Operators who want to reduce OTA-to-WPRentals lag can shorten the cron interval through the WP Crontrol plugin; those who need true real-time sync across every channel should evaluate a full API channel manager integration. Either way, the decision is now informed rather than a surprise at 3:00pm on a Saturday.
