What iCal will never synchronise: the 7 limits to know before they bite

The summary table

The limit	Workaround possible?	Verdict
Rates and special offers	No	Set by hand, or channel manager
Minimum stay and stay rules	Partly: set each platform	Liveable with some rigour
Guest's name and contact details	No: the record stays on the platform	Liveable, one more journey back and forth
Pending booking requests	No	Worth knowing: a genuine blind spot
Preparation time (cleaning)	Partly: hold the dates by hand	Liveable, but treacherous
Limited horizon, often ~12 months	Partly: note it separately and check again	The most insidious trap
Arrival and departure times	Partly: the nights convention	Liveable day to day

This page is deliberately hard on the very tool we use ourselves. The iCal format is free, universal and indestructible, and that is why every platform offers it. But it was designed to exchange appointments, not to run a holiday let. Each of its limits comes to light sooner or later; better here, before it bites. To go back to basics, the format itself is explained simply in what an iCal link is.

Limit 1: rates and special offers do not travel

You lower your November price on Airbnb, and Booking.com will never know. A calendar link contains no prices at all: each platform keeps its own rate card, and every change has to be carried over by hand, everywhere. The limit usually comes to light on an invoice: a special offer applied on one platform and forgotten on the other, and stays sold at two different prices.

Workaround: none through iCal. Either you accept carrying changes over by hand, keeping a single rate card in a document and copying it out, or rates drive your business, and that is precisely what a channel manager is for.

Limit 2: the minimum stay stays local

The "3 nights minimum" set on Airbnb exists only on Airbnb. If Booking.com has stayed on 1 night, it will sell one-night stays, entirely legitimately from its point of view. The limit comes to light with a surprise booking for a single Saturday in the middle of high season.

Partial workaround: carry your stay rules over to each platform, once a season, with a checklist. It is a stable setting that does not move on its own once it is in place. What you have to give up: fine-grained rules that change with the seasons demand real discipline, or a tool that synchronises them.

Limit 3: the guest stays anonymous in the imported calendar

In the calendar a platform imports, a booking from elsewhere is called "Reserved" or "Not available" at best. No full name, no telephone number, no amount. That is not a fault: platforms protect their customer data, and in any case the format provides for very few fields. The guest's full record stays on the platform where the booking was made, and you will always have to go back there to write to them or to check a payment.

Workaround: none, and beware of the opposite. Your own export can carry more than you expect, including held dates that have nothing to do with bookings: what the Airbnb export slips into your dates is set out in the "Airbnb (Not available)" dates.

Limit 4: pending requests exist nowhere

A booking request you have not yet accepted appears in no calendar link. Until you have approved it, the dates are still shown as free everywhere, and a firm booking can land elsewhere while you are thinking it over. The limit comes to light on the day you accept a morning request when a booking arrived at midday on another platform.

Workaround: none through the format. The defence lies in how you organise yourself: answer requests quickly, and check your other calendars just before accepting, not the day before.

Limit 5: the preparation time does not travel

The cleaning day that Airbnb holds automatically after each stay goes into the export as an anonymous held period, but the setting itself never travels: the other platforms apply no gap around their own bookings, and the exported hold only reaches the other side at the next reading. The classic result: an arrival sold right up against a departure, and the cleaning done without pausing for breath.

Partial workaround: set the preparation time on each platform that offers it, and for the others, hold the buffer days by hand on the tight turnarounds. Spotting those turnarounds is in fact one of the uses of a central calendar shared with the cleaning team.

Limit 6: the horizon, often limited to around 12 months

This is the least known limit and the most dangerous. The horizon is cut on both sides, and it is not symmetrical. On the export side, Airbnb only sends the bookings for the next 12 months or so, according to the synchronisation tools that read these calendar links day in, day out (observed in August 2026). On the import side, Vrbo states that it only shows imported events for the next 365 days, while Airbnb says it imports up to 2 years of data. A booking taken 14 months ahead, a wedding for instance, may therefore travel in no calendar link at all: on the other side, those dates stay shown as free for weeks, with a real risk of a firm booking on a period already let. Hosts have been asking for a longer horizon on the platforms' forums, without success to date.

Partial workaround: for any distant booking, do not trust the automatic route. Hold the dates by hand on every platform, note the booking separately, and check again when it comes within the 12-month window. It is old-fashioned handiwork, and it is nevertheless the only reliable method.

Limit 7: arrival and departure times are rounded off

The format can carry times, but platforms think in nights: exports lay down whole days, and departures at 10 am or arrivals at 4 pm are lost along the way. Depending on the set-up, a stay may even appear to spill over by a day in a calendar, a matter of how end dates are interpreted.

Partial workaround: adopt the nights convention, the same one the platforms use: a booking covers its nights, and the departure day is free for the next arrival. Precise times are handled in your messages to guests, not in the calendars.

If these limits stand in your way, say so now

Take the test honestly: how many rows of the table really concern you? If your answer is "rates, minimum stays, and I have bookings more than a year ahead", the verdict is simple and we give it to you straight: you need a channel manager, with its direct connections that carry all of that. The weighing-up, with figures, is in channel manager or iCal.

If, on the contrary, your rates are managed by hand and your bookings fit within the year, then iCal covers your real need, free of charge. Its remaining limits are handled by good habits, and its true weak point is not in that table: it is the silent outage and the overlap discovered too late. That piece, and that piece alone, is what calendar watching takes on: checking every link every 30 minutes, and sending an email alert if there is an outage or an overlap. It lifts none of the seven limits on this page, and we would rather write that here.

This page will be kept up to date: when a platform changes its export or its horizon, we update the table, with the date on which we observed it. The limits of a tool are no scandal; discovering them at the wrong moment is.