A scheduler is an availability and booking policy engine layered over connected calendars; reading events is only one input, not the scheduling product itself.
Query provider free/busy data where possible, merge all selected calendars, then apply working hours, meeting duration, buffers, minimum notice, date horizon, and the organizer's IANA time zone.
Availability becomes stale between page load and confirmation. Re-read the candidate interval, acquire a short booking lock, create the provider event with an idempotency key, and release the lock only after recording the result.
Record which connected account organizes the meeting, attendee response state, provider event ID, calendar ID, time zone, location, and conference data. Invitations and updates must originate from an identity the provider authorizes.
Consume provider changes, detect organizer-side edits, update the booking record idempotently, and notify the product. Recurring meetings, moved instances, declined attendees, and deleted events need explicit states rather than a generic update flag.
No. It supplies busy intervals. The scheduler still owns working hours, buffers, notice, routing, capacity, time zones, conflict checks, and booking policy.
Recheck availability immediately before creation, serialize competing reservations for the same owner and slot, and make the provider create command idempotent.
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.