Google Calendar Ownership Changes

What changed

Google now enforces a dedicated ownership model for every secondary calendar. Before 2026, deleting a Google account left its secondary calendars intact as ownerless "orphans." Starting April 27, 2026, orphan calendars on personal accounts are permanently deleted. Workspace orphans follow on October 5, 2026, giving organizations roughly 6 additional months to prepare.

According to Google's November 2025 announcement, every secondary calendar now requires a single, dedicated owner. Shared team calendars, project calendars, and Google Classroom calendars can no longer exist without one. Google reports that over 3 billion calendar events are created each year across Workspace alone, so the scope of this change is significant.

The deletion behavior is split by account type. Personal Google accounts start losing orphan calendars on April 27, 2026. Google Workspace accounts do not switch to deletion until October 5, 2026, and Google says orphan Workspace calendars continue through an auto-assignment process until that date when another user already has Make changes and manage sharing access. If your integration creates calendars on behalf of users, or your organization relies on calendars created by former employees, act before the enforcement date that applies to your account type.

Timeline

Google is rolling out the calendar ownership policy across 5 milestones spanning 12 months, from November 2025 through October 2026. Personal accounts face enforcement first, while Workspace accounts get an extended window. Each milestone introduces a specific change to how secondary calendars are handled.

The March 2026 update pushed the Workspace deadline from the originally planned date to October 5, giving admins more time. Personal account enforcement starts April 27 as scheduled.

What breaks

The new ownership enforcement breaks any workflow that depends on orphan calendars surviving after the creator's account is deleted. Shared team calendars, Google Classroom calendars, and service-account-created calendars are the 3 primary categories at risk. Each fails differently depending on whether the account is personal or Workspace.

Shared team calendars

Once the policy is enforced for the relevant account type, a team calendar created by a departing employee is deleted when their account is removed unless ownership was transferred first. Every subscriber -- colleagues, bots, integrations -- loses access. Events, attachments, and meeting notes vanish. For Workspace accounts, Google says the current auto-assignment behavior continues until October 5, 2026.

Google Classroom calendars

Classroom calendars are secondary calendars owned by the teacher who created the class. After the lifecycle policy takes effect for that account type, deleting that teacher's account can also delete the Classroom calendar unless ownership is transferred first.

Service account-created calendars

If your app creates calendars using a service account or a dedicated "bot" user, those calendars are owned by that account. Once lifecycle enforcement applies, disabling or deleting that owner account can mean losing every calendar it created unless you transfer ownership first.

Suspended accounts

Suspending a user (without deleting) preserves their calendars. Only super admins can modify events on suspended accounts. This is the safe path for temporary offboarding.

The new ownership transfer API (June 2026)

Google is launching a Calendar API endpoint in June 2026 that enables programmatic ownership transfers for secondary calendars. This endpoint eliminates the manual Admin console workflow that currently requires 4 steps per transfer. According to the March 2026 blog post, the API will support the following capabilities:

• Transfer secondary calendars within the same organization without requiring confirmation from the receiving user
• Support transferring individual calendars (not just bulk transfers)
• Require the Calendar administrator privilege
• Restrict transfers to users within the same domain

Until the API launches, use the Google Workspace Admin console to transfer calendars manually: Admin console > Apps > Google Workspace > Calendar > Data transfer.

Audit your calendars now

Auditing means identifying every secondary calendar owned by accounts scheduled for deletion or deactivation. A typical Workspace organization has 2-5 secondary calendars per user, so a 100-person team may have 200-500 calendars to review. Start by listing all calendars on each connected account, then cross-reference the owners against your user directory.

The Nylas CLI outputs calendar metadata as JSON, which pipes directly into jq for filtering. The is_primary field distinguishes the account's default calendar from secondary calendars that are subject to the ownership policy. Non-primary calendars are the ones at risk.

# List all calendars for the connected account
nylas calendar list --json | jq '.[] | {id: .id, name: .name, is_primary: .is_primary}'

# Example output
# {
#   "id": "cal_abc123",
#   "name": "Team Standup",
#   "is_primary": false
# }
# {
#   "id": "cal_def456",
#   "name": "Project Phoenix",
#   "is_primary": false
# }

Cross-reference non-primary calendar owners against your user directory. Any calendar owned by a departing user needs an ownership transfer before you delete their account.

