Imported iCal blocks are never released when the source event is removed

[Bruce-and-Dakota0]

Summary

When Airbnb imports an external iCal calendar, blocking works correctly — an event in the feed blocks the night, and the calendar shows the imported calendar as the source.

Removing that event does not unblock the night. On the next sync, Airbnb drops the attribution to the imported calendar but leaves the date blocked. The night becomes an unattributed block that can only be cleared by hand.

The result is that an imported calendar can only ever add blocks. It can never remove them.

Expected: event disappears from the feed → Airbnb releases the night on the next sync.

Actual: event disappears → attribution to the imported calendar is dropped, night stays blocked indefinitely.

Steps to reproduce

1. Import an external iCal URL into a listing (Calendar → Availability → Connect calendars).
2. Publish an all-day VEVENT covering a future night, e.g.:

BEGIN:VEVENT
UID:block-2026-11-08@example
DTSTART;VALUE=DATE:20261108
DTEND;VALUE=DATE:20261109
SUMMARY:Not available
END:VEVENT

(DTEND is exclusive, so this covers exactly one night.)

1. Sync the calendar in Airbnb. The night blocks correctly and shows the imported calendar as its source. ✅
2. Remove that VEVENT from the feed so the calendar is served with no events (still a structurally valid BEGIN:VCALENDAR / END:VCALENDAR).
3. Sync again.

Result: the night is still blocked, but no longer shows the imported calendar as the source.

This is not a problem with the feed

I want to pre-empt the usual first answers, because I checked them:

• The feed is reachable and valid. HTTP 200, Content-Type text/calendar, no redirects, complete VCALENDAR, no-store cache headers, verified byte-for-byte at each step.
• The UID is stable. The same UID is used across every fetch, so a removal is unambiguous rather than looking like a re-key.
• SEQUENCE increments on every change, so each update outranks the one before it.
• Airbnb is definitely processing the change. This is the important one: the attribution to the imported calendar disappears at the moment the event is removed. Airbnb clearly reads the updated feed and acts on it — it just doesn't release the date. This rules out a stale fetch or a caching problem.
• It happens on both manual and scheduled syncs. I've reproduced it both by pressing the sync button and by leaving the calendar alone and letting Airbnb's own scheduled import run. The behavior is identical, so it isn't an artifact of the manual refresh taking a shortcut.
• I also tried explicitly cancelling the event rather than removing it — republishing the same UID with STATUS:CANCELLED and a higher SEQUENCE, which is the RFC 5545 way to retract a published event. Identical outcome: attribution dropped, night still blocked.
• Most importantly: Google Calendar behaves exactly the same. I set up a shared Google Calendar, imported its .ics into Airbnb, created an event, confirmed the night blocked, then deleted the event and confirmed it was gone from the published .ics before syncing. The night stayed blocked, unattributed — the same as with my own feed.

Two completely independent calendar sources, one of them Google's, produce the same result. That points to the importer rather than to any particular feed.

Why this matters

• Lost bookings. Every block that gets released upstream stays blocked on Airbnb. Availability silently drifts toward less availability over time, and nobody notices until a night that should have been bookable wasn't.
• It is not self-correcting. Because the attribution is gone, the orphaned block has no visible connection to the calendar that created it. There's no way to tell an intentional manual block from a stale import.
• Manual cleanup doesn't scale. Finding and clearing these by hand means auditing every future date against the source calendar.
• It affects cancellations most. The natural workflow — a booking or owner block is cancelled upstream, so the night should reopen — is exactly the case that fails.

Questions

1. Is this intended behavior? If so, is the reasoning documented anywhere? I couldn't find anything describing how the importer treats removed or cancelled events.
2. Can imported blocks be released when their source event disappears from the feed? This is the fix that would matter.
3. If not, would you consider honoring STATUS:CANCELLED? That gives an explicit, standards-defined retraction signal (RFC 5545 §3.8.1.11), which is unambiguous in a way that absence arguably isn't.
4. Failing either, is there a way to identify or bulk-clear orphaned imported blocks? Even keeping the attribution visible after the source event is gone would make cleanup possible.

Happy to provide the exact feed payloads at each step, or a test URL, if that's useful.

[Emilie]

Hi @Bruce-and-Dakota0, 

I wondered if you'd contacted the Support team yet regarding this?

It might be worth it if you think something isn't working quite as it should. 🙂

Thanks,

Emilie 

[Bruce-and-Dakota0 · Accepted solution]

@Emilie Thanks - I took your advice and asked the tech support AI chat and looks like there's no way to unblock via iCal, which is certainly too bad!

AI Assistant10:52 AM

Unfortunately, Airbnb does not currently support removing blocks via iCal feed formatting, such as using "STATUS:CANCELLED" or removing the event entirely. The system does not interpret these signals as a command to unblock dates; instead, it typically retains the block without attribution once the source event is no longer present in the feed.
Because there is no supported iCal method to trigger an automatic release of these orphaned blocks, the only way to make the nights available again is to manually unblock them individually on your Airbnb calendar or disconnect and reconnect the calendar to clear the imported history.

[Emilie]

Thanks for closing the loop and sharing this with us @Bruce-and-Dakota0!

If you think it could be a useful change to the platform in the future, perhaps you could use the official Airbnb feedback form here to share your suggestion directly with the teams.