@thommyb Cooler Tipp, sehr hilfreich! Vielen Dank!

@BiKi Danke für das Angebot! Ja, das mit der Zeit kenne ich 😊

Mit .NET habe ich mich ehrlich gesagt noch nie auseinandergesetzt (bin eher für plattformübergreifende Lösungen). Da müsste ich mich erst einmal einarbeiten. Gedanklich bin ich bei einer Lösung als Webservice, die man von jedem Rechner aus triggern kann und welche einem zumindest das ZIP ausspuckt.
Ich denke da nochmal genau drüber nach und würde mich ggf. melden.

Ich antworte mir hier nochmal selbst, da die Follow-Ups für mich tatsächlich in hohem Maße an Attraktivität verlieren, wenn ich das Email-Intervall nicht einstellen kann.

Beispiel onboarding: Ich habe eine Gruppe "Erste Schritte", die Gäste beim Weg in die Gemeinde begleiten soll. Es gibt verschiedene "Meilensteine" (zu Willkommen-abend einladen, KG empfehlen, .... irgendwann über Mitgliedschaft sprechen).

Ich nutze die FUs vor allem als Erinnerung, diverse Gespräche zu führen bzw. Termine auszumachen. Dafür ist das mega gut! Aber wie oben geschrieben, brauche ich diese Erinnerung keinesfalls täglich, schon gar nicht 14 Tage vorher.

Stört das sonst niemand? Oder nutzt ihr die Follow-Ups ganz anders oder gar nicht?

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