What actually happened
A Booking.com iCal feed does not carry a stable identifier for a reservation. Every event has a UID, but Booking.com changes it: when two stays sit back to back, when a stay is in progress, or for no visible reason at all. The feed also does not label events. A guest reservation, a host block and an availability closure are all exported as CLOSED - Not available.
Software that keys a booking on the UID sees the old ID disappear and concludes "cancelled". It cancels the cleaning job, stands the cleaner down, and five minutes later creates a fresh booking from the "new" event. From the host's side the reservation vanished, or flickered, or came back asking to be confirmed again.
What Lemon does instead
Lemon's sync identifies a stay by (property, feed, checkout date), never by the UID. When a UID vanishes but the same checkout still appears under a different, unclaimed UID, that is the same stay, re-keyed. Lemon re-links it, keeps the cleaning job and the assigned cleaner, and records a rekey_adopted decision so the event can be audited later.
Three other guards sit in front of any cancellation:
- Forward-trim guard — Booking.com removes the elapsed nights from an in-progress stay on almost every fetch. An arrival that has already happened is treated as immutable.
- Merged-block guard — two real stays exported as one long block are not a new booking and not a cancellation of either.
- Imminent protection — a confirmed job within 24 hours of checkout is never cancelled on feed evidence alone. It is held for the host to look at.
Evidence
- In the 30 days to 2026-09-10 Lemon fetched 18 Airbnb and Booking.com feeds 129,351 times and logged 1,445 booking decisions. 78 were re-keys adopted instead of cancelled; only 10 were automatic cancellations. Source: the OTA Calendar Feed Integrity Report.
- Before this identity rule shipped (2026-08-05), one customer's estate showed 328 of 406 bookings cancelled and 41 cancel-then-recreate pairs exactly five minutes apart — one sync interval. Every one was a re-key, not a guest cancellation.
What to do if it happens to you
- Check whether the same dates still appear in the Booking.com extranet. If they do, the guest did not cancel.
- Look for a new event in the feed with the same checkout. That is the re-keyed stay.
- Use a tool that re-links by checkout rather than cancelling on a missing ID, or ask your tool's vendor which identity it keys on.