Hallo @thommyb,
danke für den Semantik-Hinweis „split and update" - das war die Lösung. Ich bin noch neu bei ChurchTools und brauche noch ein paar Aha-Effekte, um eure Philosophie im Modell ganz zu verstehen.
Die Selbstkritik zur noch nicht vollständigen Doku nehme ich als sehr positiv und ehrlich wahr. Gleichzeitig seid ihr, was die Automatisierungsmöglichkeiten angeht, sehr vorbildlich und weit und habt die richtigen Weichen gestellt. Dass da immer wieder ein paar Swagger-Einträge fehlen (und immer wieder fehlen werden), ist ein Zeichen für Weiterentwicklung, nicht für Stillstand.
Für alle, die das später über die Suche finden, hier der komplette Weg, da der Endpoint aktuell nicht in der OpenAPI-Spec auftaucht:
Endpoint: POST /api/calendars/{calendarId}/appointments/{appointmentId} - also POST auf den Serien-Termin selbst (die Spec kennt auf diesem Pfad nur GET/PUT/DELETE).
Body: die Felder des herausgelösten Einzeltermins plus die Split-Parameter - analog zum dokumentierten Booking-Split (POST /bookings/{bookingId}):
{
...
"title": "…",
"startDate": "2026-08-19T18:00:00Z",
"endDate": "2026-08-19T19:00:00Z",
"allDay": false,
"description": "…",
"isInternal": false,
"repeatId": 0,
"appointmentId": 108879,
"splitDate": "2026-08-19",
"splitUntilEnd": false
...
}
Verifiziert (bei uns): Der Server erledigt alles atomar in einem Request - Einzeltermin wird angelegt (Response enthält die neue ID), die Exception landet in der Serie, und ein am Datum hängendes Event wird samt allen eventServices (inklusive besetzter Dienste) auf den neuen Einzeltermin umgehängt. Verhalten damit identisch zu „Nur diesen Termin ändern" in der UI. Genau das, was wir gebraucht haben.
Eine kleine Anmerkung noch: Ein GET auf die Serie unmittelbar nach dem POST kann die neue Exception noch nicht enthalten (kurzer Verzug).
Danke und viele Grüße
Darijo
