Calendar

Authority

Service IDs:

Repos: PlatformApplications/TopoloCalendar

Hosts:

Dependencies: topolo-auth, topolo-chat, topolo-nexus, topolo-notify, applications-packages

Depends on Topolo Auth: yes

Contract Source

Type: curated

Source: PlatformApplications/TopoloDocs/src/content/public/applications/calendar.mdx

Source exists: yes

Calendar is a Worker + D1 + per-host Durable Object application. D1 is the system of record for hosts, event types, availability rules, bookings, reserved slot-hold audit rows, and external calendar sync metadata. CalendarHostDO (keyed by host handle) serialises concurrent booking attempts, owns short-lived in-memory slot holds, and caches availability windows. Confirmed bookings are written through to D1 before the DO acknowledges success; when TOPOLO_NOTIFY_URL and TOPOLO_NOTIFY_API_KEY are configured, Calendar emits `calendar.booking.confirmed` through @topolo/notifications after persistence so the host can be notified without rolling back bookings on notification failure. Meeting sessions remain owned by Topolo Chat; `chat_meeting` bookings call Chat's internal Calendar bridge and store the returned guest URL in `meetingProviderRef`, while external providers (Microsoft Teams, Google Meet, Zoom) store host-configured links or instructions until native Nexus provisioning is added. The public root renders the shared Topolo LandingPage from Auth-managed Calendar landing config. Public booking pages (/<handle>/<event-type>) and availability/hold/confirm endpoints are unauthenticated. The admin `/login` route renders the shared first-party Topolo login on the app origin, with embedded email/password sign-in enabled by the UI Kit first-party registry, login config reads through `/api/auth/*`, and one-time `sso_code` completion on `/auth/callback`. Initial `/app` boot retries one Auth cookie refresh after a 401 admin context response and redirects to `/login` after clearing local session state if refresh fails. Signed users without a Calendar host row complete the shared @topolo/onboarding first-run host setup flow before the admin workspace opens. Signed users with a host row enter the shared `TopoloAppShell`; Calendar supplies section metadata and workspace content while the UI Kit owns sidebar, header, account menu, mobile navigation, app-switcher mount, launcher shortcut behavior, dark/light toggle, sidebar collapse, command palette, and BugFix reporter controls. Calendar scopes raw workspace CSS to app-owned containers so shared portal overlays keep package-owned styling. The default weekly Calendar view is backed by `GET /api/admin/bookings`. Calendar exposes `GET /api/widget` with the shared `@topolo/sdk` widget response contract for TopoloOne live workspace. Admin endpoints require bearer tokens validated by @topolo/auth-middleware against srv_topolo_calendar and enforce route-level Calendar service permissions, accepting Auth's service-scoped canonical grant form such as `srv_topolo_calendar.host:read`. The embed SDK (@topolo/calendar-embed) supports iframe, popup, and floating bubble modes with a @topolo/calendar-react wrapper; embed origins are validated against the service manifest allowlist.

API key scopes in Auth catalog: 11

Auth Requirements

No global OpenAPI security scheme is declared.

• api_keys.write
• availability.read
• availability.write
• bookings.read
• bookings.write
• embed.issue
• event_types.read
• event_types.write
• external_sync.write
• host.read
• host.write

Runtime and Deployment

Wrangler surfaces: none detected

Environment variables: none derived

Routes: workers.dev or Pages-only delivery

Observability enabled: no explicit signal found