Turo Sync via iCal: Handling Third-Party Calendar Integration Without Losing Your Mind

Some Amber Car Rental fleet vehicles are also listed on Turo. Turo doesn't offer a real-time webhook for booking events — it publishes an iCal feed per listing, meant for calendar apps, not for driving a second source of truth. Keeping the native booking system honest against that feed is its own small integration problem.

Why this is harder than "just poll the feed"

• iCal feeds are eventually consistent, not real-time — there's a lag between a Turo booking existing and it showing up in the feed.
• The feed gives you a full snapshot each time, not a diff — you have to compute what changed yourself, including cancellations, which show up as an event simply disappearing.
• A vehicle's availability window on the native side has to reflect the Turo booking before a native customer can book over it — the two systems only agree if the sync runs often enough and handles a still-visible-in-Turo-but-actually-cancelled event correctly.

The approach that held up

Poll each vehicle's feed on a fixed interval, diff the new snapshot against the last known set of Turo-sourced bookings for that vehicle, and reconcile: new events become blocked windows, vanished events get released. Every sync run is idempotent — replaying the same feed twice produces the same state, which matters because a flaky fetch shouldn't corrupt availability.

The same database-level exclusion constraint that stops two native admins from double-booking a vehicle also catches a Turo-sourced block that races against a native booking — the constraint doesn't care which system originated the row, which turned out to be the real payoff of pushing that rule into Postgres instead of application code.