API-first-Scheduling: Dein Kalender ist eine Datenbank, keine App

Die meisten Scheduling-Tools behandeln die UI als das Produkt. Der Kalender lebt in der App, und der einzige Weg, an ihn heranzukommen, ist einloggen und klicken. Wenn du etwas machen willst, an das die Designer:innen nicht gedacht haben – die Meetings der nächsten Woche in dein Weekly Review ziehen, aus einer CSV automatisch Sprechstunden anlegen, die Raycast-Extension einer Kolleg:in etwas für dich buchen lassen – hast du keine Chance.

WhenToMeet vertritt die andere Sicht. Der Kalender ist eine Datenbank. Die UI ist eine Ansicht davon. Wenn du eine andere Ansicht willst, schreib sie.

Dafür ist die v1-REST-API da.

Was die API kann

Die v1-Oberfläche unter /api/v1/ ist bewusst klein. Sie deckt die Dinge ab, die Leute tatsächlich automatisieren:

• Events – Scheduling-Polls und Direct Events auflisten, lesen und anlegen. /api/v1/polls
• Bookings – die Termine lesen, die über deine Booking-Pages reingekommen sind. /api/v1/bookings
• Calendar Events – eine vereinheitlichte Sicht über alle verbundenen Kalender, plus deine eigenen Scheduling Events und Bookings. /api/v1/calendar/events
• Conflict-Checks – prüfen, ob ein vorgeschlagener Zeitraum mit etwas kollidiert, das du schon hast
• Profile – dein eigenes Nutzerprofil, Zeitzone, Tier und Einstellungen abrufen

Authentifizierung läuft über einen Bearer-Token. Du erzeugst in deinen Kontoeinstellungen einen sk_…-Key, schickst ihn als Authorization: Bearer sk_…, und bist drin. Jeder Endpoint ist gescoped, damit ein Key nur das sieht, wozu er berechtigt ist.

Es gibt eine OpenAPI-Spec. Die Docs unter docs.whentomeet.io listen jeden Endpoint mit Request- und Response-Form, sodass du einen Code-Generator draufwerfen und in deiner Lieblingssprache einen typisierten Client bekommst.

Warum Pro-gated

API-Zugriff ist ein Pro-Feature. Der ehrliche Grund ist: Eine API ist eine Support-Oberfläche – Keys leaken, Skripte laufen in Schleifen, Rate-Limits werden getroffen – und wir wollen das lieber sorgfältig für die Leute betreuen, die es tatsächlich brauchen, als es dünn über alle Free-Accounts zu verteilen. Die Rate-Limits sind pro Key und bewusst locker für normale Automatisierung. Mit einem wöchentlichen Digest kommst du da nicht hin.

Was sich dadurch ändert

Sobald der Kalender ein echter Endpoint ist, verschwindet die Arbeit, die er früher gemacht hat, in Skripten:

• Die Praktikant:in kopiert nicht mehr die Meetings der nächsten Woche ins Team-Wiki. Das macht ein Cronjob.
• Du leitest keine Booking-Benachrichtigungen mehr an dein CRM weiter. Ein regelmäßiger Poll schreibt sie hinein.
• Der Engineering Lead ist nicht mehr die Scheduling-PM. Ein geteiltes Skript erstellt das wöchentliche Standup mit einem einzigen Befehl.

Nichts davon ist vom Prinzip her neu – Entwickler:innen kleben seit fünfzehn Jahren SaaS-Produkte mit APIs zusammen. Neu ist, dass Scheduling-Tools sich historisch geweigert haben, in diesem Stapel zu landen. Es gab Calendly das Produkt und sonst nichts. Mit einer echten API wird das Produkt einer von vielen Clients.

Wenn du etwas bauen willst

Fang bei docs.whentomeet.io an, erzeuge einen Key, ruf damit GET /api/v1/polls auf – und deine eigenen Scheduling Polls kommen als JSON zurück. Alles Weitere ist Komposition ab dort.

Wenn du die Schlüssel lieber einem Agenten in die Hand drücken willst, statt das Skript selbst zu schreiben – Claude, ChatGPT, Cursor – dann verpackt der MCP-Server unter /api/mcp die gleichen Endpoints in ein Protokoll, das diese Clients schon sprechen. Gleiche Auth, gleiche Rate-Limits. Dazu mehr im nächsten Post.