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.

AvailableSlot object

An AvailableSlot represents a bookable time window returned by POST /api/v1alpha1/smart-schedules/{id}/availability, nested under each host in the hostGroups structure. Each slot carries a slotToken — an opaque, HMAC-signed string that you pass verbatim to POST /api/v1alpha1/scheduled-meetings (or PATCH /api/v1alpha1/scheduled-meetings/{id}) to book or reschedule.

The AvailableSlot schema

{
  "startTime": "2026-06-16T17:00:00Z",
  "endTime":   "2026-06-16T17:30:00Z",
  "slotToken": "eyJzY2hlZHVsZUlkIjoic2NoZWRf..."
}

Fields

---

startTime string

Slot start, ISO 8601 in UTC.

---

endTime string

Slot end, ISO 8601 in UTC. Equals startTime plus the effective durationMinutes (the schedule default, or the value passed on the availability request).

---

slotToken string

An opaque, signed string. The token encodes the schedule, host, start time, end time, and an expiration timestamp — all signed with a server-held secret so tampering is detectable.

The format is intentionally opaque and unprefixed: do not attempt to parse, modify, or generate slot tokens client-side. Treat them as you would a one-time URL.

---

Slot semantics

Token lifetime

Slot tokens are valid for 10 minutes from the moment /availability returns them. After that window:

• POST /scheduled-meetings returns 410 slot-token-expired
• PATCH /scheduled-meetings/{id} with an expired token returns 410 slot-token-expired

Refresh availability and pick a new slot.

Slot may go stale within the TTL

A slot can become unbookable before its 10-minute TTL expires — most commonly because the host accepted another meeting on their calendar in the interim. In that case the book/reschedule call returns 409 slot-conflict with rerunAvailability: true:

Recommended retry pattern: re-call /availability with the same form values, select a fresh slot, and retry the booking.

Preview-mode slots

If /availability was called with preview: true, the issued slot tokens carry a preview flag. When used to book, the resulting meeting will:

• Not trigger webhook delivery
• Not sync to CRM

The meeting still appears on the host's calendar — preview mode is for testing the end-to-end booking flow without producing webhook traffic or CRM records, not for testing without creating any calendar event.

Tampering

A slot token whose signature fails to verify — or whose payload doesn't match the request context (wrong schedule id on the path, wrong meeting on a reschedule) — is rejected with 422 slot-token-invalid. Do not retry the same token; call /availability again.

Concurrency

Slot tokens do not reserve the slot. Two callers holding slot tokens for the same time may both attempt to book; the second POST /scheduled-meetings will receive 409 slot-conflict once the first booking is committed. Build your client to handle this — agents should be prepared to retry availability + book on conflict.

{
  "type": "https://docs.cirrusinsight.com/platform-api/errors/slot-conflict",
  "title": "Slot is no longer available",
  "status": 409,
  "detail": "The selected slot conflicts with the host's calendar.",
  "rerunAvailability": true
}