Scheduling features look simple until you build them. Google Calendar speaks its own REST API with events.insert; Microsoft 365 wants Graph and POST /me/calendar/events; Apple and a long tail of providers expect CalDAV. The moment your app needs to read a user's events, drop a meeting on their calendar, or check whether three people are free at 2pm, you're staring down three integrations that disagree on field names, time formats, and recurrence rules.
The Nylas Calendar API gives you one interface over all of them. Connect a user's account once, get a grant_id, and read calendars, manage events, send RSVPs, and compute free/busy with the same request shape whether the backing provider is Google or Microsoft. This post walks the calendar surface from both sides: the HTTP API your backend calls, and the Nylas CLI for testing the same operations in a terminal.
I work on the CLI, so the terminal snippets below are the commands I actually run when I'm poking at a calendar.
Calendars, events, and the calendar_id
A connected account has one or more calendars, and every event belongs to exactly one of them. Most operations take a calendar_id, and the special value primary resolves to the account's default calendar — so you don't need to look up an ID to act on the main calendar. One exception: iCloud doesn't support primary, so for iCloud accounts you pass a real calendar ID from nylas calendar list.
