Skip to content

How to list Google calendar events

Google Calendar is the most common calendar provider developers integrate with, and the Google Calendar API comes with more setup friction than you might expect. Between the GCP project configuration, the tiered OAuth scope system, and Google’s restricted-scope security assessment, there’s a lot of overhead before you can make your first API call. On top of that, Google has its own concepts like event types (focus time, out of office), numeric color IDs, and non-standard recurring event behavior that don’t map cleanly to other providers.

Nylas normalizes all of that. You get a single Events API that works across Google, Microsoft, iCloud, and Exchange without provider-specific branching. This guide covers listing events from Google Calendar accounts and the Google-specific details you should know about.

Why use Nylas instead of the Google Calendar API directly?

Section titled “Why use Nylas instead of the Google Calendar API directly?”

The Google Calendar API requires more scaffolding than most developers anticipate:

  • GCP project and OAuth consent screen - You need a GCP project, an OAuth consent screen, and the correct calendar scopes configured before anything works.
  • Three-tier scope system - Google classifies calendar scopes as non-sensitive, sensitive, or restricted. Restricted scopes (like full read-write) require a third-party security assessment before you can go to production.
  • Google-specific data model - Event types (outOfOffice, focusTime, workingLocation), numeric color IDs, and Google Meet auto-attachment are all concepts that don’t exist on other providers.
  • Recurring event quirks - Google marks cancelled occurrences as hidden events instead of removing them, and returns unsorted results when querying by master_event_id.

Nylas handles token management, scope negotiation, and data normalization. If you only need Google Calendar and want fine-grained control over every Google-specific field, the native API works. If you need multi-provider support or want to skip the verification process, Nylas is the faster path.

You’ll need:

New to Nylas? Start with the quickstart guide to set up your app and connect a test account before continuing here.

Google classifies OAuth scopes into three tiers, and each one comes with different verification requirements:

Scope tierExampleWhat’s required
Non-sensitivecalendar.readonly (metadata only)No verification needed
Sensitivecalendar.events.readonlyOAuth consent screen verification
Restrictedcalendar.events, calendarFull security assessment by a third-party auditor

If your app only needs to read events, the calendar.events.readonly scope is classified as sensitive. For full read-write access to calendars and events, you’ll need the calendar scope, which is restricted and requires a security assessment.

Nylas handles token refresh and scope management, but your GCP project still needs the right scopes configured. See the Google provider guide for the full setup.

Make a List Events request with the grant ID and a calendar_id. The calendar_id parameter is required for all events requests. You can use primary to target the user’s default calendar. By default, Nylas returns the 50 most recent events sorted by start date:

The same code works for Microsoft, iCloud, and Exchange accounts. Just swap the grant ID and Nylas handles the provider differences.

You can narrow results with query parameters. Here’s what the Events API supports:

ParameterWhat it doesExample
calendar_idRequired. Filter by calendar?calendar_id=primary
titleMatch on event title (case insensitive)?title=standup
descriptionMatch on description (case insensitive)?description=quarterly
locationMatch on location (case insensitive)?location=Room%20A
startEvents starting at or after a Unix timestamp?start=1706000000
endEvents ending at or before a Unix timestamp?end=1706100000
attendeesFilter by attendee email (comma-delimited)[email protected]
busyFilter by busy status?busy=true
metadata_pairFilter by metadata key-value pair?metadata_pair=project_id:abc123

Google accounts also support these additional filter parameters:

ParameterWhat it doesExample
show_cancelledInclude cancelled events?show_cancelled=true
updated_afterEvents updated after a Unix timestamp?updated_after=1706000000
updated_beforeEvents updated before a Unix timestamp?updated_before=1706100000
ical_uidFilter by iCalendar UID[email protected]
master_event_idGet occurrences of a recurring event?master_event_id=evt_abc123

Here’s how to combine filters. This pulls events with “standup” in the title within a specific time range:

Google Calendar supports event types beyond standard calendar events. These are Google-only and won’t appear on other providers. By default, the Events API returns only default events. To retrieve other types, you must explicitly filter for them using the event_type parameter.

Event typeDescription
defaultStandard calendar events. Returned by default if event_type is not specified.
outOfOfficeOut-of-office blocks set by the user. Automatically declines new invitations during the blocked time.
focusTimeFocus time blocks. Mutes notifications during the blocked time.
workingLocationWorking location events that indicate where the user is working from (office, home, or another location).

Event types don’t mix in a single request. You can only filter for one event type at a time. If you need both default and outOfOffice events, make two separate requests.

A few provider-specific details that matter when you’re building against Google Calendar and Google Workspace accounts.

The outOfOffice, focusTime, and workingLocation event types only exist on Google Calendar. Microsoft has similar concepts (like focus time in Viva), but they surface differently through the API. If you’re building a multi-provider app, you’ll need to handle the case where these event types simply don’t exist for non-Google accounts.

Also worth noting: these event types are only returned when you explicitly filter for them. A standard list request without event_type returns only default events, so you won’t accidentally pull in out-of-office blocks.

When a Google Calendar user has Google Meet enabled (most do), new events often get a Meet link auto-attached. Nylas returns this in the conferencing object on the event:

{
"conferencing": {
"provider": "Google Meet",
"details": {
"url": "https://meet.google.com/abc-defg-hij"
}
}
}

You can also manually add conferencing when creating events through Nylas, including Google Meet, Zoom, and Microsoft Teams links.

Google supports numeric color IDs for event-level color overrides. These map to a fixed set of colors in Google Calendar’s UI. The color ID appears in the event response as a string (like "1" through "11"). Other providers handle event colors differently or not at all, so don’t rely on this field for cross-provider consistency.

When you use master_event_id to fetch occurrences of a recurring event from a Google account, the results come back in a non-deterministic order. Unchanged occurrences typically appear first, followed by modified occurrences, but this isn’t guaranteed. Sort the results by start_time on your end if order matters.

For more details on how Google handles recurring event modifications and deletions compared to Microsoft, see the recurring events guide.

When a user deletes a single occurrence from a recurring series in the Google Calendar UI, Google doesn’t actually remove the event. Instead, it marks the occurrence as cancelled and creates a hidden master event to track deleted occurrences. That master event has a different ID from the individual occurrences.

To retrieve cancelled events, pass show_cancelled=true in your request. One important detail: Google does not reflect cancelled occurrences in the EXDATE of the primary recurring event. If you’re using EXDATE to track which occurrences were removed, you’ll get incomplete results for Google accounts.

Google enforces calendar API quotas at two levels:

  • Per-user: Each authenticated user has a per-minute and daily quota for API calls
  • Per-project: Your GCP project has an overall daily limit across all users

Nylas handles retries when you hit rate limits, but if your app polls aggressively for many users, you may exhaust your project quota. Two ways to reduce this:

  • Use webhooks instead of polling so Nylas notifies your server when calendar events change
  • Set up Google Pub/Sub for real-time sync, which gives faster notification delivery for Google accounts

Both personal Google accounts and Google Workspace accounts work with Nylas, but there are differences worth knowing:

  • Workspace admins can restrict which third-party apps have access. If a Workspace user can’t authenticate, their admin may need to allow your app in the Google Admin console.
  • Service accounts are available for Google Workspace Calendar access, which lets you read and write events without individual user OAuth flows. See the service accounts guide.
  • Domain-wide delegation lets a Workspace admin grant your service account access to all users in the organization, which is useful for enterprise calendar integrations.

The Events API returns paginated responses. When there are more results, the response includes a next_cursor value. Pass it back as page_token to get the next page:

Keep paginating until the response comes back without a next_cursor.