REST-API: Serien-Termin individualisieren löscht verknüpftes Event – kein Äquivalent zu „Nur diesen Termin ändern“

Darijo

Hallo zusammen,

wir pflegen Termine über die REST-API und stoßen beim Individualisieren einer Serien-Instanz auf eine Lücke.

In der UI: „Nur diesen Termin ändern“ legt eine Exception in der Serie an und erstellt einen Ersatz-Einzeltermin. Das am Datum hängende Event wird mitgenommen: event.appointmentId zeigt danach auf den Einzeltermin, die Dienstzuordnungen bleiben erhalten.

Über die REST-API: Dasselbe Muster (PUT auf die Serie mit ergänztem exceptions[] + POST für den Einzeltermin) löscht das Event am Ausnahme-Datum samt Dienstzuordnungen. changeimpact kündigt es an ({"domainType": "event", "type": "deletion"}), und wir haben es in einem Sandbox-Kalender verifiziert: Nach dem PUT liefert GET /events/{id} HTTP 404.

Kein Reparaturweg: PUT /events/{eventId} erlaubt nur adminIds, isCanceled, note – appointmentId ist nicht schreibbar. POST /events existiert nicht.

Fragen:

Gibt es einen unterstützten REST-API-Weg, eine Serien-Instanz zu individualisieren, ohne das Event samt Dienstplan zu verlieren?
Falls nein: Wäre ein API-Äquivalent zur UI-Logik denkbar (schreibbares appointmentId, POST /events oder ein „Individualisieren“-Endpoint)?

Danke euch!

thommyb

@Darijo Mit den beschriebenen zwei Aufrufen geht der Event verloren, sobald du die exception einträgst. Danach gibt es dann nichts mehr zu retten. Warum auch? Du hast CT angewiesen, einen Termin samt Event aus der Serie zu löschen.

Um einen einzelnen Termin herauszulösen und zu individualiseren, musst du den POST request für "split and update" aufrufen, und zwar mit dem splitDate auf den Tag gesetzt, den du herauslösen möchtest.

Mir ist bewusst, dass unser API für Termine in diesem Bereich noch etwas dünn dokumentiert ist. Deshalb ist für dich nicht ganz so offensichtlich, was hier zu tun ist.

Darijo

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