A complete Google Calendar connection covers least-privilege OAuth, calendar discovery, event and recurrence semantics, sync tokens, expiring watch channels, and explicit 410 recovery.
Map read, free/busy, and write features to the documented Google scopes, configure the consent screen and redirect URI, and complete the verification required for production use. Keep tokens server-side and account-scoped.
Retain calendar and event IDs, organizer, attendees, date or dateTime values, named time zone, recurrence rules, recurringEventId, originalStartTime, conference data, status, and ETag.
Use the initial events.list result to obtain a sync token on its final page. Repeat the same collection query with that token for changes, and wipe and rebuild the affected local collection when Google returns 410 for invalid state.
Each channel belongs to a user and resource, requires an HTTPS callback with a valid certificate, and can expire. Notifications have no changed-event body, so validate the channel token, deduplicate, and trigger incremental retrieval.
The incremental request returns 410 Gone. Clear the affected synchronized collection and perform a fresh full synchronization before storing a new token.
No. The notification indicates the watched resource changed; the application must call the Calendar API to retrieve the authoritative change details.
Not as released connectors. Google Calendar has one feature-flagged development method, calendar.event.create, plus list/get for DewEngine-confirmed creates and the resulting canonical creation event. Provider calendar reads and sync, update/delete, availability, recurrence, watches, and Microsoft Graph Calendar remain planned. The implemented slice has only local fake-provider evidence, not real-account or production conformance.
DewEngine is in development. Real use cases decide what ships first.