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.

Configuration Events

Configuration events audit changes to your organization's Cirrus Insight setup — settings, company profile, service accounts, and domain list. Every configuration event carries a change record in event.data: the previous state, the new state, and the user who made the change.

Use these events to meet compliance requirements around change management, mirror configuration into a source-of-truth system, or notify your team when someone changes a critical setting.

All configuration events follow the same Eventmodel envelope as scheduling events. The data shape follows a shared change history pattern with the fields below.

Shared shape: change history

Every configuration event's data payload has this common shape:

Field	Type	Description
previous	object	The domain object before the change. null on creation events (a new record was added, so there's no prior state).
current	object	The domain object after the change. null on deletion events.
modifiedBy	object	The Cirrus Insight user who made the change. Same shape as the host object on the Meeting model.

The domain-specific inner shape is documented per event below. Full field-level references live under the v0.1 configuration model docs — the shapes are unchanged from v0.1; only the outer envelope is different.

---

{
  "previous": { /* domain-specific — see per-event sections below */ },
  "current":  { /* domain-specific */ },
  "modifiedBy": {
    "userId": "usr_...",
    "email": "admin@example.com",
    "firstName": "Alex",
    "lastName": "Rivera",
    "displayName": "Alex Rivera"
  }
}

organization.setting.changed

Fires when an organization-wide setting is modified in the Cirrus Insight admin panel. Covers per-org configuration knobs (feature flags, defaults, integration toggles).

data.previous and data.current each carry the setting's value and allowUserOverride flag. data.setting carries the setting's metadata (which module owns it, its human-readable title, help text).

See v0.1 → Model → Organization Setting for the full field reference — the shape is unchanged.

---

{
  "previous": {
    "value": "true",
    "allowUserOverride": true
  },
  "current": {
    "value": "false",
    "allowUserOverride": false
  },
  "setting": {
    "module": "scheduling",
    "name": "AutoConfirmBookings",
    "default": "true",
    "title": "Auto-confirm bookings",
    "helpText": "When on, meetings booked through smart schedules skip manual confirmation."
  },
  "modifiedBy": { "userId": "usr_...", "...": "..." }
}

organization.profile.changed

Fires when your company's profile (name, web address, logo) is updated in the admin panel.

data.previous and data.current are organization-profile records:

---

{
  "previous": {
    "companyName": "Acme, Inc.",
    "webAddress": "https://acme.example.com",
    "logoUrl": "https://cdn.example.com/logo-old.png"
  },
  "current": {
    "companyName": "Acme Corporation",
    "webAddress": "https://acme.example.com",
    "logoUrl": "https://cdn.example.com/logo-new.png"
  },
  "modifiedBy": { "userId": "usr_...", "...": "..." }
}

organization.service_account.changed

Fires when a service-account configuration (Google, Microsoft, Exchange, Salesforce integration) is added, modified, or removed.

• Creation: data.previous is null; data.current is the new service account.
• Update: both previous and current are populated.
• Deletion: data.current is null; data.previous is the removed service account.

Credentials are never in the payload

For security, actual credential values (tokens, usernames, passwords) are never included. The credentials field on current only signals whether credentials were part of the change — "changed" or "unchanged". If your integration needs to react to credential rotations, key off credentials: "changed" and query the admin panel for details.

See v0.1 → Model → Organization Service Account for the full field reference.

---

{
  "previous": {
    "name": "Google",
    "domains": ["acme.example.com"]
  },
  "current": {
    "name": "Google",
    "domains": ["acme.example.com", "acme-eu.example.com"],
    "credentials": "unchanged"
  },
  "modifiedBy": { "userId": "usr_...", "...": "..." }
}

organization.domains.changed

Fires when your organization's domain list is modified. The domain list is used across organization settings to gate features per-domain.

data.previous.value and data.current.value are arrays of domain strings:

Compare the two arrays to detect which domains were added or removed. There's no separate "domain added" / "domain removed" event — one delta event fires per admin operation.

---

{
  "previous": {
    "value": ["acme.example.com"]
  },
  "current": {
    "value": ["acme.example.com", "acme-eu.example.com"]
  },
  "modifiedBy": { "userId": "usr_...", "...": "..." }
}

Compliance and audit patterns

Configuration events are frequently used to feed audit-trail systems. Practical patterns:

• Diff-and-persist: Store the full payload in your audit database, keyed by event.eventId for idempotent replay. Use modifiedBy for attribution.
• Alerting: Route specific settings to a chat channel — e.g., "auto-confirm bookings turned off" pings the ops team.
• Rollback assist: Preserve previous payloads so an operator can revert a mistaken change with one click, populating the admin panel with the prior values.

Every configuration event carries a stable correlationId — the same id is on retry attempts. Use it to deduplicate on your side and correlate across Cirrus's delivery log if you need to reconcile.