CALENDAR SYNC · DOUBLE-BOOKING PREVENTION

Double bookings or dates blocked twice?
Both start with your iCal export

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

Two opposite failures, one root cause

Calendar sync goes wrong in exactly two directions. They need different fixes.

Under-blocking → double bookings

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.

Over-blocking → duplicate blocked dates

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.

Does this sound familiar?

These four symptoms usually share one cause.

The same nights are blocked twice

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.

You cannot edit your own reservation

Extending or shortening a stay is refused because an external block sits on those nights — a block that originated from your own feed.

A cancelled stay leaves the dates blocked

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.

It gets worse with every channel you add

Two platforms is tolerable. At three, blocks start arriving by more than one route and the calendar becomes genuinely hard to reason about.

What iCal actually is

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.

DTEND is exclusive

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.

UID must be unique

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.

The real question: native only, or everything?

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.

Duplicate overlay

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.

You lose control of your booking

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.

Provenance is destroyed

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.

The trade-off, stated honestly

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.

How to wire it properly

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.

Setup
Platforms
Links to configure
Airbnb + your direct site
2
2
Airbnb + Booking.com + your site
3
6
Add Vrbo to the above
4
12

For the common three-platform setup, those six links are:

  1. Your site's feed → imported into Airbnb
  2. Your site's feed → imported into Booking.com
  3. Airbnb's feed → imported into your site
  4. Airbnb's feed → imported into Booking.com
  5. Booking.com's feed → imported into your site
  6. Booking.com's feed → imported into Airbnb

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.

See your property as a direct booking website

Paste your Airbnb or VRBO link. Free preview in 2 minutes, no account needed.

No signup requiredNo credit cardReady in minutes

Platform specifics worth knowing

Behaviour that is documented but easy to miss.

Airbnb

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.

Booking.com

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.

Common mistakes

Five failure modes that account for most sync problems.

Chaining instead of meshing

Linking A→B and B→C does not carry A's bookings to C. Every pair needs its own link, in both directions.

Blocking the checkout day

DTEND is exclusive by design. Treating it as blocked costs you one bookable night on every reservation you sync.

Assuming sync is instant

With multi-hour polling on both sides, a same-day double booking stays possible however correct your feeds are.

Never re-checking links

Regenerate a feed URL or recreate a listing and sync stops silently. Nothing warns you. Test periodically.

Double-blocking an OTA booking

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.

Ignoring the two-year horizon

Airbnb discards anything beyond two years on import, so far-future blocks in your feed are wasted bytes on every pull.

Test your setup in five minutes

You can verify all of this yourself without any special tooling.

  1. Open your export URL directly in a browser. You should get a text file beginning with BEGIN:VCALENDAR.
  2. Read the 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.
  3. Check DTEND on a booking you know. It should be the checkout date, not the last night.
  4. Block a test date on one platform, wait for the refresh window, and confirm it appears on the other.
  5. Remove the test block and confirm it clears on both sides.

Frequently asked questions

