# Re-key

Source: https://lemon.cy/glossary/re-key/  
Publisher: Lemon.cy (Red Tribe Media Ltd, Limassol, Cyprus)  
Updated: 2026-09-10 · Verified against production: 2026-09-10

**Short answer:** When an OTA's iCal feed stops exporting a stay under one UID and exports the same nights under a new UID. Common on Booking.com. To software keyed on the UID it looks like a cancellation followed by a new booking; Lemon re-links the stay by its checkout instead.

The iCal standard treats `UID` as a permanent identifier for an event. Booking.com's export does not, because what it exports is the set of unavailable nights, not reservations; when that set changes shape, the events describing it may be regenerated with fresh identifiers. Airbnb re-keys far less often but is not immune.

Lemon's rule 1: identity is `(property, feed, checkout date)`, never the UID. When a tracked UID is absent from a healthy feed and the same checkout is present under a different, unclaimed UID, the new UID is adopted onto the existing booking and a `rekey_adopted` decision is logged. The cleaning job and its cleaner are untouched.

In the 30 days to 2026-09-10, 78 re-keys were adopted across 18 feeds — about 4.3 per feed per month.

## Related

- [Reshape](https://lemon.cy/glossary/reshape/)
- [Forward-trim](https://lemon.cy/glossary/forward-trim/)
- [Merged block](https://lemon.cy/glossary/merged-block/)
- [Why does Booking.com change the UID of an existing reservation in its iCal feed?](https://lemon.cy/learn/booking-com-ical-changes-uid-rekey/)