Create one timed Google event with explicit development limits

DewEngine implements one feature-flagged development method: calendar.event.create. It can expose normalized records for its own confirmed creates, but it does not list or synchronize the user's Google Calendar.

Development evidence only. One create method is implemented; production release gates remain open.

Talk to us ↗Read technical guides →

Capability boundary

One isolated create method is in development

The implemented slice has unit and local fake-provider evidence. It is not a production connector, a consented real-Google result, provider calendar synchronization, or broad event CRUD.

Catalog status and access: Google Calendar — development, official api
Authentication: The development flow uses a customer-style Google OAuth setup and account-scoped credentials, but production verification, managed KMS, user-by-project grant ownership, whole-grant revocation/deletion, and real-account conformance remain open.
Resources: events
Target actions: calendar.event.create
Target events: calendar.event.created
Implemented development slice: calendar.event.create, calendar_event.list, calendar_event.get, calendar.event.created
Limitations and failures: Feature-flagged development only; List/get return DewEngine-confirmed creates rather than provider calendar contents; No provider sync, update/delete, availability, recurrence, watches, or production proof
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

Input contract

Create a bounded timed event

The development method accepts RFC 3339 start and end values, an optional time zone, attendees, location, description, and an explicit notification mode. Validation rejects malformed or inverted intervals before the provider attempt.

Idempotency

Give one logical command one stable provider identity

The caller supplies an idempotency key. DewEngine derives a deterministic provider event identifier and private command marker so a retry or reconciliation read can recognize the same intended event.

Provider outcome

Reconcile uncertainty before acknowledging creation

A successful insert or a matching provider read can acknowledge the command. A timeout or interruption remains observable, and an unknown write that may notify attendees is not blindly repeated.

Read model

Return only events DewEngine actually confirmed

After acknowledgement, the service stores a tenant-scoped normalized event and emits calendar.event.created. Current list and get operations cover those records only; they are not Google event listing or synchronization.

Release gates

Keep the broader calendar roadmap out of the proof

Calendar discovery, provider reads, incremental sync, updates, deletes, availability, recurrence, all-day events, conference creation, change notifications, quota testing, and real-account verification remain unfinished.

Development proof

Keep the integration boundary consistent.

The create path uses the implemented command lifecycle, provider-attempt record, normalized result, and signed event delivery. It is development evidence, not a production release.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

RequestTypeScript

const command = await dew.calendarEvents.create(
  "acc_google_7f2",
  {
    summary: "Architecture review",
    start: "2026-09-01T09:00:00+07:00",
    end: "2026-09-01T09:30:00+07:00",
    sendUpdates: "none"
  },
  { idempotencyKey: "review-2026-09-01" }
);

202 accepted · provider confirmation pending

Questions

Before you build.

Can this method be used in production?+

No. It is a feature-flagged development slice with local fake-provider evidence and open production gates.

Does list return existing Google Calendar events?+

No. It returns only normalized events created and confirmed through DewEngine.

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 ↗