How do I stop double bookings between Airbnb and Booking.com?
Connect every pair of channels directly rather than in a chain. For Airbnb, Booking.com and your own direct booking site that means six links, since each pair needs a connection in both directions. Missing one link creates a blind spot in exactly that direction. Because iCal polls on a delay, also consider requiring booking approval instead of instant book during peak season, or move to real-time sync.
Can iCal sync completely prevent double bookings?
No. iCal is a polling protocol, so there is always a delay between a reservation being confirmed on one channel and other channels learning about it. Airbnb refreshes roughly every three hours and other platforms are commonly in the one to two hour range. Correct configuration removes most of the risk but only real-time API sync closes the window entirely.
Why are the same dates blocked twice on my calendar?
Because a calendar feed is republishing dates it imported. If your site imports Airbnb's calendar and then exports those same dates back, Airbnb receives its own reservation as an external block sitting on top of the booking it already holds. The fix is to publish only your own reservations and manual blocks.
Should an iCal export include dates imported from other platforms?
No. An export should publish the platform's own reservations and the dates you blocked manually. Re-exporting imported dates sends each channel its own bookings back as an external block, which creates a duplicate overlay and can stop you editing your own reservation. Connect the channels directly to each other instead.
If my site only exports its own bookings, will Airbnb know about my Booking.com reservations?
Not through your site's feed. That is why every platform needs a direct link to every other platform. For Airbnb, Booking.com and your own site, that means six links in total, since each pair needs a connection in both directions.
Why does an iCal URL need to end in .ics?
Airbnb rejects import URLs that do not end in .ics. Other platforms are more forgiving, but ending the URL in .ics works everywhere, so it is the safe default for any calendar feed you publish.
How often does iCal calendar sync update?
It varies by platform. Airbnb refreshes roughly every three hours and caps manual refreshes. Others are commonly in the one to two hour range. There is always a window in which two platforms can sell the same night, which only real-time sync closes completely.
Why is the checkout day still bookable after a reservation syncs?
That is correct behaviour. In the iCal format DTEND marks the non-inclusive end of an event, so a stay from the 1st to the 5th blocks four nights and leaves the 5th available for the next guest. It is what makes same-day turnover possible.
What happens if an iCal link stops working?
Nothing visible happens, which is the danger. There is no error and no notification — the feed simply stops updating and the calendars drift apart. You can detect it in seconds: open the export URL in a browser and check that the file starts with BEGIN:VCALENDAR and that the newest reservation you expect is actually listed. If the URL returns an error page or the file is missing recent bookings, that link is dead and needs re-pasting on both sides.
Is iCal calendar sync free?
Yes. Calendar import and export are built into Airbnb, Vrbo and Booking.com at no cost, and no third-party software is required. Booking.com does apply eligibility conditions though: the property must be open and bookable, you need Rates and Availability permission in the Extranet, and it must have 20 room types or fewer with a single unit each. If you are already connected through an XML provider, iCal export is not offered.
Can I sync more than two platforms with iCal?
Yes, but the work grows faster than most hosts expect. Because feeds should carry only native bookings, every pair of platforms needs its own connection in both directions — n by n minus one links in total. Two platforms is 2 links, three is 6, four is 12. There is no shortcut: chaining A to B and B to C will not carry A's reservations through to C.
Can I sync individual rooms within one Booking.com property?
Not reliably. Booking.com's calendar sync eligibility requires each room type to have a maximum of one unit, so a property with multiple units of the same room type cannot use iCal for per-room availability. There is also a related trap for multi-listing properties: if you list both a whole home and its individual rooms, booking the whole home must block every room and vice versa. Plain iCal has no concept of that relationship, so it has to be handled manually or by software that understands the parent-child link.
Does iCal sync affect my nightly rates?
No. iCal carries availability only — dates and a short summary label, nothing else. There is no field in the format for price, minimum stay, fees or guest details. Rates have to be managed separately on each platform, or through a dynamic pricing tool that connects to each channel directly.
Is iCal enough or do I need a channel manager?
For one property on two platforms, iCal is usually sufficient. Beyond two platforms or four listings the number of links grows quickly and the polling delay becomes a real risk in peak season. That is the point at which real-time synchronisation starts to pay for itself.
Aleh Struneuski — Founder of DirectBookings

Aleh Struneuski

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.

Keep reading on calendar sync

Practical setup guides and the feature behind them.

Sources and caveats

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

Turn one-time guests into repeat direct bookings

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.

The repeat booking engine
1

Guest books on Airbnb

You pay the OTA commission

2

Stays at your property

Their only visit — for now

3

Connects to your WiFi

Branded splash page

4

Email captured

Added to your guest CRM

5

Automated follow-up

Offers & seasonal discounts

Books directly next trip

Zero OTA commission

Step 1

Direct Booking Website

Accept commission-free reservations from day one. Your own branded site with payments, calendar sync, and automated check-in — live in 15 minutes.

  • Branded booking website with custom domain
  • Stripe payments — zero booking fees
  • Calendar sync with Airbnb & VRBO
  • Pre-signed rental agreements & waivers
Start accepting direct bookings →
Step 2

Guest WiFi Marketing

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.

  • Branded WiFi splash page & guest email capture
  • Automated rebooking campaigns & seasonal offers
  • Repeat-guest discounts to win the direct booking
  • Guest CRM across all your properties — any router
See WiFi Marketing →

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.

Stop double bookings without a channel manager.

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

Double Bookings or Blocked Twice? Fix Your iCal Export