Preview. The endpoints on this page are illustrative and are likely to change as they move toward general availability. Documentation is published in advance so you can start shaping your integration; treat request and response details as subject to revision.

Scheduling Events

Cirrus Insight has three scheduling experiences — Smart Scheduler, personal scheduling, team scheduling — and each emits its own family of events. All three families deliver the same canonical Meetingmodel shape in event.data. Which scheduling experience produced the event is signalled by which feature sub-object on the meeting is populated:

• data.smartScheduling populated → Smart Scheduler booking
• data.personalScheduling populated → personal scheduling page booking
• data.teamScheduling populated → team scheduling page booking

There is no separate type discriminator on the payload. Presence-based feature detection is the pattern — see the Meeting model for the reasoning.

Smart Scheduler

Cirrus's round-robin scheduling experience — invitees answer a matching form; the platform routes them to an eligible host. Events in this family populate data.smartScheduling.

scheduling.smartscheduler.scheduled

Fires when a Smart Scheduler booking is created.

• data is a canonical Meeting with data.smartScheduling populated. Includes formValues (the routing form answers), surveyResponses, campaign (UTM), preview, and the scheduleId.
• data.status is "scheduled".

scheduling.smartscheduler.rescheduled

Fires when a Smart Scheduler booking's time or host changes.

• data is the updated Meeting with new startTime / endTime and possibly a new host. id is unchanged — reschedule mutates the meeting in place.
• data.status is "scheduled" (the meeting is upcoming again).
• Correlate with the original booking via data.id, which is stable across reschedule.

scheduling.smartscheduler.canceled

Fires when a Smart Scheduler booking is canceled — via the Platform API, via the self-service cancel URL, or by the host from their calendar.

• data is the Meeting with data.status = "canceled".

Personal Scheduling

Individual scheduling pages — each user publishes their own availability. Events populate data.personalScheduling.

scheduling.personalscheduling.scheduled

Fires when a personal-scheduling page is used to book.

• data.personalScheduling is populated with the page's scheduleId, surveyResponses, campaign, and the self-service rescheduleUrl / cancelUrl. No formValues — personal pages don't run a matching form.

scheduling.personalscheduling.rescheduled

Fires when a personal-scheduling booking is rescheduled.

scheduling.personalscheduling.canceled

Fires when a personal-scheduling booking is canceled.

Team Scheduling

Team scheduling pages — book against the combined availability of multiple users. Events populate data.teamScheduling, which includes an additional teamMembers list identifying the participating team.

scheduling.teamscheduling.scheduled

Fires when a team-scheduling page is used to book.

• data.teamScheduling.teamMembers is populated with each participating user. Same shape as data.host — {userId, email, firstName, lastName, displayName}.

scheduling.teamscheduling.rescheduled

Fires when a team-scheduling booking is rescheduled.

scheduling.teamscheduling.canceled

Fires when a team-scheduling booking is canceled.

Cross-feature composition

A meeting can carry multiple populated sub-objects. The most common composition: a Smart Scheduler booking that Meeting AI subsequently records will emit its scheduling event with data.smartScheduling populated, and — if Meeting AI has already produced results by the time the event fires — data.meetingAi populated as well. A later, dedicated meetingai.* event may follow with only data.meetingAi updated.

Design your handler to inspect each sub-object independently rather than switching on an assumed "meeting type." This keeps your code correct as Cirrus adds more feature sub-objects over time without you having to redeploy.

Meeting shape reference

Every field on the delivered Meeting, including all sub-objects, is documented on the canonical model page. That page is the single source of truth for the shape — this event catalog only documents which sub-objects are populated on which events.