Rental Calendar Sync Check

Compare two all-day iCalendar (.ics) exports for the same rental property. Find nights blocked in only calendar A, only calendar B, or both calendars. Use the report to review calendar differences before changing availability.

This is a snapshot comparison. It does not connect to a rental platform, refresh feeds, synchronize calendars, change availability, identify actual reservations or establish double bookings. Matching blocked dates do not prove that the exports are fresh or complete. No affiliation with a booking platform is claimed.

Quick start

1. Obtain two .ics exports you are permitted to process, from calendars for the same property. Remove guest names, contact information, private notes and feed URLs before uploading; keep occupancy dates, UIDs, status and transparency properties intact.
2. Paste their text into Calendar A and Calendar B. Replace both fictional examples.
3. Choose the first night and the exclusive end date in YYYY-MM-DD format, covering 1 to 366 nights. September 10 to September 13 compares the nights of September 10, 11 and 12.
4. Check the current price and spending cap. Run the comparison and open Readable report (HTML) or Full report (JSON).

The dataset has one summary item and a report_json string containing the full report. Grouped date ranges use an inclusive start and exclusive end. Shared blocks are listed as shared, not classified as conflicting reservations. A difference may be intentional or caused by export/sync timing; investigate it on the original platforms.

Supported calendars

Each input must contain one UTF-8 VERSION:2.0 VCALENDAR, at most 256 KiB and 1,000 VEVENTs. Only all-day DTSTART;VALUE=DATE events are supported. A corresponding all-day DTEND is exclusive. If no end or duration is present, an event lasts one day. Positive whole-day/week durations such as P2D or P1W are supported. An unfolded line is limited to 8,192 characters.

Cancelled and transparent events do not block nights. Tentative events count as blocked and produce a warning. Overlapping entries are combined into occupied-night sets. An empty calendar is allowed but explicitly warns that completeness needs checking. UTF-8 BOM, CRLF/LF endings and folded lines are supported. Alarm and time-zone metadata are ignored because occupancy is restricted to calendar dates.

Timed events, recurrence rules/dates/exceptions, duplicate UIDs, repeated occupancy properties, scheduling messages and unsupported components are rejected. Expand recurring events and resolve revisions before comparing. Unsupported events are rejected even outside the comparison window. This is a restricted occupancy reader, not a complete iCalendar validator; provider-specific booking rules are outside its scope. URLs and uploaded binary files are not supported in this version.

Billing and recovery

The Store pricing panel is the source of truth. One completed comparison requests one comparison-completed event after the HTML and JSON reports are saved, including when blocked dates match. Invalid input does not request a comparison event. A budget below one comparison stops publication before a charge request. Any platform charges are shown by Apify before execution.

A restart with the same input and an existing report retains it without requesting another event. Uncertain interrupted publication stops automatic recharging. Check the original run’s output and billing before starting a separate run, which is a separate comparison. A network failure may leave a delivered report even when the run fails; failed status does not prove there was no charge.

Privacy

Processing occurs on Apify. The two calendar inputs use secret input fields but must be decrypted to compare dates. Original input storage can contain private calendar content. The report omits guest names, descriptions, UIDs, calendar names and feed URLs; it contains dates, counts and fixed explanations. Reports are not encrypted by this Actor.

Only the current run’s default storage is used. No guest data is sent to AI, no calendar URL is fetched, and no separate customer database is maintained. Application logs omit calendar text. Access and retention depend on your Apify settings. Delete the run’s input/output key-value store and dataset when no longer needed; immediate or automatic deletion is not promised. Treat storage links as sensitive.

Support

Use the Actor’s Issues tab with a run ID and a small fictional example. Never post guest information or private feed links. Suspected incorrect charges should identify the original run/event so they can be reviewed through Apify. Refunds and support follow the applicable platform terms. This pilot does not offer instant support.

Pilot version 0.1. Review the original calendars before acting on the results.