KMUC / Booking / Architecture
KMUC Booking: Terminbuchung als System
Von Sebastian Lui · 15.7.2026
Kurzfassung
KMUC Booking ist nicht nur ein Kalender-Formular. Das System verbindet öffentliche Buchungsseiten, Admin-Verwaltung, Verfügbarkeiten, Google-Kalender, API und eine native Flutter-App.
Online-Terminbuchung wirkt von außen oft wie ein Formular mit Datum und Uhrzeit. Sobald das System aber für echte Betriebe funktionieren soll, kommen deutlich mehr Aufgaben zusammen: Leistungen, Standorte, Mitarbeitende, Ressourcen, Verfügbarkeiten, Rollen, Kalender, Benachrichtigungen und sichere Änderungen an bestehenden Terminen.
Genau daraus entsteht KMUC Booking. Das Projekt liegt im KMUC-Monorepo und besteht aus einer mandantenfähigen Booking-Plattform sowie einer nativen Flutter-Admin-App.
Links:
Mehr als eine Buchungsseite
Jede Booking-Instanz bringt eine öffentliche Buchungsseite unter /book/:slug, ein einbettbares JavaScript-Widget und eine versionierte API mit. Betriebe können Leistungen, Standorte, Mitarbeitende, Ressourcen und Öffnungszeiten verwalten. Buchungsseiten lassen sich mit eigenen Texten, Farben, Schriften, Formularfeldern sowie Datenschutz- und Impressumsangaben konfigurieren.
Vor einer Buchung prüft der Worker den Slot erneut. Dabei werden Öffnungszeiten, Ausnahmen, Puffer, Ressourcen, Kapazitäten, vorhandene Buchungen und – wenn aktiviert – Google FreeBusy berücksichtigt.
Verwaltung und Rollen
Die responsive Admin-Oberfläche bündelt Buchungen, Leistungen, Personal, Ressourcen, Buchungsseiten, Kalender, API-Keys, Webhooks, Branding und Audit-Logs. Für Benutzerkonten gelten serverseitig geprüfte Rollen: Owner, Admin, Editor und Viewer.
Konten können einem Mitarbeitenden-Profil zugeordnet werden. Dadurch entsteht zusätzlich eine persönliche Ansicht für eigene Termine. Änderungen wie Verschieben, Absagen oder Weitergeben werden gegen Rollen, Zuweisung und aktuelle Verfügbarkeit geprüft.
Google, E-Mail und Kunden-Self-Service
KMUC Booking kann interne Einträge in einen ausgewählten Google-Kalender schreiben und Gmail-Bestätigungen sowie optionale Erinnerungen versenden. Google-Zugangsdaten und Refresh Tokens bleiben dabei im zentralen OAuth-Worker.
Kunden erhalten sichere Verwaltungslinks, über die sie einen Termin innerhalb der konfigurierten Regeln selbst verschieben oder absagen können.
API, Widgets und Webhooks
Die API stellt unter /v1 unter anderem Leistungen, freie Slots und Buchungsaktionen bereit. Publishable Keys sind für begrenzte Browser-Zugriffe mit Scopes und Origin-Beschränkungen gedacht; Secret Keys dienen serverseitigen Integrationen. Schreibzugriffe nutzen Idempotency Keys.
Zusätzlich kann das System signierte Webhooks ausliefern. Eine OpenAPI-3.1-Spezifikation steht unter /openapi.json bereit.
Native Flutter-App
Die Admin-App ist in Flutter gebaut. Nach Google OAuth ermittelt das zentrale Gateway die für das Konto erlaubten Booking-Instanzen. Bei mehreren Betrieben erscheint eine Auswahl.
Unter „Geräte und Sitzungen“ zeigt die App unter anderem Plattform, Modell, Betriebssystem, App-Version sowie erste und letzte Aktivität. Fremde Gerätesitzungen lassen sich widerrufen. Seriennummern, Hardware-IDs und Werbe-IDs werden laut Projektdokumentation nicht erhoben.
Warum ich es als System betrachte
KMUC beginnt laut eigenem Operating Model mit Scope, Datenflüssen, Betrieb und Verantwortlichkeiten. Booking folgt genau diesem Ansatz: Die sichtbare Buchungsseite ist nur ein Teil. Entscheidend ist, dass Verfügbarkeit, Verwaltung, Sicherheit, Integrationen und Betrieb zusammenpassen.
Der aktuelle Stand ist deshalb keine einzelne UI-Demo, sondern eine technische Plattform mit Worker, D1-Datenbank, Admin-Oberfläche, öffentlichem Flow, API und nativer App.