What each one carries
| iCal feed | Direct PMS connection | |
|---|---|---|
| What arrives | Date ranges with a UID and (sometimes) a summary | The reservation object: status, dates, guest count, platform, code |
| Cancellation | Inferred from absence | An explicit event |
| Latency | Your fetch interval (Lemon: 5 minutes) plus the platform's export delay | Webhook, seconds; Lemon also polls every 30 minutes as a backstop |
| Identity | UID, which Booking.com changes | Stable reservation ID |
| Host blocks vs guests | Indistinguishable on Booking.com | Distinguished |
| Setup | Paste a link | Authorise once (OAuth) |
| Availability | Every platform | Hospitable, Guesty, Hostaway |
When iCal is the right answer
Most hosts with 1 to 20 properties do not run a PMS; they list on Airbnb and Booking.com directly. For them iCal is the only feed that exists, and it is enough — provided the software reading it is built for what the feeds actually do. Lemon's iCal engine exists precisely because iCal is what most of its customers have.
When to move to a direct connection
- You take last-minute bookings and the five-minute plus export delay matters.
- You have back-to-back stays on Booking.com and want the second checkout to exist without a review step.
- You want cancellations to be facts, not inferences.
- You already pay for Hospitable, Guesty or Hostaway.
How Lemon combines them
Each property has a bookingSource: ical or the PMS. When a property is connected to a PMS, its iCal feeds are deactivated by the integration so the two sources never fight. Reservations from a PMS are scrubbed of personal data at ingest — Lemon keeps what scheduling needs (dates, status, a reference) and not the guest's contact details. Hospitable reservations that are on hold are treated carefully because the term covers two different situations on that platform; Lemon documents both.