MMichael Z Consulting
all cases
case 04 · Short-term rental

STRSync

Daily Notion sync for short-term rentals: each property's iCal feeds → computed availability fields, written back to the right Notion row.

Make.comNotion APIiCalHTTP
[demo video coming soon]
/ the problem

A property manager tracks the portfolio in Notion (one row per property) but availability lives in Airbnb / VRBO / Booking.com iCal feeds. Manually checking 'when's the next free week for property X' across 10+ properties is a daily 30-minute chore that goes stale by lunch.

/ the approach

A scheduled Make scenario runs every morning: for each property row in Notion, fetch the iCal feed, parse busy ranges, compute (next available date, booked-through date, monthly free/booked flags), and write back to the existing Notion row — never create a new one. Idempotent so re-running mid-day is safe.

/ the outcome

The Notion DB is the single source of truth for availability by 8am every day. Manager can ask 'which properties have a free week in June?' as a Notion filter, not a 30-minute spreadsheet exercise.

/ engineering notes

Update existing row, never create

The first failure mode of any Notion-write scenario is duplicate rows. We look up by property ID (not name) and PATCH the existing row. If the lookup misses, we log and skip — never insert.

iCal parsing on bare HTTP, no SDK

iCal is a thin text format. Pulling in a heavy parser library would obscure the failure modes. We fetch via HTTP, parse VEVENT blocks directly in a Make Tools module, and surface parse errors as scenario failures (not silent skips).

Idempotent by design

Re-running the scenario at noon produces the same Notion state as the 8am run. No 'did I already run today' flag needed — the writes are derived from the iCal state at fetch time.

Got a workflow that looks like this?

Run the free 5-minute diagnostic — I'll tell you whether it's a $0 weekend project or a 2-week build.