Skip to main content
Calendar reads start by choosing a connected account and a calendar within it. The returned calendar reference.external_id, access level, selection, and primary status matter: a name such as “Work” is not the event’s native identity. An event list covers one calendar and one explicit interval, rather than answering availability across every calendar.
The end is exclusive. Supply offset-bearing datetimes and an IANA timezone, then follow next_cursor with the same account, calendar, interval, and timezone. Events can be recurring occurrences: inspect the returned instance ID and recurring_event_id before changing one occurrence or an entire series. A partial page, an unselected calendar, or an unexamined account cannot establish that a person is free. Event changes use explicit account and calendar flags; the JSON input contains event fields, not those identities. For a fictional Meridian Labs meeting, an update might be:
Read the current event and verify calendar access before changing it. Omitted update fields remain unchanged, but a supplied attendees array replaces the whole attendee list. attendees_complete: false is independent of the event-page cursor; omit attendees for an unrelated edit, and do not reconstruct a missing list from its count. calendar create currently accepts timed events of 1–1,499 whole minutes; all-day creation and ambiguous or DST-crossing intervals are rejected. Update and delete likewise target the exact native instance or master ID and require a request key. A mutation may return a null native reference; use its action receipt and a fresh original read where possible, not a second creation just to obtain an ID. See external actions for lost responses and presentation for showing a calendar card in chat.