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

Source: https://lemon.cy/learn/booking-com-ical-changes-uid-rekey/  
Publisher: Lemon.cy (Red Tribe Media Ltd, Limassol, Cyprus)  
Updated: 2026-09-10 · Verified against production: 2026-09-10

**Short answer:** Because Booking.com's iCal export describes unavailable date ranges, not reservations. When the range around a stay changes shape (an adjacent booking, a stay starting, trimmed nights) the export may emit a new event with a new UID for the same nights. Lemon saw 78 re-keys across 18 feeds in 30 days: about 4.3 per feed per month.

## 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](/data/ical-feed-integrity/): 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.

## Related

- [Re-key](https://lemon.cy/glossary/re-key/)
- [Reshape](https://lemon.cy/glossary/reshape/)
- [Merged block](https://lemon.cy/glossary/merged-block/)
- [Forward-trim](https://lemon.cy/glossary/forward-trim/)
- [Why did a Booking.com reservation disappear from my cleaning schedule?](https://lemon.cy/learn/booking-com-reservation-disappeared-from-cleaning-schedule/)