## Summary
Integration with Google Calendar API led to duplicated calendars per user instead of creating a single shared calendar. The requirement was one system-owned calendar with **delegated write access** for administrators and **public read access** for all users. Misunderstanding Google Calendar's ownership model caused redundant calendars.
## Root Cause
Google Calendar API requires exactly one owner per calendar (a human Google account). Core mistakes:
- Treating calendars as **ownerless entities** despite Google's strict ownership model
- Assuming organizational-level access control could override personal ownership
- Using user-specific OAuth tokens to create calendars, binding ownership to end-users
- Misinterpreting "public" sharing as delegating ownership rights
## Why This Happens in Real Systems
Architectural mismatches between SaaS APIs and organizational requirements:
- **Ownership assumptions**: Most SaaS tools tie resources to personal accounts
- **Permission granularity**: Public sharing settings often lack fine-grained constraints
- **Token scope leakage**: User-authenticated API calls inherit token owner rights
- **Impersonation gaps**: Domain-wide delegation setups get overlooked
- **Mixed-RW permissions**: SaaS rarely supports custom roles like "admin write, public read"
## Real-World Impact
- Duplicate calendars fragmented events across user accounts
- Admins **overwrote each other's changes** due to data forks
- Training sessions disappeared when specific admin left organization
- Public users saw inconsistent schedules based on sync timing
- Maintenance nightmare cleaning up 200+ orphaned calendars
## Example or Code
### Incorrect Implementation (User-Centric Creation)
```python
def create_user_calendar(user_email):
credentials = get_user_credentials(user_email) # User-owned token
service = build('calendar', 'v3', credentials=credentials)
calendar = {'summary': 'Association Calendar'}
created_calendar = service.calendars().insert(body=calendar).execute()
return created_calendar['id'] # OWNED BY USER, NOT SYSTEM
Correct Implementation (Service Account + Delegation)
def create_system_calendar():
credentials = service_account.Credentials.from_service_account_file(
'creds.json',
scopes=['https://www.googleapis.com/auth/calendar'],
subject='admin@association.org' # Domain super-admin
)
service = build('calendar', 'v3', credentials=credentials)
calendar = {
'summary': 'Association Calendar',
'description': 'System-owned shared calendar'
}
created_calendar = service.calendars().insert(body=calendar).execute()
calendar_id = created_calendar['id']
# Grant write access to admins
for admin_email in ADMIN_LIST:
service.acl().insert(calendarId=calendar_id, body={
'scope': {'type': 'user', 'value': admin_email},
'role': 'writer'
}).execute()
# Set public read access
service.acl().insert(calendarId=calendar_id, body={
'scope': {'type': 'default'},
'role': 'reader'
}).execute()
return calendar_id
How Senior Engineers Fix It
- Use service account impersonation acting as domain super-admin
- Settle calendar ownership at organization level with G Suite domain delegation
- Configure ACL rules to separate write vs read permissions
- Establish single calendar instance registered via service account credentials
- Implement reference propagation – store calendar ID in central config store
- Utilize resource immutability – restrict calendar creation/deletion to deployment pipelines
Why Juniors Miss It
- Token Linguistics: Mistaking OAuth user tokens as “system” credentials
- API Surface Area: Overlooking Calendar ACL API in favor of shallow integrations
- Ownership Blindness: Not auditing
calendar.owner property in API responses
- Setup Tunnel Vision: Skipping domain-wide delegation configuration in GCP
- Permission Inheritance: Assuming inherited viewer roles equate to explicit ACL rules
- Stateless Assumptions: Believing client apps can rebuild calendar state dynamically
