iCal Push Protocol (iPP)

White Paper v0.1 — Lestis Homes, 2026

1. Abstract

The iCalendar standard (RFC 5545) relies on passive polling: each system reads remote calendar feeds at its own interval, with no mechanism to notify connected systems when availability changes. This creates a non-deterministic synchronization window — typically between one and three hours — during which conflicting reservations can be confirmed across platforms simultaneously. Beyond the overbooking risk, passive polling generates a constant volume of outbound requests regardless of actual booking activity, the vast majority of which return unchanged data.

This paper proposes the iCal Push Protocol (iPP): a minimal, backward-compatible extension to the existing iCal ecosystem that enables active notification between systems at the moment a booking occurs. iPP relies purely on standard HTTP mechanisms, requiring no centralized infrastructure, no proprietary APIs, and no bilateral partnership agreements. Systems that do not implement iPP simply continue to operate normally on standard polling schedules.

2. The Problem

2.1 How iCal works today

iCal synchronization is passive by design. Each platform hosts a calendar file at a stable URL (e.g., platform.com/listing-x.ics). Connected systems poll that URL at their own schedule — typically every one to three hours for active OTA platforms, and up to 24 hours or more for lower-priority connections.

When a booking is confirmed on Platform B:

  1. Platform B updates its own database and its .ics file immediately.
  2. Platform A reads Platform B's .ics file — but only at its next scheduled poll.
  3. Until that poll occurs, Platform A still shows those dates as available.

This polling gap is the root cause of calendar overbooking in the short-term rental sector.

2.2 Structural inefficiency

Passive polling generates a constant volume of outbound requests regardless of actual booking activity. A system with 10,000 active iCal connections polling every two hours generates approximately 120,000 outbound requests per day. The overwhelming majority of these requests return unchanged calendar data.

iPP inverts this logic: synchronization traffic becomes proportional to actual booking activity. Polling overhead is significantly reduced during periods of low occupancy.

2.3 Who is affected

Systems with access to OTA webhook APIs receive real-time booking events, effectively reducing the synchronization window to zero. However, API access is restricted to a closed circle of certified channel management partners. The majority of systems operating in the short-term rental ecosystem — independent booking engines, regional OTAs, direct booking websites, and many Property Management Systems — rely exclusively on iCal. For these systems, the polling gap is a structural problem with no current solution.

3. iCal Push Protocol — The Proposal

3.1 Core mechanism

iPP introduces a single, optional HTTP interaction layered on top of standard iCal. When Platform B confirms a new direct booking for a listing, it queries its registry for all external systems connected to that specific listing. It then sends a payload-free HTTP HEAD request to the specific calendar endpoint provided by each of those systems.

HEAD /calendar/listing-x.ics HTTP/1.1
Host: platform-a.com
User-Agent: iPP/0.1

The request itself is the notification. No URL parameters are passed. The receiving system uses the endpoint path (/calendar/listing-x.ics) to identify which listing is affected. It then relies exclusively on its own internal database to look up which remote .ics URLs are associated with that listing, and enqueues them for an immediate poll.

3.2 Flow example

Three platforms — A, B, C — are connected to Listing X via standard bidirectional iCal:

A booking is confirmed directly on Platform B for Listing X:

  1. Platform B updates its database and its .ics file immediately.
  2. B identifies that Platforms A and C are connected to this listing.
  3. B sends: HEAD /calendar/listing-x.ics HTTP/1.1 to Platform A.
  4. B sends: HEAD /calendar/listing-x.ics HTTP/1.1 to Platform C.
  5. Platform A receives the HEAD request → identifies Listing X → immediately polls all registered remote calendars for that listing (b.ics and c.ics) → updates availability.
  6. Platform C receives the HEAD request → identifies Listing X → immediately polls all registered remote calendars for that listing (a.ics and b.ics) → updates availability.

Synchronization latency is reduced from 1–3 hours to seconds.

3.3 The "Infinite Loop" Prevention Rule

To prevent a network-wide cascade of notifications, systems must only trigger outbound HEAD requests in response to primary events (e.g., a direct booking on their own platform, a manual calendar block, or a manual cancellation).

Systems must never send outbound HEAD notifications in response to calendar changes resulting from the passive importation of a remote .ics feed.

3.4 Backward compatibility

iPP degrades gracefully. A system that does not support iPP will simply process the incoming HEAD request according to its existing configuration and continue operating on its normal polling schedule. No existing integration breaks. Adoption is incremental: iPP-capable systems benefit instantly when communicating with each other, while maintaining standard functionality with legacy systems.

4. Security & Abuse Prevention

4.1 SSRF Protection

Because the receiving system never accepts an external URL as input — resolving all poll targets from its own internal registry — Server-Side Request Forgery (SSRF) attacks are structurally impossible in this design.

4.2 Denial of Service and debouncing

The anonymous nature of the HEAD trigger could theoretically be exploited to cause request amplification (forcing a server to continuously poll remote calendars). To completely neutralize this risk, receiving systems must implement a debouncing mechanism:

  1. Acknowledge immediately: Close the HTTP connection instantly. The specific response code returned does not matter.
  2. Check timestamp: Verify the "last synced" timestamp for that listing's calendar connections.
  3. Apply a 5-minute debounce window: If the last poll occurred less than 5 minutes ago, the notification is safely dropped. No outbound requests are made. If more than 5 minutes have elapsed, the system updates the timestamp and enqueues the asynchronous GET requests.

This ensures that even if a platform is flooded with thousands of false HEAD requests, it will perform at most one polling cycle per 5-minute window per listing.

Furthermore, to reinforce the protocol's backward compatibility, platforms can continue to seamlessly apply any existing security algorithms, rate limiting, and WAF (Web Application Firewall) rules they currently use to protect their standard .ics endpoints against excessive requests. Because iPP introduces no new endpoints or payload structures, all pre-existing security measures continue to operate uninterrupted.

5. Implementation

5.1 What a system needs to implement

To send push notifications:
When a primary booking event occurs, identify all external platforms connected to the affected listing. Send a HEAD request to each of their registered calendar endpoints. Fire and forget. The sending system does not wait for, nor parse, the response body or status code.

To receive push notifications:
Handle incoming HTTP HEAD methods on your existing calendar .ics endpoints. On receipt:

  1. Acknowledge and close the connection immediately.
  2. Extract the listing ID from the URL path.
  3. Apply the 5-minute debounce check.
  4. If the check passes, enqueue an asynchronous background job to poll all remote .ics URLs registered to that listing.

Infrastructure note: Systems heavily utilizing Edge Caching or CDNs (like Cloudflare) must ensure their routing rules allow HTTP HEAD requests on .ics paths to bypass the static cache and reach the application backend, acting as the intended trigger.

5.2 Implementation estimate

For a system that already handles iCal import and export:

6. References

This document is published by Lestis Homes as an open proposal. Implementation by any system is permitted and encouraged without licensing restrictions.
Lestis Homes — https://www.lestis.homes