For Workspace admins

Until the programmatic API launches in June 2026, Workspace admins must transfer calendar ownership through the Admin console. The manual transfer process handles one source-to-destination pair at a time, so large organizations with hundreds of departing users may need to batch transfers during offboarding cycles.

# Manual transfer path (until June 2026 API):
# Admin console > Apps > Google Workspace > Calendar > Data transfer
# Select source user, destination user, and which calendars to transfer

# After June 2026: use the new Calendar API endpoint
# POST /calendars/{calendarId}/transferOwnership
# (endpoint details TBD when Google publishes documentation)

Developer checklist

Developers who create or manage Google Calendar resources programmatically should complete these 6 steps before the October 5, 2026, Workspace enforcement deadline. Each step addresses a specific failure mode introduced by the new ownership policy. The checklist applies to any integration that calls the Google Calendar API -- whether directly or through an abstraction layer like the Nylas API.

1. Audit calendar creation -- Find every place your app creates secondary calendars. Which account owns them?
2. Use a persistent service account -- Don't create calendars under individual user accounts if those users might leave
3. Build transfer into offboarding -- Before deleting a user account, transfer their secondary calendars to another owner
4. Watch for the June 2026 API -- When the ownership transfer endpoint launches, integrate it into your user lifecycle automation
5. Suspend before deleting -- Suspending preserves calendars. Delete only after you've confirmed all calendars are transferred
6. Handle cross-domain limits -- Ownership can only transfer within the same domain. Multi-domain Workspace setups need extra planning

How this affects multi-provider apps

Applications that connect to more than one calendar provider face compounding complexity from provider-specific policy changes. Google's ownership enforcement is one of at least 3 major calendar API changes in 2026: Microsoft deprecated EWS for Exchange Online (October 2026), and Apple's CalDAV still requires app-specific passwords. Hardcoding provider-specific ownership logic for each provider multiplies maintenance work.

The Nylas CLI abstracts provider differences behind a single command interface. The same nylas calendar events list and nylas calendar events create commands work across Google, Outlook, Exchange, and iCloud accounts. Provider-side ownership rules still apply to the underlying calendar, but application code doesn't need separate handling for each provider.

# Same commands whether the account is Google, Outlook, Exchange, or iCloud

# List events
nylas calendar events list --days 7

# Create an event
nylas calendar events create \
  --title "Team Standup" \
  --start "2026-04-07 09:00" \
  --end "2026-04-07 09:30" \
  --participant alice@company.com \
  --participant bob@company.com

Frequently asked questions

These 4 questions cover the most common concerns about Google's calendar ownership changes, including deletion dates, the new transfer API, shared calendar behavior, and suspended account handling. Each answer reflects the latest information from Google's March 2026 update.

When do orphan Google Calendars get deleted?

April 27, 2026, for personal Google accounts. October 5, 2026, for Google Workspace accounts. An orphan calendar is one where the owner's account has been deleted and no new owner was assigned.

What is the new ownership transfer API?

Google is launching a Calendar API endpoint in June 2026 for programmatic ownership transfers. It requires Calendar administrator privilege and restricts transfers to users within the same organization.

What happens to a shared calendar when the owner is deleted?

For personal Google accounts, the calendar and all its events are permanently deleted starting April 27, 2026. For Google Workspace accounts, that deletion behavior starts October 5, 2026. Until then, Google says orphan Workspace calendars continue through auto-assignment when another user already has sharing-manager access. Transfer ownership before deleting the account to prevent data loss.

Does suspending an account delete calendars?

No. Suspending a Google Workspace user preserves their calendars. Only super admins can modify events on suspended accounts. Suspend first, transfer calendars, then delete.

Next steps

After auditing your calendars and planning for the ownership transfer deadlines, these 6 resources cover related calendar operations and provider migrations. The Google Calendar guide and cross-provider terminal guide are the most directly relevant to the ownership changes described in this page.

• Manage Google Calendar from the CLI -- create events, check availability, manage calendars
• Manage calendar from the terminal -- the cross-provider calendar guide
• EWS to Graph migration guide -- another provider-side deprecation affecting calendar developers
• Manage Outlook calendar from the CLI -- Microsoft 365 calendar management
• Give AI agents email and calendar access via MCP -- connect Claude or Cursor to your calendar
• Full command reference -- every flag and subcommand documented