Use Cronofy Enterprise Connect service accounts to access an entire organization's calendars without per-user OAuth
domain: docs.cronofy.com · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Have a domain administrator authorize your Enterprise Connect application for their Google Workspace, Office 365, or Exchange (EWS) domain.
Request Service Account authorization, which returns a Service Account access_token scoped to that domain rather than an individual user.
Use the Service Account token to list available Resources (rooms, equipment) and to generate Calendar Accounts (individual access_tokens) for specific users/resources in the domain on demand.
Use each generated user/resource access_token against standard Cronofy API endpoints exactly as you would a normally-OAuth'd individual account.
Authenticate token requests with your Cronofy client_id/client_secret in the request body per the standard Cronofy authorization flow.
Known gotchas
Enterprise Connect setup differs meaningfully by backend (Google Workspace admin console flow vs Office 365/Exchange Graph vs EWS) — the admin-side authorization steps are not interchangeable across providers.
A Service Account token itself cannot read calendar data directly; it must first be exchanged for per-user/resource Calendar Account tokens, which is an easy step to miss when porting code from single-user Cronofy OAuth.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?