Known differences

Google Calendar

A Google Calendar API v3 simulator serving the published discovery surface and projecting calendars, meetings, rooms, attendance, and events from the shared company graph.

Vendor reference: https://developers.google.com/workspace/calendar/api/v3/reference ↗. Machine-readable: compat/google-calendar.json.

Surfaces

Kind	Path	Notes
REST	`/calendar/v3`	Calendar v3 REST API
REST	`/discovery/v1/apis/calendar/v3/rest`	Calendar v3 discovery document
REST	`/$discovery/rest`	Discovery alias with version=v3
MCP	`/mcp`	Calendar tools over Streamable HTTP; also mounted at /mcp/v1
OAuth	`/token`	Google-style mock OAuth issuer

API versions: Calendar API v3

Supported

All 38 vendor Calendar v3 methods are included in the mounted-route discovery document.
Python SDK calls work in static and dynamic discovery modes.
Event import updates an existing event when its iCalUID already exists.
Attachments require supportsAttachments, and conference creation requires conferenceDataVersion=1.
Calendar and event records are projected from the shared company graph.

Not supported

Calendar has no media-download method; alt=media and alt=proto are rejected.
Workspace Directory and People APIs are served by the Gmail connector, not this Calendar connector.

Known differences and test guidance

Scenario	Difference from Google Calendar	In your tests
Generated calendar data	Calendar, events, attendees, and rooms are deterministic projections from the shared company graph rather than real Google Workspace data.	Assert on the published Calendar resource shape and stable seed, not on a live Google tenant.
Conference creation	Conference entry points and meeting codes are deterministic simulator data; no real meeting is created.	Assert the resource shape and stable links, not callability on Google Meet.
Invitations and reminders	sendUpdates and notificationLevel are validated but no invitation mail or reminder is delivered.	Assert state changes and response shapes, not an external message.
Push channels	Channel state is in-process and is lost on restart; webhook delivery is a direct POST rather than Google's retrying pipeline.	Re-read the event list after restart or a missed notification.

Fault injection

Key	What the client sees
`throttle`	Injected throttling returns a Google-style 429 rateLimitExceeded response with Retry-After.
`fail_next`	The next configured requests fail, then the one-shot fault clears.
`latency_ms`	Adds configured latency to data-plane requests.

Applies to every system

The hosted data plane is read-only: a write is refused with 403 writes_disabled. A SOQL, GraphQL or search POST is a read and is answered.
Faults are injected through POST /_admin/faults on a simulator you run yourself; POST /_admin/faults/reset clears them.
Rate limits do not happen on their own unless a page says so. Use fault injection to exercise a client's backoff.
Distributions come from aggregated metadata sketches of data Eon backs up; no customer records; all Era data is simulated.