Glossary
Glossary of OTA calendar behaviour
Why a glossary
Booking.com and Airbnb export a stay's dates, and almost nothing else. Most of what a calendar-driven cleaning schedule has to cope with has no name in their documentation, so we named it. These are the working definitions Lemon.cy's sync engine is built on.
Offering a cleaning job to several cleaners at once; the first to accept gets it and the others are told the job is taken. Used for urgent jobs and larger pools where waiting an hour per cleaner is too slow.
A rule that holds all cancellation processing for a feed when more than half of its active future bookings vanish at once and at least three of them are missing, on the assumption that this is a platform glitch or an expired link rather than mass cancellations.
Offering a cleaning job to one cleaner at a time in the property's priority order. Each offer expires after 60 minutes (10 for urgent jobs) or on a decline, then passes to the next cleaner; when the list is exhausted the host is alerted.
The principle that only a booking's checkout determines the cleaning job. A change to the check-in alone never resets a job, never drops a confirmed cleaner and never fires a "dates changed" message, because the clean happens on the day the guest leaves.
Booking.com re-exporting an in-progress stay with its elapsed nights removed, so the event's start date walks forward one night at a time while the checkout stays fixed. Lemon pins the original check-in: an arrival that has already happened is immutable.
The ordered set of checks every iCal event passes through before it can create, change or cancel a booking: presence refresh, status determination, duration skips, the reshape family, consolidation, then the update or create branch. Each guard exists because of a specific production incident.
The "Keep it" action a host takes on a booking flagged as possibly cancelled. It tells Lemon the reservation is real regardless of the feed. A hold is not permanent: after 7 days of continued absence the booking is re-raised for review, never cancelled automatically.
The last 24 hours before a checkout. Inside it, feed evidence alone may never cancel a confirmed cleaning job; a vanished booking is held for host review with its cleaner intact. This inverts the usual design, which gives imminent bookings the shortest fuse.
One iCal event covering two or more real stays that sit back to back, exported by Booking.com as a single contiguous "CLOSED - Not available" range under one UID. The middle checkout disappears from the feed; if the block exceeds 30 nights it can also be mistaken for an owner closure.
A feed serving a booking's checkout date as A, then B, then A again on successive fetches, without any change on the platform. Lemon records the last committed direction and refuses to reset the job or message the cleaner while a date keeps reverting within 48 hours.
The soft flag Lemon puts on a still-confirmed booking that has vanished from a healthy feed. The booking keeps its cleaning job and cleaner while observed absence accrues toward a confirmation window; if the booking reappears, the flag clears silently.
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.
A change to the date span of a generic "Not available" block in an OTA feed that does not correspond to a real change in any single reservation — typically Booking.com merging back-to-back stays into one block, or splitting one back out.
When a genuinely new reservation replaces one or more now-cancelled stays inside a single Booking.com block, as opposed to a merge of stays that are all still live. Lemon decides between the two by parsimony and, when unsure, asks the host.
A booking Lemon creates itself rather than reading from a feed — today, the placeholder for uncovered nights. Because no feed will ever carry its identifier, a synthetic row is a snapshot, not a subscription, and needs its own answer to "what keeps this in step with reality?".
The clean between two stays. In Lemon a turnover is a checkout cleaning job created for every guest checkout, scheduled at the property's checkout time (default 11:00) and expected to finish before the next check-in (default 15:00). A same-day turnover is when both fall on the same date.
Nights inside a skipped reshaped block that no tracked booking covers. Lemon surfaces them to the host as a "pending review" item under a stable synthetic identifier keyed on the block's checkout, asking whether they are a real stay, rather than creating or cancelling anything.