Planned capability
Calendar API

A provider-aware contract for scheduling and calendar state

DewEngine has one isolated Google Calendar create method in development. Broader Google and Microsoft calendar discovery, synchronization, updates, availability, and provider-originated events remain planned.

Illustrative product surface. The workflows below are planned, not a live connector.
01
Capability boundary

One development write does not make a complete calendar API

Google Calendar create is the only implemented provider method. The catalog's wider Google target and the entire Outlook Calendar connector remain unreleased, without production OAuth or real-account conformance.

  • Catalog status and access: Google Calendar — development, official api; Outlook Calendar — planned, official api
  • Authentication: Both provider paths require customer-controlled OAuth applications and account-scoped delegated access. Google's user-by-project grant ownership and whole-grant revocation behavior remain explicit release gates.
  • Resources: calendars, events, attendees, availability
  • Target actions: calendar.list, calendar.event.list, calendar.event.get, calendar.event.create, calendar.event.update, calendar.event.delete, event.list, event.get, event.create, event.update, event.delete
  • Target events: calendar.event.created, calendar.event.updated, calendar.event.deleted
  • Implemented development slice: calendar.event.create, calendar_event.list, calendar_event.get, calendar.event.created
  • Limitations and failures: Only Google calendar.event.create is implemented; Normalized list/get cover only DewEngine-confirmed creates; Provider sync, update/delete, availability, recurrence, and notifications are not implemented
  • Release gates: Google Calendar — Isolated development only: Google OAuth verification, subject-by-project grant ownership, managed KMS, whole-grant upstream revocation/deletion, quota and provider-failure testing, and consented real-account conformance remain open; Outlook Calendar — Microsoft application registration, tenant consent, and subscription renewal
02
Calendar identity

Name the account, calendar, event, and time basis

A scheduling command needs more than a title and two timestamps. The target model keeps the connected account, provider calendar, stable event identifier, attendee set, time zone, and provider metadata available for later reconciliation.

03
Writes

Make event creation idempotent and observable

The development Google path assigns one idempotency key to the logical create and records each provider attempt. A timeout remains uncertain until a matching provider result is found; notification-bearing unknown writes are not repeated blindly.

04
Synchronization

Use provider cursors for the future read path

A complete connector will need a bounded baseline, provider-native incremental state, explicit deletion handling, and controlled full resynchronization. The current DewEngine list endpoint is not that provider synchronization surface.

05
Scheduling semantics

Keep time zones, recurrence, and attendee state provider-aware

Google and Microsoft represent recurring instances, availability, organizer changes, and attendee responses differently. These remain target concerns and must not be inferred from the narrow timed-event create implementation.

06
Release proof

Require real accounts and failure evidence before expansion

Production readiness needs verified OAuth, managed key custody, quota and throttling tests, renewal and resync behavior, real-account conformance, and complete grant deletion evidence for every claimed method.

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

  • Explicit connected-account ownership
  • Stable public resource identifiers
  • Truthful provider outcome state
  • Release status beside every capability
Illustrative shapePlanned · not callable
const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;
No live connector · no provider request
Questions

Before you build.

Can DewEngine synchronize Google or Outlook calendars today?+

No. One Google timed-event create method is in development; provider listing and synchronization and the Outlook connector remain planned.

Does the current list endpoint show every provider event?+

No. It returns only normalized events created and confirmed through DewEngine's development path.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case