Why does Booking.com change the UID of an existing reservation in its iCal feed?

The export is about availability, not bookings

The iCal standard assumes a UID identifies one event for its whole life. Booking.com's export does not honour that assumption for reservations, because what it exports is the set of nights the property is closed. A reservation is just one reason a night is closed. When the set of closed nights changes shape, Booking.com is free to regenerate the events that describe it, and in practice it does:

• Back-to-back stays (one checkout is the next check-in) are frequently exported as one contiguous CLOSED - Not available block under a single new UID, replacing the two earlier events.
• A stay in progress is re-exported with its elapsed nights removed. Sometimes the UID survives; sometimes a new one appears for the shortened range.
• A cancelled-and-rebooked night range can reappear under a brand-new UID that happens to coincide with the old dates.

None of this is documented by Booking.com. Lemon learned it from 30-day retention of every fetch of every feed it syncs.

Why it matters for a cleaning schedule

If your software's idea of "this booking" is the UID, a re-key looks exactly like a cancellation followed by a new booking. The cleaning job attached to the old UID is cancelled, the cleaner is told to stand down, and a new job is created for the "new" booking — unassigned. With a five-minute sync you see the cancel and the recreate five minutes apart. Lemon's own history contains exactly that pattern: before 2026-08-05 one customer saw 41 cancel-recreate pairs each five minutes apart.

Lemon's rule

Identity is (property, feed, checkout date), never the UID. The UID is an attribute Lemon re-links, not a key it cancels on. When a tracked UID vanishes and the same checkout reappears under a different, unclaimed UID, Lemon adopts the new UID onto the existing booking and logs a rekey_adopted decision. The job and the cleaner stay exactly as they were.

The checkout date is the anchor because it is the one thing the OTA does not move on its own: a forward-trim moves the check-in, a merge moves the check-in, but the checkout is where the guest leaves, and that is also the date the clean happens on.

Numbers

From the September 2026 feed integrity report: 78 re-keys adopted in 30 days across 9 Booking.com and 9 Airbnb feeds — 4.3 per feed per month. The vast majority came from Booking.com feeds.