Calendar & Scheduling API

Iron has a first-party scheduling engine (the native scheduler). A legacy Cal.com-backed calendar also exists as a per-org fallback. All endpoints are org-scoped via X-Org-Id unless noted as public.

Native scheduling (/scheduling)

The native scheduler owns calendars, event types, members, availability, slot computation, and booking. Routes are under /api/v1/scheduling/* and include CRUD for calendars, event types, members, and availability, plus slot and booking operations. Public, slug-keyed booking is served under /api/v1/public/scheduling/* (no org enumeration).

Key capabilities (grounded in the scheduling service):

• Per-slot and per-day caps, min-notice, pre/post buffers, round-robin priority, and collective (intersection) availability — DST-safe.
• Booking writes the same kind='appointment' activity shape and event cascade as the Cal.com webhook, so automations keep firing.
• Best-effort confirmation SMS and a .ics email invite on book / reschedule / cancel.
• Per-booking Google Meet links (with a Jitsi fallback so every booking always gets a working link).
• Optional external-calendar sync (block-busy + push) per member.

Draft

This page lists the scheduling capabilities and the public/authed split. The full per-endpoint table for /scheduling/* is still being filled in — see apps/api/src/routes/scheduling.py for the authoritative list.

Legacy calendar (/calendar)

The older calendar router exposes a simpler slot/booking surface and the Cal.com webhook. Paths are under /api/v1:

Method	Path	Description
GET	/calendar/slots	Available slots.
POST	/calendar/book	Book a slot.
GET	/calendar/appointments	List appointments.
POST	/webhooks/calcom	Cal.com inbound webhook (creates appointment activities).

The per-org engine flag (native vs calcom) selects which path is authoritative for a given subaccount. See the Calendar Booking guide.