A double booking means your calendars did not share enough. Duplicate blocked dates mean they shared too much. Both come from the same misunderstanding about what a calendar feed should publish — and both are fixable in an afternoon.
Reviewed August 2026 · Platform behaviour can change after publication
Calendar sync goes wrong in exactly two directions. They need different fixes.
Two guests confirm the same nights on different platforms. This happens when a reservation never reaches a channel — either because the links are wired in a chain rather than between every pair, or because the polling delay left a gap. It costs a refund, a relocation, a damaged review and possible platform penalties.
The same nights get blocked twice, because a feed republished dates it had imported. Nobody loses a guest, but you lose visibility, you may be unable to edit your own reservation, and cancelled stays can stay stuck as unavailable.
Why double bookings are the more expensive failure. Over-blocking is loud and obvious — you can see the duplicate on your calendar. Under-blocking is silent until two guests arrive for the same week. That asymmetry is why the safe default is to publish everything you own, and to connect every pair of channels directly rather than hoping one feed will relay for the others.
Worth knowing: iCal cannot eliminate double-booking risk entirely. Airbnb refreshes imported calendars roughly every three hours, and other platforms are commonly in the one to two hour range. A reservation confirmed on one channel is invisible to the others until the next pull, so a same-day double booking stays possible no matter how correctly your feeds are configured.
These four symptoms usually share one cause.
Airbnb shows your reservation and an imported external block covering the identical dates. The calendar looks like two separate bookings when there is only one.
Extending or shortening a stay is refused because an external block sits on those nights — a block that originated from your own feed.
The reservation is gone but the nights stay unavailable, because a second system is still republishing the block back to the platform that cancelled it.
Two platforms is tolerable. At three, blocks start arriving by more than one route and the calendar becomes genuinely hard to reason about.
A plain text file, served over HTTPS, that lists unavailable periods.
iCal, or iCalendar, is a format defined by RFC 5545. Airbnb, Booking.com, Vrbo, Google Calendar and Apple Calendar all read and write it. Each unavailable period is one VEVENT, and a valid one looks like this:
BEGIN:VEVENT UID:a1b2c3d4@example.com DTSTAMP:20260826T010938Z DTSTART;VALUE=DATE:20260901 DTEND;VALUE=DATE:20260905 SUMMARY:Reserved END:VEVENT
Two details cause most of the confusion, and both are worth understanding before you debug anything.
The example above blocks four nights: the 1st through the 4th. The guest checks out on the 5th and the 5th stays bookable. This is deliberate, not an off-by-one bug, and it is what makes same-day turnover work. If your system blocks the checkout day you lose a bookable night on every single stay.
The UID is how the receiving platform recognises an event across refreshes. Two different events sharing one UID in the same file is invalid, and platforms resolve the conflict inconsistently — some keep the first, some the last, some render both. Alongside DTSTAMP, it is one of only two properties the spec marks as required.
You will find confident advice in both directions, so here is the reasoning.
A guest books on Airbnb. Your direct booking site imports Airbnb's feed and blocks those nights. Now Airbnb subscribes to your feed. Should your feed include that Airbnb reservation you just imported?
No. Publish your own reservations and your own manual blocks. Leave out anything that arrived from another channel.
This is not a fringe opinion. Beds24 ships a dedicated export option whose stated purpose is to stop re-exporting bookings that came in through its own iCal import, and Hostaway documents that every imported iCal event arrives as a reservation labelled "Blocked" — which is exactly how provenance gets lost when a feed relays data it did not originate.
Airbnb ends up showing an external block sitting directly on top of a reservation it already holds. The calendar becomes difficult to read and the same nights appear blocked twice for no reason.
With an external block covering those nights, the platform may prevent you extending, shortening or otherwise editing the reservation it owns. You end up fighting your own calendar feed.
A reservation carries context: a guest, a policy, a payout. Relayed through a third feed it arrives as an anonymous blocked range. Nothing downstream can tell what it was, or react correctly when it gets cancelled.
Native-only exports have a real cost, and it is better to know it up front.
If a feed carries only its own bookings, it does not relay one channel's reservations to another. Airbnb will not learn about a Booking.com stay through your site. That protection has to come from somewhere else — namely a direct link between every pair of platforms.
This is the part most guides skip. Native-only is the right default because over-blocking is loud and obvious while under-blocking is silent until a guest is standing at the door. But it only works if the links are wired properly, which is the next section.
You cannot chain platforms in a line. Every pair needs its own connection.
Because feeds carry only native data, linking A to B and B to C will not get A's bookings to C. The number of links you need is n × (n − 1), where n is the number of platforms.
For the common three-platform setup, those six links are:
Miss one and you have a blind spot in exactly one direction — the hardest kind of sync problem to spot, because everything looks fine until the one combination you skipped comes up.
Paste your Airbnb or VRBO link. Free preview in 2 minutes, no account needed.
Behaviour that is documented but easy to miss.
The import URL must end in .ics or Airbnb refuses it, which accounts for a lot of "the link doesn't work" confusion. Airbnb refreshes roughly every three hours and imports at most two years of data, so publishing further out achieves nothing. Its own documentation states that nights booked on a connected calendar are blocked automatically, but that nights you merely block elsewhere may or may not carry across — reservations are the reliable currency between platforms.
Export lives under Rates & Availability → Sync calendars in the Extranet, but only if the property qualifies: it must be open and bookable, you need Rates & Availability permission, and the property must have 20 room types or fewer with a single unit each. If you are already connected through an XML provider such as another channel manager, iCal export is not available.
Five failure modes that account for most sync problems.
Linking A→B and B→C does not carry A's bookings to C. Every pair needs its own link, in both directions.
DTEND is exclusive by design. Treating it as blocked costs you one bookable night on every reservation you sync.
With multi-hour polling on both sides, a same-day double booking stays possible however correct your feeds are.
Regenerate a feed URL or recreate a listing and sync stops silently. Nothing warns you. Test periodically.
Recording an Airbnb reservation on your own system to issue a check-in link? Those dates are usually already blocked by the imported feed. Blocking them again creates a duplicate that can travel back to Airbnb.
Airbnb discards anything beyond two years on import, so far-future blocks in your feed are wasted bytes on every pull.
You can verify all of this yourself without any special tooling.
BEGIN:VCALENDAR.SUMMARY lines. Every event should be one of your own bookings or manual blocks. If reservations from another platform appear, your feed is re-exporting imported data.DTEND on a booking you know. It should be the checkout date, not the last night.Founder & CEO, DirectBookings
He is the founder of DirectBookings, which he built as a vacation rental host who wanted a direct booking site without paying OTA commission. Before that he spent years building large-scale distributed systems at EPAM Systems and Amazon Web Services. He wrote this guide after tracing a duplicate-block problem through a real Airbnb feed and rebuilding the platform's calendar export to match the specification.
Practical setup guides and the feature behind them.
Reviewed August 26, 2026. Platform terms change without notice.
Format requirements are taken from RFC 5545. Refresh intervals, the two-year import window and the .ics requirement come from Airbnb's own calendar sync documentation. Booking.com eligibility rules come from its partner help centre. Verify current behaviour in your own dashboards before making operational decisions.
RFC 5545: iCalendar specification · Airbnb: sync your calendars · Booking.com: sync calendars across channels · Hostaway: custom iCal setup, sync and limitations
Most hosts never see their guests again. Every OTA stay should become your next direct booking — your website accepts commission-free reservations, your WiFi keeps your brand in front of guests long after checkout.
Guest books on Airbnb
You pay the OTA commission
Stays at your property
Their only visit — for now
Connects to your WiFi
Branded splash page
Email captured
Added to your guest CRM
Automated follow-up
Offers & seasonal discounts
Books directly next trip
Zero OTA commission
Accept commission-free reservations from day one. Your own branded site with payments, calendar sync, and automated check-in — live in 15 minutes.
Stop letting guests disappear after checkout. Capture their email when they log on to WiFi, then automatically invite them back to book direct next time.
One repeat booking often pays for your subscription many times over — there's no OTA commission the second time around. Bundle subscribers save 30% on Guest WiFi Marketing.
Two-way iCal sync with Airbnb, Booking.com and Vrbo, and an export that publishes only your own bookings — never the dates it imported. $9/month, 5-day free trial.
No credit card required · Cancel anytime