claritos
deenru

Changelog

Jede Änderung an der API steht hier, mit Version und Datum. Breaking Changes gibt es nur mit neuer Pfad-Version und mindestens zwölf Monaten Vorlauf.

v1.411.0 · 10. November 2026

  • Neu: Berichte der Anwesenheit für eine Auswahl. learning.createAttendanceReport nimmt contactListId (eine Klasse; es zählen ihre Mitglieder, die Teilnehmer sind) oder contactIds (1 bis 500 Teilnehmer), nicht beides; ohne beides wie bisher alle Teilnehmer. PDF und CSV nennen nur die Gewählten. Zwei geltende Berichte dürfen sich nur für dieselbe Person nicht überschneiden (409 period-overlaps), und attendance-finalized gilt nur für die Personen im Bericht. Ist niemand in der Auswahl Teilnehmer: no-participants. Jeder Bericht trägt selection (course, contactList, contacts), contactListId und contactIds.

v1.410.0 · 10. November 2026

  • Neu: Ereignisse learning.attendance.minimumAtRisk (die Mindestanwesenheit eines Kurses ist nur noch mit allen offenen Terminen zu schaffen) und learning.attendance.minimumUnreachable (nicht mehr zu schaffen), je Stufe, Kurs und Kontakt einmal, täglich geprüft, nur für Kurse Ihrer Organisation. Nutzlast nur Kennungen und Zahlen: courseId, sharedCourseId (null), contactId, attendedCount, pastCount, totalCount, requiredCount, minimumPercent; dieselbe Rechnung wie status in learning.getCourseAttendance.

v1.409.0 · 10. November 2026

  • Neu: festgeschriebene Berichte der Anwesenheit. learning.createAttendanceReport (POST /learning/courses/{id}/attendance-reports) friert die Liste eines Kurses für einen Zeitraum ein (from, to, Kalendertage einschliesslich) oder ohne Angabe für den ganzen Kurs und stellt ein PDF mit Prüfcode aus (document); jeder Termin des Zeitraums mit Datum muss vorbei sein (409 sessions-pending), mindestens einer muss darin liegen (no-sessions), und kein geltender Bericht darf einen Tag teilen (409 period-overlaps). learning.listAttendanceReports, learning.getAttendanceReport (mit eingefrorenen sessions und data), learning.getAttendanceReportCsv und learning.cancelAttendanceReport (storniert auch das PDF). Nachträge zu Terminen eines geltenden Berichts lehnen learning.createAttendanceEntry und learning.revokeAttendanceEntry mit 409 attendance-finalized ab. Solange Berichte in einer Umgebung nicht freigeschaltet sind, gibt das Festschreiben feature-not-available mit reason: "attendance-reports-disabled".

v1.408.0 · 10. November 2026

  • Neu: Anwesenheitsliste einer Klasse. learning.getContactListAttendance (GET /contact-lists/{id}/learning-attendance) liefert je heutigem Mitglied der Klasse und Terminlektion aller Kurse, die die Klasse über einen Zugang hat, dieselben Zellen wie learning.getCourseAttendance, dazu besucht und status je Kurs und besucht und Quote über alle Kurse. Jede Sitzung trägt courseId und sharedCourseId (null bei eigenen Kursen); wer in einem Kurs keine Vergabe hat, steht dort mit notParticipant: true und ohne Zellen. learning.getContactListAttendanceCsv liefert dieselbe Liste als CSV. Nur lesen; Nachträge und Berichte gehen je Kurs.

v1.407.0 · 10. November 2026

  • Neu: Profile des Finders verwalten. finder.listProfiles (GET /finder/profiles) liefert alle Behandler-Profile der Organisation in jedem Zustand, mit Filter status und contactId; die öffentliche Sicht bleibt GET /finder/practitioners. finder.deleteProfile (DELETE /finder/profiles/{id}, Recht finder:write) löscht ein archiviertes Profil endgültig samt Anfragen, Prüfrunden, Zertifikaten und Orten und nennt in der Antwort, wie viele es waren; ein Profil in einem anderen Zustand gibt 409 conflict mit reason: "profile-not-archived".
  • Geändert: contacts.merge (POST /contacts/{id}/merge) scheitert nicht mehr an einem archivierten Finder-Profil. Es wird beim Zusammenführen gelöscht, samt Anfragen, Prüfrunden, Zertifikaten und Orten; es bleibt höchstens ein Profil (das nicht archivierte, sonst das des Siegers, sonst das zuletzt geänderte). 409 mit practitioner-profiles-on-multiple kommt nur noch, wenn zwei nicht archivierte Profile zusammenträfen.

v1.406.0 · 9. November 2026

  • Neu: Nachträge zur Anwesenheit. learning.createAttendanceEntry trägt zu einer Terminlektion „vor Ort“ (onSite, zählt als besucht und hakt die Lektion ab) oder „entschuldigt“ (excused) mit Grund nach; höchstens einer je Teilnehmer und Lektion (409 already-recorded). learning.revokeAttendanceEntry nimmt ihn zurück und gibt ihn mit revokedAt zurück. Jede Zelle der Anwesenheitsliste trägt entry. Die Liste, ihre CSV und die Nachträge nehmen als {id} auch die courseId eines freigegebenen Kurses (learning.listSharedCourses), ohne Termin der Anbieterin. Solange Nachträge in einer Umgebung nicht freigeschaltet sind, gibt das Eintragen feature-not-available mit reason: "attendance-entries-disabled".

v1.405.0 · 9. November 2026

  • Neu: Anwesenheitsliste eines Kurses. learning.getCourseAttendance liefert je Teilnehmer und Terminlektion Minuten und Anteil im Termin (gemessen im Live-Raum, nur die Zeit von Beginn bis Ende), measurement (upcoming, measured, absent, notMeasured, cancelled), besucht, Quote und status gegen die Mindestanwesenheit des Abschlusses (onTrack, atRisk, unreachable); learning.getCourseAttendanceCsv dieselbe Liste als CSV. Nur für Kurse Ihrer Organisation; ein freigegebener Kurs gibt noch not-found (kommt mit den Nachträgen).
  • Geändert: Eine Terminlektion gilt erst als besucht, wenn die Person während des Termins im Live-Raum war (nur die Zeit von Beginn bis Ende), nicht schon im offenen Raum davor oder danach. Das betrifft den Lektionsstand in learning.getCourseParticipant sofort, completedCount in learning.getCourseProgress, learning.listCompletions und das Ereignis learning.course.completed, sobald der Abschluss an Terminlektionen hängt. Bereits festgehaltene Lektionen bleiben erledigt; die Regel greift erst beim nächsten Festhalten.

v1.404.0 · 9. November 2026

  • Neu: freigegebene, aber nicht versendete Rechnungen erneut senden. POST /invoices/plan-runs/resend (Rumpf wie release, runId) und POST /invoices/resend-released (ids, 1 bis 200) senden nur Rechnungen, die freigegeben, aber noch nicht versendet sind, mit 200 und { sent, notSent, notSentInvoices, skipped }: notSent wie bei der Freigabe (Grund → Anzahl), notSentInvoices je Rechnung mit id, number und reason (Schlüssel der Versandlogik), skipped für Kennungen ohne solche Rechnung. Nur ORG_ADMIN. Neu an GET /invoices/plan-runs: releasedNotSent je Lauf.
  • Geändert: GET /invoices/plan-runs nennt einen Lauf auch dann, wenn waiting 0 ist und releasedNotSent größer als 0. Automatisch versendete Rechnungen (Abo-Folge, Freigabe nachgereichter und Plan-Rechnungen, Anlauf-Einzug) stehen nach dem Versand auf SENT und melden invoices.invoice.sent, wie ein Versand mit POST /invoices/{id}/send; vorher blieben sie auf ISSUED ohne Ereignis.

v1.403.0 · 9. November 2026

  • Neu: Zahlungsbedingung für viele Kontakte. POST /contacts/billing-defaults/update (Scope contacts:write) setzt die Standard-Zahlungsbedingung an contactIds (1 bis 500) oder an allen Treffern eines filter mit den Feldern von GET /contacts (q, type, tag, responsible, directDebitMandate), genau eines von beiden; paymentTermId: null nimmt die eigene weg. Antwort { matched, unchanged, overwritten, updated } mit 200. POST /contacts/billing-defaults/update/preview (Scope contacts:read) zählt mit demselben Rumpf, ohne zu ändern, { matched, unchanged, overwritten }. Mehr als 5.000 Treffer: 422 precondition-failed, reason: too-many-contacts, mit matched. Eine archivierte Zahlungsbedingung gilt als nicht gefunden (404). Wie PATCH /contacts/{id}/billing-defaults löst der Lauf kein Ereignis aus. Neu an GET /contacts: directDebitMandate=valid|notValid, Kontakte mit oder ohne gültiges SEPA-Lastschriftmandat (Status GUELTIG und nicht nach 36 Monaten ohne Nutzung verfallen).

v1.402.0 · 7. November 2026

  • Geändert: Zugänge, Vergaben, Klassen am Zugang und Zugänge am Artikel gehen jetzt mit einem der Rechte LERN_BIBLIOTHEK (Bibliothek) oder LERN_KURSE (Kurse), wie sie GET /organization/entitlements zeigt; vorher nur mit LERN_BIBLIOTHEK. Betroffen: learning.listAccesses, learning.createAccess, learning.updateAccess, learning.archiveAccess, learning.unarchiveAccess, learning.listGrants, learning.grantAccess, learning.revokeAccess, learning.revokeAccessOfContact, learning.getAccessContactLists, learning.setAccessContactLists, learning.getArticleAccesses, learning.setArticleAccesses. Eine Sammlung im Zugang braucht weiter LERN_BIBLIOTHEK, ein Kurs LERN_KURSE; wer einen Zugang mit Sammlung UND Kurs anlegt, braucht beide, sonst feature-not-available. Ausnahme: learning.setAccessCollections und learning.setAccessCourses mit leerer Liste gehen mit einem der beiden. Die Automations-Aktionen lern-zugang-gewaehren und lern-zugang-entziehen rufen learning.grantAccess und learning.revokeAccessOfContact und folgen damit derselben Regel.

v1.401.0 · 7. November 2026

  • Neu: responsibleContactId (nullable) am Kurs (learning.getCourse, learning.listCourses, learning.updateCourse): ein Kontakt, der als Lehrkraft geführt wird; er beantwortet Fragen und Abgaben im Portal unter „Als Lehrkraft“. Die beiden Felder schliessen sich aus; das Setzen des einen leert das andere. Beide mit einem Wert zugleich gibt invalid_combination, ein Kontakt ohne Lehrkraft-Eintrag not-found an body.responsibleContactId.
  • Neu: feedback.contactId (nullable) an jeder Runde in learning.getSubmission: die Kontakt-Lehrkraft, wenn sie im Portal zurückgemeldet hat; dann ist userId null.

v1.400.0 · 7. November 2026

  • Neu: sharedCourseId (nullable) an jeder Abgabe (learning.listSubmissions, learning.getSubmission) und jedem Abschluss (learning.listCompletions) sowie in den Ereignissen learning.submission.submitted, learning.submission.reviewed und learning.course.completed: die Freigabe, wenn der Kurs einer anderen Organisation gehört (dann direkt zu learning.getSharedCourse), bei eigenen Kursen null.
  • Neu: certificateTemplateId auch an jedem Eintrag von learning.listSharedCourses, nicht nur in learning.getSharedCourse.

v1.399.0 · 7. November 2026

  • Neu: learning.setSharedCourseCertificate setzt Ihre eigene Zertifikat-Vorlage für einen freigegebenen Kurs oder entfernt sie (null); schon Abgeschlossene ohne Zertifikat bekommen es nachträglich (issuedCount). Dazu certificateTemplateId an learning.getSharedCourse. Die Vorlage der anbietenden Organisation gilt bei Ihnen nicht.
  • Geändert: learning.listCourseParticipants, learning.getCourseParticipant, learning.completeParticipantLesson, learning.reopenParticipantLesson, learning.getCourseProgress und learning.resetQuizAttempts nehmen auch die courseId eines freigegebenen Kurses (aus learning.listSharedCourses); Teilnehmer sind Ihre Kontakte mit einer Vergabe über diese Freigabe. learning.getCourse gibt für diese Kennung weiter 404.
  • Geändert: learning.listSubmissions und learning.listCompletions liefern auch Abgaben und Abschlüsse zu freigegebenen Kursen; ihr courseId ist die Kennung des Kurses der anbietenden Organisation, der Filter courseId wirkt auf beide. Dieselbe Kennung steht in learning.submission.* und learning.course.completed.

v1.398.0 · 6. November 2026

  • Neu: learning.releaseSharedCourseItem gibt eine Stelle (course, module, lesson) eines freigegebenen Kurses allen frei, die ihn gerade über einen Zugang haben, je Person ein Eingriff „Jetzt freigeben“ mit Grund (released zählt sie, 0 ist kein Fehler). Dazu waitsForAppointment am Kurs, an jedem Modul und an jeder Lektion in learning.getSharedCourse.
  • Geändert: In freigegebenen Kursen erscheint eine Bedingung „nach Termin“ der anbietenden Organisation bei Ihnen als manual (nie afterAppointment). Erkennbar ist sie an waitsForAppointment in learning.getSharedCourse; freigeben mit learning.releaseSharedCourseItem oder learning.createIntervention.
  • Geändert: learning.createIntervention nimmt jetzt auch Kurs, Modul und Lektion eines freigegebenen Kurses an, wenn der Zugang der Vergabe die Freigabe trägt.

v1.397.0 · 6. November 2026

  • Neu: Kurse, die andere Organisationen Ihrer Organisation freigegeben haben. learning.listSharedCourses (mit providerName, createdAt, endedAt, active; beendete Freigaben, solange bei Ihnen Zugänge laufen), learning.getSharedCourse (Kopf und Gliederung nur lesend, in der Form eigener Kurse) und learning.setAccessSharedCourses. sharedCourseIds an jedem Zugang und an learning.createAccess. Eine beendete Freigabe lässt sich nicht neu hinzufügen (422 shared-course-ended), eine unbekannte steht als Fehler an body.sharedCourseIds.

v1.396.0 · 6. November 2026

  • Neu: Kurse an andere Organisationen freigeben, Seite der Anbieterin. learning.listCourseShareConnections (aktive Verbindungen zur Kursfreigabe), learning.listCourseShares (Freigaben eines Kurses mit participantCount, der Zahl der Teilnehmer mit laufendem Zugang bei der anderen Organisation, ohne Namen), learning.shareCourse (201, created) und learning.endCourseShare (laufende Zugänge dort laufen bis zu ihrem Ende weiter; schon beendet: 409 already-ended). Alle nur Administration. Fehler: 404 connection-unknown, 422 connection-not-active, connection-revoked, connection-wrong-purpose, course-not-published.
  • Geändert: learning.archiveCourse beendet die Freigaben des Kurses an andere Organisationen; laufende Zugänge dort laufen bis zu ihrem Ende weiter. Zurückholen (learning.unarchiveCourse) öffnet sie nicht wieder.

v1.395.0 · 6. November 2026

  • Neu an jeder Sammlung (learning.listCollections, learning.createCollection, learning.updateCollection und alle Antworten mit einer Sammlung): recommendation („Passend dazu“, dieselbe Form wie am Kurs: eine andere Sammlung, ein Kurs oder ein eigener Link), schreibbar beim Anlegen und Ändern; null entfernt die Empfehlung, fehlt das Feld, bleibt sie. Eine Sammlung kann sich nicht selbst empfehlen (422 an recommendation.collectionId).

v1.394.0 · 6. November 2026

  • Neu an jedem Kurs (learning.*Course*): withoutLearningControl („Ohne Lernkontrolle“: keine Fragen an die Lehrkraft und keine Abgabe-Lektionen; Quiz und Termin-Lektionen bleiben; Vorgabe false), schreibbar an learning.createCourse und learning.updateCourse. Einschalten, solange der Kurs Abgabe-Lektionen hat (Entwürfe eingeschlossen): 422 precondition-failed mit assignments-present, lessonIds (höchstens 100) und assignmentCount.
  • Geändert: In einem Kurs mit withoutLearningControl lehnt learning.createLesson mit type: "assignment" ab (422 precondition-failed, without-learning-control), und der Kurs-Import legt Abgabe-Lektionen der Quelle nicht an bzw. stellt keine auf Abgabe um; sie stehen unter kept mit reason: "without-learning-control". Clients sollen unbekannte Gründe in kept allgemein behandeln.

v1.393.0 · 6. November 2026

  • Neu an learning.getAppointmentMaterial und learning.updateAppointmentMaterial: recordingCollectionId (wirksame Sammlung der Aufzeichnung) und die Übersteuerung recordingCollectionOverride ({ collectionId } oder null = wie die Terminart; „keine Sammlung“ gibt es am Termin nicht, unbekannt: 422 an body.recordingCollectionOverride.collectionId mit not-found). Wechselt die wirksame Sammlung ohne recordingFolderOverride, gilt am Termin wieder der Ordner der Terminart.
  • Neu: learning.addAppointmentRecordings (POST /appointments/{id}/learning-material/recordings) legt fertige Video-Aufzeichnungen des Termins ohne Lerninhalt nachträglich als Entwurf in Sammlung, Ordner und Frist des Termins; Antwort 200 mit created und recordings. 422 recording-consent-incomplete (behebbar mit confirmIncompleteConsent: true) und no-target-collection. Dazu an learning.getAppointmentMaterial die Liste recordings (nur, was der Zugang sehen darf).
  • Geändert: visibleDaysAfterRelease ist jetzt an learning.createContent und learning.updateContent schreibbar (1 bis 3650 oder null) und gilt für jeden Inhalt, nicht nur für Aufzeichnungen; bisher nur lesend an Aufzeichnungen. Ungültig: 422 an body.visibleDaysAfterRelease.

v1.392.0 · 6. November 2026

  • Neu an den Unterzeichner-Plätzen einer PDF-Vorlage (templates.getPdf, templates.updatePdf, signerSlots): contactId, ein vorgeschlagener Kontakt mit E-Mail-Adresse, der über den Link der E-Signatur unterschreibt (etwa eine Lehrkraft, die kein Mitglied ist). Ein Platz trägt userId oder contactId, nie beides. Fehlt der Kontakt oder hat er keine E-Mail-Adresse: 422 an body.signerSlots mit invalid_reference.
  • Neu an ausgestellten Dokumenten (letters.getIssued und die übrigen Antworten mit dem Dokument, signature.slots): suggestedContactId, der Kontakt, den die Vorlage für den Platz vorschlägt (null, wenn sie ein Mitglied oder niemanden vorschlägt).

v1.391.0 · 6. November 2026

  • Geändertes Verhalten: Gehört eine Aufgabe zu einer Wiedervorlage aus der Anrufliste (die Pipeline legt sie an), folgt die Karte ihr: PATCH /tasks/{id} mit neuer dueDate verschiebt die Wiedervorlage der Karte; status DONE, DELETE /tasks/{id} oder dueDate: null nehmen sie zurück (eine geparkte Karte behält sie); wieder geöffnet kommt sie mit der Fälligkeit der Aufgabe zurück. Gilt auch für POST /tasks/{id}/status. Andere Felder ändern an der Karte nichts.

v1.390.0 · 6. November 2026

  • Geändert: Für einen Metabolic-Balance-Fall zählt die jüngste Einreichung des Bogens, die noch keinem früheren Fall dieser Akte gedient hat, auch wenn sie vor dem Start kam; bisher nur eine nach dem Start. form.responseId/form.submittedAt an clients.listMetabolicBalanceCases und startMetabolicBalanceCase sowie die Übergabe (…/handover, …/handover/send) folgen dieser Regel; submittedAt kann vor startedAt liegen. Das gilt auch für bereits laufende Fälle.
  • Geändert: In die Übergabe an Metabolic Balance (…/handover, bloodValues, und …/handover/send) gehen nur Werte aus freigegebenen Berichten, ausgelesen oder von Hand; bisher genügte ein gelesener Bericht, auch im Entwurf. Abgelehnte Berichte zählen nirgends. Im Fall (report) zählen Berichte von Hand ab eingereicht; ist schon alles gelesen, aber noch nicht alles freigegeben, sagt der Schritt report das.

v1.389.0 · 5. November 2026

  • Neu an learning.getAppointmentTypeMaterial und learning.setAppointmentTypeMaterial: recordingFolderId (Ordner der Ziel-Sammlung für die Aufzeichnung, null = oberste Ebene; nicht in der Sammlung: 422) und recordingVisibleDays (sichtbar für N Tage nach der Freigabe, 1 bis 3650, null = unbefristet). Wechselt recordingCollectionId ohne neuen Ordner, wird der Ordner null.
  • Neu an learning.getAppointmentMaterial und learning.updateAppointmentMaterial: wirksam recordingFolderId und recordingVisibleDays, dazu die Übersteuerungen recordingFolderOverride ({ folderId } oder null = wie die Terminart) und recordingVisibleDaysOverride ({ days } oder null). Ein Ordner, der nicht mehr in der Sammlung liegt, wirkt als oberste Ebene.
  • Neu am Inhalt: visibleDaysAfterRelease (nur lesend, nur an Aufzeichnungen, sonst null). Geändertes Verhalten in der Kontakt-Sicht: Eine Aufzeichnung mit Frist erscheint nach so vielen Tagen ab der Freigabe des Kontakts nicht mehr (Suche mit contactId, Medien); die Freigabe bleibt in learning.listReleases stehen, in der Bibliothek der Organisation bleibt der Inhalt.

v1.388.0 · 5. November 2026

  • Geändertes Verhalten: Das Material nach der Stunde (Lauf zum Ende des Termins und learning.releaseAppointmentMaterial) geht je Inhalt an alle mit laufendem Zugang zu seiner Sammlung, ob am Termin eingetragen oder nicht; bei attendeesOnly an die gemessen Anwesenden mit Zugang. Bisher ging es an die Eingetragenen, und wer keine Rückmeldung gegeben hatte, fiel heraus. recipientCount zählt verschiedene Kontakte.
  • Geändertes Verhalten: Die Freigabe des Materials veröffentlicht unveröffentlichte Inhalte (Entwürfe nicht). Bei attendeesOnly bleiben sie unveröffentlicht und sind in der Kontakt-Sicht nur für die Empfänger sichtbar; ein solcher Inhalt erscheint bei Abwesenden nicht, auch nicht nach dem Zeitplan der Sammlung.

v1.387.0 · 5. November 2026

  • Lehrkräfte halten Termine: resourceId an appointments.create (und an Terminreihen) nimmt jetzt auch eine Lehrkraft (teacher an der Ressource), für jede Terminart und zu jeder Zeit, ohne Besetzung und ohne Arbeitszeit; geprüft wird nur, ob sie dann schon einen Termin hat (sonst 409 conflict mit slot-taken). appointments.reschedule behält die Lehrkraft eines Termins auch ohne resourceId. Online-Termine einer Lehrkraft bekommen den Live-Raum. Bisher antwortete eine solche resourceId mit dem Fehler, dass die Ressource die Terminart nicht hält.

v1.386.0 · 5. November 2026

  • Lehrkräfte (Kontakt als Gastgeber von Unterricht, ohne freie Zeiten): GET, PUT und DELETE /appointment-teachers/{contactId} (appointments.getTeacher, appointments.setTeacher, appointments.removeTeacher). getTeacher liefert isTeacher, resourceId, removable, upcomingCount und die nächsten höchstens 20 Termine (upcoming mit participantCount, ohne Namen); ein Kontakt, der keine Lehrkraft ist, antwortet mit isTeacher: false. setTeacher ist wiederholbar und antwortet mit 200; removeTeacher antwortet mit 204, bei künftigen Terminen 409 conflict mit reason upcoming-appointments und extra.count. Ein fehlender oder fremder Kontakt gibt 404, eine Firma validation-failed an params.contactId mit code not-a-person. An jeder Ressource neu teacher (appointments.listResources, appointments.getResource).

v1.385.0 · 5. November 2026

  • Neu: POST /clients/{id}/metabolic-balance-client/plans/{planId}/copy-pdf (clients.copyMetabolicBalancePlanPdf, ohne Rumpf, 200) übernimmt das PDF eines Plans des verknüpften Klienten bei Metabolic Balance als geschützte Kopie in die Akte, nur auf diesen ausdrücklichen Aufruf je Plan. Antwort { planId, documentId, copiedAt, created }; liegt das PDF schon in der Akte (eigene Kopie oder PDF eines Falls), kommt dieselbe Kennung mit created: false, und nichts wird neu geholt. Gründe: 404, wenn der Plan nicht zum verknüpften Klienten gehört; 422 metabolic-balance-client-not-linked und metabolic-balance-plan-without-pdf (mit extra.planState); 409 metabolic-balance-pdf-failed (mit extra.error) und metabolic-balance-copy-in-progress (ein liegengebliebener Vorgang verfällt nach fünf Minuten).
  • An clients.listMetabolicBalanceClientPlans neu je Plan documentId: das PDF des Plans in der Akte (PDF eines Falls oder übernommene Kopie), sonst null; die Datei über documents.downloadUrl.

v1.383.0 · 5. November 2026

  • Neu: der Bestand bei Metabolic Balance an der Akte. GET /clients/{id}/metabolic-balance-client (clients.getMetabolicBalanceClient) liest, mit welchem Klienten bei MBG die Akte verknüpft ist (nicht verknüpft: 200 mit linked: false). GET …/metabolic-balance-client/candidates (clients.searchMetabolicBalanceClients, search 2 bis 100 Zeichen) sucht im ganzen Konto bei MBG: höchstens 10 Kandidaten, anonymisierte nie, eingeordnet mit match. PUT …/metabolic-balance-client (clients.linkMetabolicBalanceClient, { patientId }, 200) verknüpft nur auf diesen ausdrücklichen Aufruf; claritos liest den Klienten vorher bei MBG: 422 validation-failed an body.patientId, 409 metabolic-balance-client-linked-elsewhere mit extra.clientId. DELETE …/metabolic-balance-client (clients.unlinkMetabolicBalanceClient, 204) löst nur die Verknüpfung bei claritos. GET …/metabolic-balance-client/plans (clients.listMetabolicBalanceClientPlans) und …/blood-tests (clients.listMetabolicBalanceBloodTests, neueste zuerst, höchstens 20) lesen bei jedem Aufruf bei MBG, gespeichert wird nichts; ohne Verknüpfung { data: [] }.
  • Ist die Akte verknüpft, nimmt …/handover/send diesen Klienten und fragt nicht nach Dubletten; wählt oder legt die Coach beim Senden einen Klienten an, wird eine freie Akte damit verknüpft.

v1.381.0 · 5. November 2026

  • Neu: POST /clients/{id}/metabolic-balance-cases/{caseId}/handover/release-plan (clients.releaseMetabolicBalancePlan, { phase, allowedTreatMeals, allowedOils }, 200) gibt den Plan bei MBG frei und an die Klientin weiter; claritos schickt ihr eine Mail ohne Gesundheitsangaben und zeigt den Plan in ihrem Kundenportal. Ob MBG sie selbst benachrichtigt, ist offen; claritos nimmt eine Freigabe nicht zurück; nie zweimal, ein erneuter Aufruf nach einem Teilfehler setzt fort. Gründe: 422 metabolic-balance-not-generated (mit extra.planState), 409 metabolic-balance-already-released, dazu die bekannten.
  • An mbg der Übergabe neu: releaseDefaults (die Werte des Plans bei MBG als Vorbelegung) und releasedAt.

v1.380.0 · 5. November 2026

  • Neu: der Chat der Prüfung mit dem Backoffice von Metabolic Balance. GET /clients/{id}/metabolic-balance-cases/{caseId}/handover/chat (clients.listMetabolicBalanceChatMessages) liest die letzten 100 Nachrichten, älteste zuerst, bei jedem Aufruf bei MBG (claritos speichert keine Nachrichten; Lesen markiert nichts als gelesen; ohne Chat eine leere Liste). POST …/handover/chat (clients.postMetabolicBalanceChatMessage, { text }, 200) sendet eine Nachricht; 409 metabolic-balance-no-chat ohne Chat. Den Schutz gegen doppeltes Senden gibt der Idempotency-Key.
  • An mbg der Übergabe neu: chatAvailable und chatUnreadSince.

v1.379.0 · 5. November 2026

  • An mbg der Übergabe neu: planDocumentId (das Plan-PDF in der Akte, kopiert in die geschützte Ablage, sobald der Plan bei MBG erzeugt ist; erzeugt MBG ihn neu, ersetzt claritos die Datei unter derselben Kennung, und scheitert das, bleibt die bisherige) und planPdfError (no-pdf, fetch-failed, not-a-pdf, too-large; nach fünf Fehlversuchen kein weiterer). Die Datei kommt über documents.downloadUrl mit dieser Kennung, nur für Schlüssel mit Klientendaten-Freigabe; die Links von MBG gibt claritos nie heraus.

v1.378.0 · 5. November 2026

  • Neu: POST /clients/{id}/metabolic-balance-cases/{caseId}/handover/generate-plan (clients.generateMetabolicBalancePlan) erzeugt den Plan bei Metabolic Balance. Jeder Aufruf, der erzeugt, kostet einen Plan auf dem Konto der Organisation bei MBG; der Rumpf verlangt confirmCost: true, ein doppelter Aufruf erzeugt nie zweimal. Antwort 200 mit der Übergabe. Gründe: 422 metabolic-balance-not-sent, metabolic-balance-not-ready (mit extra.checkErrors); 409 metabolic-balance-already-generated (mit extra.planState), dazu die bekannten.
  • An mbg der Übergabe neu: generationRequestedAt, verificationReason (eigene Schlüssel), blockReason (Text von MBG, höchstens 500 Zeichen) und lastCheckedAt. claritos fragt Pläne ab, die etwas erwarten (Erzeugung, Prüfung): kurz nach dem Erzeugen und alle fünf Minuten.

v1.377.0 · 5. November 2026

  • Neu: POST /clients/{id}/metabolic-balance-cases/{caseId}/handover/laboratory (clients.createMetabolicBalanceLaboratory) legt ein neues Labor im Labormanagement des Coaches bei Metabolic Balance an und wählt es im Fall. Das Eingabeprofil kommt aus dem Bericht: Einheit und Normbereich für das Geschlecht der Klientin, sonst die Vorbelegung von MBG; keine Personendaten. Antwort 200 mit der Übergabe. 409 metabolic-balance-laboratory-exists mit extra.laboratoryId, wenn es ein Labor gleichen Namens schon gibt (wählen mit PATCH …/handover); scheitert nur das Profil, setzt ein erneuter Aufruf fort. Weitere Gründe: 422 metabolic-balance-not-connected, validation-failed (etwa body.countryId); 409 case-closed, metabolic-balance-rejected, metabolic-balance-unavailable.
  • An der Übergabe (GET, PATCH, send) neu options.countries (Länder von MBG) und options.reportLaboratory (name, matchedLaboratoryId, suggestedCountryId).

v1.376.0 · 5. November 2026

  • Geändert: affiliates.createCoupon (POST /affiliate-coupons), affiliates.updateCoupon (PATCH /affiliate-coupons/{id}) und affiliates.updateClimateContribution (PUT /affiliate-climate-contribution) verlangen das Recht AFFILIATE_VERWALTUNG (siehe GET /organization/entitlements). Ohne es antworten sie 403 feature-not-available mit reason affiliate-license, wie affiliates.activity. Ausnahme: updateCoupon mit active: false (Abschalten) geht weiter ohne das Recht, ebenso affiliates.deleteCoupon und affiliates.disableTracking. Dieselbe Regel gilt in der Oberfläche.

v1.375.0 · 5. November 2026

  • Neu: POST /clients/{id}/metabolic-balance-cases/{caseId}/handover/send sendet die Übergabe an Metabolic Balance: Klient und Plan anlegen oder die vorhandenen nehmen, alle Abschnitte und den Bluttest übertragen, MBG fragen, ob erzeugt werden kann. Erzeugt wird nichts. Ein erneuter Aufruf setzt fort und legt nichts doppelt an. Vorher sucht claritos den Klienten im Konto bei MBG; ein Treffer wird nie still übernommen: 409 metabolic-balance-duplicate mit bis zu fünf Kandidaten in extra.candidates, dann mit patient ({ mode: "existing", patientId } oder { mode: "new" }) wählen. Danach fragt claritos nach einem offenen Entwurf bei MBG, der nicht aus diesem Fall stammt (MBG erlaubt einen je Klient): 409 metabolic-balance-draft-exists mit extra.draft (planId, createdAt, state), auch hier vor jedem Schreiben; mit overwriteDraftPlanId übernehmen und überschreiben, beim zweiten Aufruf zusammen mit patient. Weitere Gründe: 422 handover-incomplete (mit extra.missing), collection-too-old, metabolic-balance-not-connected; 409 case-closed, metabolic-balance-rejected (mit extra.providerMessage), metabolic-balance-unavailable.
  • An der Übergabe (GET, PATCH, send) neu mbg: Klient und Plan bei MBG (patientId, planId), planState in eigenen Schlüsseln, canGenerate, checkErrors wie von MBG geliefert, sentAt, outOfGlobalRange; null, bis gesendet wurde.

v1.374.0 · 5. November 2026

  • Geändert: couplings.prospectsRequired an pipelines.update (PATCH /pipelines/{id}) gilt als erfüllt, sobald der Interessent irgendeine Karte in einer Pipeline der Organisation hat, gleich in welchem Zustand (offen, geparkt, abgeschlossen), nicht mehr nur eine Karte in dieser Pipeline. Erst ein Interessent ganz ohne Karte bekommt die Bitte um Zuordnung oder, mit prospectsAutomatic, eine Karte. Das verhindert doppelte Karten für dieselbe Person.
  • Geändert: Der Nachzug der Pflicht (pipelines.getBackfill und pipelines.startBackfill, GET/POST /pipelines/{id}/backfill) nimmt nur noch Interessenten ohne jede Karte in der Organisation; wer schon in einer anderen Pipeline eine Karte hat, auch eine abgeschlossene, kommt nicht mehr hinzu. candidates zählt entsprechend.

v1.373.0 · 5. November 2026

  • Impressum und Datenschutzerklärung: Ergänzungen zur laufend erzeugten Vorlage. GET /organization/legal-texts nennt an jedem Eintrag mode, supplements und sections (bei anderen Arten null) sowie dpoNotAppointed. Neu PUT /organization/legal-texts/{kind}/supplements. DELETE /organization/legal-texts/{kind} verwirft den eigenen Text; Ergänzungen bleiben, ohne Ergänzungen wie bisher. PATCH /organization/legal-texts nimmt dpoNotAppointed. isCustomized ist weiter nur bei eigenem Text wahr (gleich mode own), Ergänzungen allein ändern es nicht; version steigt auch, wenn sich die Ergänzungen ändern.

v1.371.0 · 5. November 2026

  • Neu: die Übergabe eines Falls an Metabolic Balance lesen und vorbereiten. GET /clients/{id}/metabolic-balance-cases/{caseId}/handover liefert die Abschnitte wie im MB-Portal mit Ampel (ready, unclear, optional, attention), die Einstellungen des Plans, die Auswahlen (options: Labore, Sprachen, Listen von MBG), die Blutwerte mit Einheit des Berichts in der Schreibweise von MBG (keine Umrechnung) und zwei Stufen (outside-norm, outside-global), die freien Angaben des Bogens zum Zuordnen und blockers. PATCH desselben Pfads ändert Einstellungen und Zuordnungen teilweise. Eigene Schlüssel: dietGoal none/lose/regulation/gain, healthTrigger in camelCase; Kennungen bei Metabolic Balance kommen aus options. Gesendet wird noch nichts.

v1.370.0 · 5. November 2026

  • Neu: POST /clients/{id}/metabolic-balance-cases/{caseId}/request-report fordert den Laborbericht bei der Klientin nach. Der Aufruf schreibt sie sofort über den Kanal des Falls an, mit dem Upload-Link; ist ein Bericht gelesen, nennt die Nachricht die fehlenden Pflichtwerte. Nimmt die bisherige Datei-Anfrage keine Uploads mehr an, entsteht eine neue (dann in fileRequest). Jeder Aufruf schreibt erneut an. Antwort 200 mit dem Fall; 409 case-closed oder send-failed, 422 case-not-sent, contact-without-email, sender-missing, metabolic-balance-not-connected.
  • Am Fall-Objekt (GET und POST /clients/{id}/metabolic-balance-cases) neu report: Phase (none, reading, redaction, failed, read), requiredCount, receivedCount, missing, optionalRequested, optionalReceived als { key, name } (key wie markerKey in biomarkers.listProfileItems) und lastRequestedAt. Berichte, die im Labor-Reiter mit der Laboranforderung des Falls verknüpft werden, zählen mit.

v1.369.0 · 5. November 2026

  • Neu: Fälle von Metabolic Balance an der Akte. GET /clients/{id}/metabolic-balance-cases nennt die Fälle mit ihrem Stand (Versand, Anamnesebogen, Laborbericht, Übergabe, Plan). POST /clients/{id}/metabolic-balance-cases startet einen Fall: gibt die Laboranforderung aus dem Profil frei, stellt den Link zum Anamnesebogen aus und legt die Datei-Anfrage für den Laborbericht an (channel email oder portal). Die Nachricht an die Klientin geht im Hintergrund hinaus, sobald die PDFs der Laboranforderung fertig sind; delivery.sentAt steht deshalb erst danach und lässt sich mit dem GET nachlesen. Voraussetzung: das Recht METABOLIC_BALANCE (sonst 403 metabolic-balance-license) und ein verbundener Zugang (sonst 422 metabolic-balance-not-connected); ein offener Fall je Akte (409 case-open).

v1.368.0 · 5. November 2026

  • Neues Recht METABOLIC_BALANCE (Anbindung an das Metabolic-Balance-Portal) in GET /organization/entitlements und in den Lizenz-Endpunkten. Es hat keine Voraussetzung und schaltet die Verbindung zum Portal in den Einstellungen der Organisation frei; den Schlüssel trägt man dort ein, nicht über die API.
  • GET /organization/integrations nennt bei Geschäftsorganisationen die Anbindung metabolicBalance (Einstellungen unter bereich=schnittstellen): ohne das Recht METABOLIC_BALANCE mit state not-enabled, sonst not-connected, faulty (letzte Prüfung fehlgeschlagen) oder connected.

v1.367.0 · 4. November 2026

  • Neu: courseId an learning.searchCourses beschränkt die Suche auf einen Kurs.
  • Die Suche über Kurse findet jetzt auch Seiten der PDF-Dateien einer Lektion (matchIn: "pdfPage"), mit dem neuen Feld lessonMaterialId; bei Seiten des PDF-Mediums der Lektion bleibt es null.

v1.366.0 · 4. November 2026

  • Terminarten lassen sich duplizieren: POST /appointment-types/{id}/duplicate (appointments.duplicateType, Scope appointments:write, dasselbe Recht wie createType) legt eine inaktive Kopie an, mit „(Kopie)“, „(copy)“ bzw. „(копия)“ am Namen in jeder gespeicherten Sprache und neuem slug (…-kopie, …-kopie-2); Antwort 201 mit der Kopie. Übernommen werden die Einrichtung samt Besetzung und Leistungen; Marke, Formular, Leitfaden, Ort, Telefon, Erinnerungsplan und Checkout-Link verweisen auf dieselben Objekte. Termine, Buchungslinks und die Partnerfreigabe gehen nicht mit (partnerRelease NONE). Zeigt die Vorlage auf einen Leitfaden, Checkout-Link oder Erinnerungsplan, den createType nicht annähme, kommt derselbe Fehler wie dort.

v1.365.1 · 4. November 2026

  • Behoben: includeArchived=false an pipelines.list (GET /pipelines) und pipelines.listSlas (GET /pipelines/slas) lieferte bisher auch Archiviertes (jeder nicht leere Wert galt als true). Der Parameter nimmt jetzt true oder false.

v1.365.0 · 4. November 2026

  • Kurse können ihre beiden Ebenen der Gliederung benennen (levelNames: first für Module, second für Untermodule), gesetzt in der Sprache der Anfrage und übersetzt wie die übrigen Kurstexte; null oder ein leerer Text setzt alle Sprachen auf die Vorgabe zurück. Namen tragen keine Nummer: Das Portal nummeriert selbst, und nur dort, wo die Titel keine tragen.

v1.364.0 · 4. November 2026

  • Lernplattform, Kurse: description und instructor.description sind formatierter Text (HTML; Klartext bleibt erlaubt und wird zu Absätzen) und nehmen in learning.createCourse und learning.updateCourse bis 20.000 Zeichen statt 5.000. claritos säubert das HTML beim Speichern. Verhalten: Wer description bisher als Klartext angezeigt hat, sieht jetzt Auszeichnung wie <p>; vor der Anzeige als HTML behandeln. Auch der Kurs-Import (learning.startCourseImport) säubert beide Texte jetzt beim Speichern und macht Klartext zu Absätzen; dort gilt die Grenze von 20.000 nicht. Wird ein Text erst durch das Säubern länger als 20.000 Zeichen, meldet createCourse/updateCourse am Feld too_big.

v1.363.0 · 4. November 2026

  • Lernplattform, Kursordner und Kurse in Sammlungen: neue Endpunkte learning.listCourseFolders, createCourseFolder, updateCourseFolder, moveCourseFolder, deleteCourseFolder (Ordner der Kurse, höchstens zwei Ebenen, ohne Freigaberegel), learning.orderCourseItems (POST /learning/courses/order) und listCollectionCourses, addCollectionCourse, updateCollectionCourse, removeCollectionCourse (Kurs als Kachel in einer Sammlung; gibt keinen Zugang). Am Kurs neu folderId, position und collections, learning.updateCourse nimmt folderId. An Sammlungsordnern neu courseCount, learning.deleteFolder meldet movedCourseCount, learning.orderItems kennt type course. Verhalten: Ordner, Inhalte und Kurs-Kacheln einer Sammlungsebene teilen sich jetzt die Zahlen in position. Ein Import legt keine Kursordner an und verschiebt nichts Einsortiertes.

v1.362.0 · 4. November 2026

  • Lernplattform, Suche über Kurse: neuer Endpunkt learning.searchCourses (GET /learning/courses/search), additiv. Sucht in Kursen, Modulen und Lektionen (Titel, Beschreibungen, Name, Zeile und Text des Dozenten, Texte der Lektionen, Gesprochenes und PDF-Seiten ihrer Medien); flache Zeilen wie bei learning.searchContents, mit type (course, module, lesson), modulePath und lessonType; mit contactId aus der Sicht des Kontakts (locked, unlockReasons), ohne mit draft. learning.searchContents bleibt unverändert und liefert KEINE Kurstreffer; wer beides will, ruft beide Suchen.

v1.361.0 · 4. November 2026

  • Lernplattform, Kurse: instructor hat zwei neue Felder, jobTitle (Zeile unter dem Namen auf der Karte im Portal, je Sprache) und imageAssetId (Foto aus der Medienbibliothek, null = Initialen); in der Antwort immer, in learning.updateCourse optional. Der Importbaum (learning.startCourseImport) bringt weder Foto noch jobTitle mit; ein späterer Import lässt beide stehen. Neues Feld recommendation („Passend dazu“, höchstens ein Eintrag, oneOf nach type: Sammlung, anderer Kurs oder eigener Link mit Titel und Bild), in der Antwort immer (null ohne Eintrag), in learning.updateCourse optional (null entfernt ihn); learning.createCourse setzt es nicht. Wird das Ziel gelöscht, ist der Eintrag null.

v1.360.0 · 4. November 2026

  • Lernplattform, Vorspulen: neues Feld allowSeeking (boolean, Vorgabe true) an der Sammlung (lesen, learning.createCollection, learning.updateCollection) und am Kurs (lesen, learning.updateCourse). Bei false lässt das Portal bei Video und Ton nur Sprünge bis zur weitesten schon gesehenen Stelle zu. Verhalten: Der Fortschritt steigt dann je Meldung höchstens um die seit der letzten Meldung vergangene Zeit (mal 1,25, plus 15 Sekunden); eine einzelne Meldung macht ein Video also nicht mehr „angesehen“. Bei true, also bei allen bestehenden Sammlungen und Kursen, verhält sich der Fortschritt wie bisher; die Grenze greift nur bei false.

v1.359.0 · 3. November 2026

  • Grösse des Rumpfs je Endpunkt: learning.startCourseImport (POST /learning/course-imports) nimmt jetzt bis 4 MB an (4.194.304 Bytes), alle anderen Aufrufe weiter bis 1 MB. Bisher lehnte der Rahmen jeden Rumpf über 1 MB mit 413 ab, auch am Kurs-Import, der 4 MB zusagt; ein Kurs mit rund 250 Lektionen scheiterte daran. Jede Operation mit Rumpf nennt ihre Grenze in der Spec als x-max-body-bytes, die Antwort 413 (payload-too-large) nennt sie als maxBodyBytes. Gezählt wird in Bytes (UTF-8), auch bei einer Anfrage ohne Content-Length.

v1.358.0 · 3. November 2026

  • Lernplattform, Materialien einer Lektion: learning.createLessonMaterial (POST /learning/lessons/{id}/materials, 201) hängt eine Datei aus der Medienbibliothek an (ohne title der des Mediums, höchstens 50, darüber conflict mit too-many-materials), learning.updateLessonMaterial und learning.deleteLessonMaterial (/learning/lesson-materials/{id}), learning.orderLessonMaterials (POST …/materials/order). Ein Material aus dem Import wird nicht geändert (conflict, material-from-import); entfernt kommt es mit dem nächsten Import wieder, von Hand angelegte lässt jeder Import stehen. Neu materials an jeder Antwort mit einer Lektion, immer geliefert ([] ohne Material), je Material mit media wie an der Lektion.

v1.357.0 · 3. November 2026

  • Biomarker, vor der Auslieferung umbenannt: Die Zählfelder an biomarkers.listAxes (und in den Antworten von createAxis, updateAxis, orderAxes) heissen draftEntryCount, lockedEntryCount und ruleCount statt draftEntries, lockedEntries und rules, wie markerCount und ruleCount im Bereich (1.356.0 war nie auf einer Umgebung).

v1.356.0 · 3. November 2026

  • Biomarker, Achsen von Hand: Die Achsen der Biomarker-Profile lassen sich jetzt ohne Import der Profil-Mappe pflegen. Neu biomarkers.listAxes (GET /biomarker-axes, mit Zahl der Einträge in Entwürfen draftEntryCount und in freigegebenen, zurückgezogenen oder übernommenen Profilen lockedEntryCount, Regeln ruleCount, deletable, deleteBlockedBy), biomarkers.createAxis (POST, ohne key der nächste freie wie „A18“; vergeben gibt 409 axis-key-taken, der Schlüssel order ist nicht erlaubt), biomarkers.updateAxis (PATCH /biomarker-axes/{key}, Name und Notiz; der Schlüssel bleibt), biomarkers.orderAxes (PUT /biomarker-axes/order, alle Schlüssel genau einmal, Antwort die geordnete Liste) und biomarkers.deleteAxis (DELETE; Einträge in Entwürfen verlieren die Achse; 409 axis-in-locked-profile, solange ein freigegebenes, zurückgezogenes oder übernommenes Profil sie nennt, axis-in-rule, solange eine Regel mit ihr rechnet). Am Eintrag: biomarkers.listProfileItems (GET /biomarker-profiles/{id}/items, Marker, Geschlecht, axisKey, familyKey, assignment) und biomarkers.setItemAxis (PUT /biomarker-profiles/{id}/items/{itemId}/axis, nur in eigenen Entwürfen, sonst 409 profile-not-draft oder profile-licensed; axisKey: null entfernt die Zuordnung; Antwort der Eintrag wie bei listProfileItems); eine Änderung stellt assignment auf ACHSE_FESTGELEGT.

v1.355.0 · 3. November 2026

  • Lernplattform, Kurse am Zugang: learning.setAccessCourses (PUT /learning/accesses/{id}/courses) setzt die Kurse eines Zugangs, ersetzt die Liste in der übergebenen Reihenfolge und lässt die Sammlungen stehen; ein unbekannter Kurs gibt not-found an body.courseIds, ohne Recht für Kurse feature-not-available. Neu courseIds in den Antworten von Zugang und Vergabe, immer geliefert ([] ohne Kurse), und optional in learning.createAccess (eine leere Liste braucht kein Recht). Entwürfe und archivierte Kurse wie bei den Sammlungen. Ereignisse unverändert.

v1.354.0 · 3. November 2026

  • Lernplattform, Kurs anlegen: learning.createCourse (POST /learning/courses, 201) legt einen leeren Kurs an, als Entwurf mit Freigabe sofort und ohne source; ein späterer Import trifft ihn nicht. Felder title (Pflicht), description, type und selfPacedStart wie bei learning.updateCourse, Antwort wie learning.getCourse mit leerer Gliederung.

v1.353.0 · 3. November 2026

  • Konversationen, Zuständigkeit und Bezug: inbox.listConversations und inbox.getConversation tragen neu assigneeUserId, die zuständige Person (Mitglied der Organisation; nur solange sie Mitglied ist), und relatedTo, worauf sich die Konversation bezieht, als Vereinigung über type. Heute gibt es nur { type: "lesson", courseId, lessonId }: eine Frage, die ein Kunde im Portal zu einer Lektion gestellt hat; zuständig ist dann die Lehrkraft des Kurses (responsibleUserId, 1.352.0). Fällt Kurs oder Lektion, steht dort null. Ohne Zuständigkeit bzw. Bezug sind beide Felder null, also bei allen bisherigen Konversationen. Neuer Filter assigneeUserId an inbox.listConversations, assigneeUserId=none für niemand zugewiesen. Setzen der Zuständigkeit kommt mit einer späteren Fassung.

v1.352.0 · 3. November 2026

  • Lernplattform, Lehrkraft am Kurs: Kurse tragen responsibleUserId, das Mitglied der Organisation, dem Fragen aus dem Portal zu Lektionen dieses Kurses zugehen (assigneeUserId der Konversation); null = niemand. Setzbar per learning.updateCourse; kein Mitglied gibt not-found an body.responsibleUserId. Verlässt die Person die Organisation, bleibt der Wert stehen, gilt aber als niemand. Unabhängig von instructor (dem angezeigten Dozenten).
  • Lizenz, Verhalten (Spec unverändert): Für Lizenzen mit Fassung (model: version) ergibt sich das Recht LIVE_RAUM jetzt aus der Video-Stufe der Organisation (enthalten, gebucht oder als Einzelausnahme am Tenant mit Start); eine eigene Freigabe an der Organisation ist dafür nicht mehr nötig. Fassungen führen LIVE_RAUM nicht mehr in choiceList und nicht als buchbaren Baustein (bookable), das gilt beim Lesen für jede Fassung, auch für schon veröffentlichte; eine Buchung des Moduls wird abgelehnt (conflict, reason rejected). Neu gespeicherte Fassungen enthalten es auch nicht mehr. Zubuchbar sind die Video-Stufen. Lizenzen ohne Fassung (model: existing) bleiben unverändert.

v1.351.0 · 3. November 2026

  • Lizenz, Video-Stufen mit Namen und Fassung: Neben dem Schlüssel (tier) steht der Name in der Sprache der Anfrage (tierName; eigene Stufen mit ihrem Namen, START, PLUS, PRO mit festem Text) an organization.getLicenseChoices (auch in den Antworten von setLicenseChoices und setVideoTier: video.tierName, video.booked[].tierName), organization.getLicense (modules[].tierName, bookable[].tierName, perOrganization[].videoTierName) und der Vorschau des Taktwechsels (modules[].tierName). Die Nummer der Fassung der Stufe steht, wo eine Organisation ihre Stufe sieht: video.tierVersionNumber, perOrganization[].videoTierVersionNumber, und bei bookable[] die Fassung, die eine neue Buchung heute bekäme (tierVersionNumber). Eigene Stufen haben einen Schlüssel aus ihrem ersten Namen, der sich danach nicht ändert; angezeigt wird deshalb der Name.

v1.350.0 · 3. November 2026

  • Konversationen: Neuer Kanal portal (channel an inbox.listConversations und inbox.getConversation, Filter channel=portal, channels.portal in inbox.getConversationCounts). Er umfasst die Nachrichten im Kundenportal im Bereich Kommunikation, je Faden eine Unterhaltung; Akte-Post erscheint nicht. subject ist der Betreff des Fadens, counterpart ist null, die Nachrichten im Verlauf tragen HTML. Wer über channel verzweigt, bekommt damit einen neuen Wert.

v1.349.0 · 3. November 2026

  • Lernplattform, Lückentext und Fragenpool: type einer Quizfrage bekommt den Wert blanks (Lückentext); Clients, die nach der Art verzweigen, brauchen einen Zweig dafür. Neu an der Frage blanks (je Lücke answers, die akzeptierten Antworten; null bei single und multiple, bei blanks ist options leer). Die Lücken stehen im Text als {{1}}, {{2}} …, ab 1 fortlaufend; verglichen wird ohne Gross- und Kleinschreibung, Leerraum zusammengefasst. learning.createQuestion und learning.updateQuestion nehmen type blanks mit blanks (1 bis 20 Lücken, je 1 bis 10 Antworten bis 100 Zeichen); Platzhalter, die nicht zu den Lücken passen, geben invalid an body.blanks, eine Lücke ohne Antwort required an body.blanks[i].answers, zu viele oder zu lange Antworten too-large. PUT /learning/questions/{id}/answers gibt am Lückentext wrong-type an params.id. Am Quiz neu questionsPerAttempt (Fragenpool: so viele Fragen zieht jeder Versuch zufällig, null alle; beim Speichern höchstens so viele, wie das Quiz hat, sonst invalid an body.questionsPerAttempt; werden später Fragen gelöscht, nimmt jeder Versuch alle). Import und getCourseMissing bleiben bei single und multiple.

v1.348.0 · 3. November 2026

  • Lernplattform, Quiz erweitert: Am Quiz einer Lektion (learning.updateQuiz, lesbar an der Lektion) neu maxAttempts (Höchstzahl der Versuche je Person, 1 bis 100, null unbegrenzt; zurückgesetzte zählen nicht), timeLimitMinutes (1 bis 600, null ohne; gerechnet auf dem Server ab „Quiz starten“ im Portal, nach Ablauf und kurzer Toleranz zählt eine Abgabe als nicht bestanden) und showSolution (never Vorgabe wie bisher, afterSubmit, afterPass: wann das Portal die richtigen Antworten zeigt). Ausserhalb der Grenzen invalid an body.maxAttempts bzw. body.timeLimitMinutes. learning.getCourseParticipant trägt je Quiz-Lektion quiz mit attemptCount, lastScore, passed, remainingAttempts (sonst null). Neu POST /learning/courses/{id}/participants/{contactId}/lessons/{lessonId}/quiz-attempts/reset (learning.resetQuizAttempts): Die Versuche bleiben im Verlauf, zählen aber nicht mehr; ein laufender Versuch endet; keine Quiz-Lektion gibt wrong-type an params.lessonId.

v1.347.0 · 3. November 2026

  • Zertifikate und PDF-Vorlagen: Neue Feldart TRIGGER_VALUE in pdfFieldKind (templates.*, letters.getIssued) für einen Wert, den der Ablauf beim Ausstellen mitgibt; binding ist heute nur course.title, der Kurstitel beim Kursabschluss der Lernplattform. Von Hand ausgestellt bleibt ein solches Feld leer. Wer über kind verzweigt, bekommt damit einen neuen Wert. Am Zertifikat neu sourceKind (COURSE_COMPLETION) und sourceId (die id aus learning.listCompletions bzw. completionId aus learning.course.completed), wenn ein Ablauf ohne angemeldete Person ausgestellt hat, sonst beide null. Ein Abschluss ergibt höchstens ein Zertifikat.

v1.346.0 · 3. November 2026

  • Lernplattform, Teilnehmer: GET /learning/courses/{id}/participants (learning.listCourseParticipants, nach Name, Filter active als true/false, mit lessonCount, completedLessonCount, progressPercent, lastActivityAt, completedAt, grantId der geltenden Vergabe) und GET /learning/courses/{id}/participants/{contactId} (learning.getCourseParticipant: je Lektion status completed/open/locked, completedAt, completedManually, unlocksAt, unlockReasons, dazu interventions). Von Hand abhaken: POST …/participants/{contactId}/lessons/{lessonId}/complete mit reason (learning.completeParticipantLesson, schon erledigt bleibt unverändert) und …/reopen (learning.reopenParticipantLesson, nur von Hand Abgehaktes, sonst 422 precondition-failed mit reason not-manual). Eingriffe in den persönlichen Zeitplan (auch für die Bibliothek): POST /learning/grants/{id}/interventions (learning.createIntervention, 201, Vereinigung über type: pause mit startDate/endDate, move mit targetType/targetId/date, releaseNow mit targetType/targetId, extendEnd mit endDate; reason Pflicht; eine Stelle, die nicht zur Vergabe gehört, gibt not-found an body.targetId), GET /learning/grants/{id}/interventions (learning.listInterventions) und POST /learning/interventions/{id}/revoke (learning.revokeIntervention, wiederholbar). GET /learning/courses/{id}/progress (learning.getCourseProgress): je Lektion startedCount und completedCount, dazu participantCount. unlockReasons tragen bei afterItem jetzt targetType.

v1.345.0 · 3. November 2026

  • Lernplattform, Abschluss und Zertifikat: Am Kurs (learning.getCourse, schreibbar über PATCH /learning/courses/{id}) neu completionRule mit requiredLessons (all alle Lektionen ohne Entwürfe, selected nur requiredLessonIds) und minAttendancePercent (1 bis 100 % der Terminlektionen, aufgerundet; bei all zählen Termine dann über den Anteil; null keine), immer gesetzt, im PATCH ersetzt sie die ganze Regel; dazu certificateTemplateId (PDF-Vorlage, templates.getPdf). Eine Lektion ausserhalb des Kurses gibt not-found an body.completionRule.requiredLessonIds[i], ein Prozentwert ausserhalb invalid, eine unbekannte Vorlage not-found, eine stillgelegte invalid an body.certificateTemplateId. Neu GET /learning/completions (learning.listCompletions): Abschlüsse, die zuletzt geänderten zuerst, Filter courseId, contactId, updatedSince, mit certificate (status none/pending/issued/failed, issuedDocumentId lesbar über letters.getIssued, failureReason). Neues Ereignis learning.course.completed (einmal je Teilnehmer und Kurs). Hat der Kurs eine Vorlage, wird das Zertifikat beim Abschluss ausgestellt (status issued mit issuedDocumentId, gescheitert failed mit failureReason); setzt das Team eine Vorlage, bekommen Abschlüsse ohne Zertifikat es nachträglich.
  • Automationen: Die Auslöser learning.course.completed, learning.submission.submitted und learning.submission.reviewed lassen sich auf Kurse einschränken (Filter courseId, Art course, „eines von“), etwa um nur beim Abschluss eines bestimmten Kurses einen nächsten Schritt anzustossen.

v1.344.0 · 3. November 2026

  • Lernplattform, Abgaben: GET /learning/submissions (learning.listSubmissions) listet die Abgaben der Teilnehmer in Lektionen der Art assignment, die zuletzt geänderten zuerst, mit Filtern courseId, lessonId, contactId, status (submitted, returned, accepted) und updatedSince; Entwürfe nie. GET /learning/submissions/{id} (learning.getSubmission) liefert die abgegebenen Runden mit Text, Dateien (documentId, filename, mimeType, sizeBytes; Abruf über GET /documents/{id}/download-url) und der Rückmeldung je Runde. POST /learning/submissions/{id}/feedback (learning.createSubmissionFeedback, 201) meldet auf die zuletzt abgegebene Runde zurück: result accepted schliesst die Lektion ab, returned gibt zurück, grade wahlweise; ohne abgegebene Runde 422 precondition-failed mit reason not-submitted, mit Rückmeldung already-answered. Neue Ereignisse learning.submission.submitted und learning.submission.reviewed.
  • Automationen: Der Auslöser learning.submission.reviewed lässt sich nach dem Ergebnis der Rückmeldung filtern (result: accepted, returned), etwa um nur bei angenommenen Abgaben einen nächsten Schritt anzustossen.

v1.343.0 · 3. November 2026

  • Lernplattform, Kursarten: type (selfPaced, class) ist an PATCH /learning/courses/{id} (learning.updateCourse) schreibbar; neu selfPacedStart (access mit dem Zugang, Vorgabe; firstOpen beim ersten Öffnen im Portal), lesbar am Kurs und schreibbar. Es wirkt nur bei selfPaced und bleibt am Klassenkurs gespeichert; ein Klassenkurs beginnt am gemeinsamen Start der Klasse, über die der Teilnehmer kam, ohne Start der Klasse mit dem Zugang. „Ab Tag n“ und immediately zählen ab diesem Start, ein Start in der Zukunft sperrt bis dahin.
  • Lernplattform, Termin-Lektionen: POST /learning/courses/{id}/lessons (learning.createLesson) nimmt type: "appointment"; appointmentId an createLesson und PATCH /learning/lessons/{id} (learning.updateLesson, null entfernt ihn); an einer Lektion anderer Art invalid, ein Termin, den es in der Organisation nicht gibt, not-found, jeweils an body.appointmentId. Neu GET /learning/lesson-appointments/options (learning.lessonAppointmentOptions: aktive Terminarten mit kind und capacity, laufende Terminreihen) und GET /learning/lesson-appointments (learning.listLessonAppointments: Termine zur Auswahl mit genau einem von appointmentTypeId und recurrenceId, keiner required, beide invalid; kommende zuerst, Seiten über cursor). In Kursregeln ist afterAppointment jetzt wählbar; ein Termin ausserhalb der Organisation gibt not-found an body.rule.conditions[i].appointmentId.

v1.342.0 · 3. November 2026

  • Klassen, gemeinsamer Start: GET /contact-lists, GET /contact-lists/{id}, POST /contact-lists und PATCH /contact-lists/{id} tragen startDate, den gemeinsamen Start der Klasse als Kalendertag yyyy-mm-dd in der Zeitzone der Organisation (null: noch kein Start); Kurse der Lernplattform für diese Klasse beginnen an diesem Tag. PATCH /contact-lists/{id} (contacts.updateList) nimmt jetzt { name?, startDate? }, mindestens eines von beiden (sonst validation-failed mit required); startDate: null löscht den Start, ein Tag, den es nicht gibt, oder ein Jahr ausserhalb 2000 bis 2100 ergibt validation-failed an body.startDate, und dann wird auch der Name nicht geändert. Untergruppen haben keinen Start.

v1.341.0 · 2. November 2026

  • Lernplattform, Freigaberegeln je Stelle im Kurs: rule und display an PATCH /learning/courses/{id} (learning.updateCourse; am Kurs immer gesetzt, Vorgabe sofort), PATCH /learning/modules/{id} und PATCH /learning/lessons/{id} (learning.updateModule, learning.updateLesson; null = keine eigene, es gilt die darüber) und in ihren Antworten; hasOwnRule an Modulen und Lektionen in learning.getCourse. Im Kurs zeigt afterItem auf module oder lesson, afterQuiz.quizId ist die Kennung der Lektion vom Typ quiz. Ein Bezug, den es im Kurs nicht gibt, gibt not-found, eine Stelle, die auf sich selbst oder etwas unter sich wartet, cycle, eine Lektion anderen Typs bei afterQuiz wrong-type, jeweils an body.rule.conditions[i]. POST /learning/releases/preview (learning.previewRule) nimmt statt collectionId auch courseId (mit moduleId oder lessonId); genau eins von beiden.
  • Das Schema der Bedingung ist geteilt und wird breiter: afterItem.targetType kennt jetzt auch module und lesson. Regeln einer Sammlung, ihrer Ordner und Inhalte enthalten nie module/lesson (sie werden dort mit invalid an body.rule.conditions[i].targetType abgelehnt), Regeln eines Kurses nie collection/content. Die Freigabe-Endpunkte (targetType bei listReleases, release, withdrawRelease) bleiben bei collection/content.

v1.340.0 · 2. November 2026

  • Terminarten tragen in liveRoom jetzt waitingRoom (AUTO, ON, OFF; Vorgabe AUTO): den Warteraum im claritos Live-Raum. Wer nicht Gastgeber oder Co-Moderator ist, wartet, bis der Termin live geht. AUTO lässt den Live-Raum nach Art entscheiden: an bei Unterricht und Gruppenterminen, sonst aus. Fehlt das Feld im PATCH, bleibt der gespeicherte Wert. Gilt bei jedem Eintritt, also auch für schon gebuchte Termine; schaltet der Gastgeber im Raum um, geht das vor. Lesen in appointments.getType/listTypes, setzen in createType/updateType.

v1.339.0 · 2. November 2026

  • Lernplattform: Ein Kurs aus GoHighLevel lässt sich in der Oberfläche auch als Sammlung der Bibliothek übernehmen; je Lektion entsteht ein offener Eintrag, bis eine Datei zugeordnet ist. Neu: GET /learning/collections/{id}/missing (learning.getCollectionMissing, offene und geschlossene Einträge mit path und expectedType), PUT /learning/collection-entries/{id}/media (learning.setCollectionEntryMedia, legt den Inhalt an; idempotent für dasselbe Medium, 409 bei einem anderen, wrong-type oder media-not-ready an body.assetId), POST /learning/collection-entries/{id}/dismiss und /reopen (learning.dismissCollectionEntry, learning.reopenCollectionEntry, 204).
  • Kurs-Import-Läufe (learning.getCourseImport, learning.listCourseImports, learning.startCourseImport) haben neu targetType (course oder collection) und collectionId. Läufe können jetzt auch Sammlungen sein (nur aus dem GoHighLevel-Importer der Oberfläche): dann ist courseId leer, ohne dass der Lauf gescheitert wäre, und missingVideos zählt die offenen Einträge. listCourseImports filtert mit targetType; für Sammlungsläufe gibt es keine Ereignisse learning.courseImport.*.

v1.338.0 · 2. November 2026

  • Lernplattform, Gliederung eines Kurses: Module mit POST /learning/courses/{id}/modules (learning.createModule), PATCH /learning/modules/{id} (learning.updateModule), POST /learning/modules/{id}/move (learning.moveModule), DELETE /learning/modules/{id} (learning.deleteModule; ohne cascade rücken Untermodule und Lektionen eine Ebene hoch, mit ?cascade=true werden sie gelöscht, Antwort mit movedLessonCount, movedModuleCount, bei cascade dazu deletedLessonCount, deletedModuleCount), POST /learning/courses/{id}/modules/order (learning.orderModules). Lektionen mit GET/PATCH/DELETE /learning/lessons/{id} (learning.getLesson, learning.updateLesson, learning.deleteLesson mit 204), POST /learning/courses/{id}/lessons (learning.createLesson), POST /learning/lessons/{id}/move (learning.moveLesson), POST /learning/courses/{id}/lessons/order (learning.orderLessons). Quiz mit PATCH /learning/lessons/{id}/quiz (learning.updateQuiz: passMark, passedText, failedText), POST /learning/lessons/{id}/questions (learning.createQuestion), PATCH/DELETE /learning/questions/{id} (learning.updateQuestion, learning.deleteQuestion mit 204), POST /learning/lessons/{id}/questions/order (learning.orderQuestions). Eine dritte Modulebene meldet validation-failed mit code too-deep an body.parentId, unpassende Antworten invalid an body.options.
  • Behoben: includeArchived=false an learning.listAccesses, learning.listCollections, learning.listContents und learning.listCourses lieferte bisher auch Archiviertes (jeder nicht leere Wert galt als true). Der Parameter nimmt jetzt true oder false.

v1.337.0 · 2. November 2026

  • Lernplattform, Kurse: neue Endpunkte GET /learning/courses (learning.listCourses), GET/PATCH /learning/courses/{id} (learning.getCourse mit Gliederung, learning.updateCourse), POST /learning/courses/{id}/publish (learning.publishCourse; fehlen Videos oder richtige Antworten, 422 mit reason course-incomplete, missingVideoCount, missingAnswerCount, behebbar mit confirmIncomplete: true), POST /learning/courses/{id}/archive und /unarchive, GET /learning/courses/{id}/missing (learning.getCourseMissing), PUT /learning/lessons/{id}/media (learning.setLessonMedia, 409 wenn schon ein Medium da ist) und PUT /learning/questions/{id}/answers (learning.setQuestionAnswers, correctIndexes als Stellen ab 0).

v1.336.0 · 2. November 2026

  • Lernplattform, Kurs-Import: claritos holt die Dateien eines Imports (Bilder, Videos, Ton, Materialien) jetzt in die Medienbibliothek. Neu je Eintrag in files[] (GET /learning/course-imports/{id}, learning.listCourseImports): failureReason (nur bei failed: not-https, blocked-network, too-large, timeout, wrong-type, source-error, invalid-url, dns-failed, too-many-redirects, connection-aborted, empty, internal-error), httpStatus (nur bei source-error) und assetId (bei done). Neu counts.filesPending, auch im Ereignis learning.courseImport.completed: Die Dateien kommen nach diesem Ereignis, filesPending > 0 heisst, es läuft noch. Video und Ton bis 2 GiB, sonst 200 MB.

v1.335.0 · 2. November 2026

  • Lernplattform, Klassen am Zugang: neue Endpunkte GET /learning/accesses/{id}/contact-lists (learning.getAccessContactLists) und PUT /learning/accesses/{id}/contact-lists (learning.setAccessContactLists, ganze Menge contactListIds, Antwort mit grantedCount und revokedCount). Eine gewählte Klasse gewährt allen heutigen Mitgliedern den Zugang (source class), eine abgewählte beendet nur diese Vergaben (Ereignis learning.access.ended mit reason class); Vergaben aus anderen Quellen bleiben. Neu contactListIds am Zugang. learning.listAccesses liefert jetzt auch notifyOnGrant, wie der Einzelabruf.

v1.334.0 · 2. November 2026

  • Lernplattform, Ordner in Sammlungen (zwei Ebenen: Ordner und Unterordner): neue Endpunkte GET/POST /learning/collections/{id}/folders (learning.listFolders, learning.createFolder), PATCH/DELETE /learning/folders/{id} (learning.updateFolder, learning.deleteFolder mit movedContentCount und movedFolderCount; Inhalte und Unterordner rücken eine Ebene nach oben), POST /learning/folders/{id}/move (learning.moveFolder) und POST /learning/collections/{id}/items/order (learning.orderItems, Ordner und Inhalte einer Ebene). Neu folderId an Inhalten (lesen, createContent, addContents, updateContent; null = oberste Ebene), folderPath an Suchtreffern und folderId in learning.previewRule. Eine dritte Ebene lehnt die Schnittstelle mit dem Code too-deep ab. learning.orderContents ordnet weiter nur die übergebenen Inhalte.

v1.333.0 · 2. November 2026

  • Neu: Passkeys des Kontakts im Kundenportal GET /contacts/{id}/portal-passkeys (contacts.getPortalPasskeys, contacts:read): passkeyCount, lastUsedAt und je Passkey data[] mit id (Kennung des Eintrags bei claritos, nicht die Credential-Kennung), label (Anbieter oder Gerät), createdAt, lastUsedAt. Öffentliche Schlüssel und Credential-Kennungen gibt die API nie heraus. Dazu DELETE /contacts/{id}/portal-passkeys (contacts.removePortalPasskeys, contacts:write): entfernt alle Passkeys, etwa nach einem verlorenen Telefon; die Person meldet sich danach wieder mit Code an. Antwort { removedCount } mit Status 200, ohne Passkeys removedCount: 0; unbekannter Kontakt not-found.

v1.332.0 · 2. November 2026

  • Konversationen, Stimmung: Jede Unterhaltung in GET /inbox/conversations und GET /inbox/conversations/{id} trägt sentiment (positive, neutral, negative, null = noch nicht eingestuft), die Stimmung der zuletzt eingestuften eingehenden E-Mail. Neuer Filter sentiment (positive, neutral, negative, none = noch nicht eingestuft); er setzt den Kanal auf email, weil SMS nie eingestuft werden. GET /inbox/conversation-counts nennt dazu sentiments { positive, neutral, negative, none }, gezählt über offene E-Mail-Unterhaltungen.

v1.331.0 · 2. November 2026

  • Lernplattform, Kurs-Import: neue Endpunkte POST /learning/course-imports (learning.startCourseImport, 202), GET /learning/course-imports/{id} (learning.getCourseImport) und GET /learning/course-imports (learning.listCourseImports, Filter sourceSystem, sourceCourseId). Ein Programm schickt einen ganzen Kurs (Module, Untermodule, Lektionen, Quiz samt richtiger Antwort; Dateien als Adresse), claritos importiert ihn im Hintergrund als Entwurf; ein zweiter Import derselben Herkunft ergänzt. Neue Ereignisse learning.courseImport.completed und learning.courseImport.failed (mit reason).

v1.330.0 · 2. November 2026

  • Lernplattform, mehrere Inhalte auf einmal: neuer Endpunkt POST /learning/collections/{id}/contents (learning.addContents) mit assetIds (1 bis 50 Dateien der Medienbibliothek). Je Datei entsteht ein unveröffentlichter Inhalt am Ende der Sammlung, in der Reihenfolge von assetIds; Titel ist der Name der Datei in der Medienbibliothek. Antwort 201 { created, failed }; ein Fehler bei einer Datei hält die anderen nicht auf, failed nennt je Datei den Grund (not-found, media-not-ready, limit-reached, failed).

v1.329.0 · 2. November 2026

  • Lernplattform, Mail bei neuem Zugang: Jeder Zugang trägt notifyOnGrant (ab Werk an, schreibbar in POST /learning/accesses und PATCH /learning/accesses/{id}). Ist es an, bekommt ein Kontakt eine Mail mit dem Link ins Portal, sobald der Zugang für ihn wirksam wird. Jede Vergabe trägt dazu accessEmailStatus (pending, sent, skipped, failed), accessEmailSkipReason (bei skipped: disabled, alreadyActive, noEmail, companyWithContacts, ambiguousEmail, beforeIntroduction) und accessEmailAt.

v1.328.0 · 2. November 2026

  • Lernplattform, Aufzeichnungen ohne volle Kurs-Zustimmung: POST /learning/contents mit einem Dokument einer Live-Sitzung, dem nicht alle Teilnehmer zugestimmt haben, antwortet 422 precondition-failed mit reason recording-consent-incomplete, consentedCount, participantCount und fixable: true; mit dem neuen Feld confirmIncompleteConsent: true wird angelegt und die Bestätigung festgehalten. Jeder Inhalt trägt dazu consentConfirmation (null oder confirmedAt, consentedCount, participantCount, confirmedByUserId, confirmedByApiKeyId).

v1.327.0 · 2. November 2026

  • Lernplattform, Suche: GET /learning/contents/search (q 2 bis 100 Zeichen, limit 1 bis 100 ohne Blättern). Treffer in Titel, Beschreibung, Gesprochenem (positionMs) und PDF-Seiten (pdfPage), Feld matchIn, excerpt. Mit contactId nur, was dieser Kontakt sieht, gesperrte Treffer mit locked und unlockReasons; ohne die ganze Bibliothek samt Entwürfen (draft). Zu kurzer Begriff: 422 validation-failed an query.q.

v1.326.0 · 2. November 2026

  • Lernplattform, Material nach der Stunde: GET/PUT /appointment-types/{id}/learning-material (Liste aus der Bibliothek, die zum Ende jedes Termins dieser Art frei wird, recordingCollectionId für die Aufzeichnung als Entwurf, attendeesOnly), GET/PATCH /appointments/{id}/learning-material (add, hide, attendeesOnly abweichend, withheld; Antwort mit releasedAt und recipientCount) und POST /appointments/{id}/learning-material/release (jetzt freigeben; mit „nur Anwesende“ ohne Messung 422 precondition-failed, reason attendance-not-measured). Die Freigaben melden sich über learning.content.released mit source appointment.

v1.325.0 · 2. November 2026

  • Lernplattform: Sammlungen tragen notifyDelivery, die Vorgabe des Teams für Benachrichtigungen an Teilnehmende (bellOnly, push, emailNow, emailDaily, emailWeekly, sms; null heisst Vorgabe von claritos, also Wochenüberblick). Lesen in GET /learning/collections, setzen über POST /learning/collections und PATCH /learning/collections/{id}. Die Glocke im Portal kommt immer dazu; jedes Mitglied kann es für sich ändern. Bei notify: false wird das Feld nicht gelesen.

v1.324.0 · 2. November 2026

  • Lernplattform: die Bibliothek vollständig über die API. Sammlungen (GET/POST /learning/collections, PATCH /learning/collections/{id}, …/publish, …/archive und …/unarchive, POST /learning/collections/order) mit Freigaberegel als rule (match all oder any, höchstens fünf conditions: immediately, afterDays, fromWeek, onDate, afterItem, afterQuiz, afterAppointment, fromLevel, manual), Anzeige display und Dauer duration. Inhalte (GET /learning/collections/{id}/contents, POST /learning/contents aus Medienbibliothek assetId, Dokument oder https-Link, PATCH, …/media für eine neue Fassung, …/publish, …/archive, …/unarchive, Reihenfolge) mit Nutzung releasedTo/seenBy. Zugänge anlegen und pflegen (POST /learning/accesses, PATCH, …/archive, …/unarchive, PUT …/collections). Freigaben: GET /learning/releases, POST /learning/releases (von Hand), POST /learning/releases/withdraw, POST /learning/releases/preview (Regel vorab rechnen, schreibt nichts). Zugänge eines Artikels: GET/PUT /articles/{id}/learning-accesses.

v1.323.0 · 2. November 2026

  • Neu: Konversationen, E-Mail-Fäden und SMS-Verläufe in einer Liste. GET /inbox/conversations filtert nach Ansicht (open, starred, closed), Kanal, Postfach, Ungelesen, Kontakt-Tag oder Tag-Gruppe (contactTagMode any/all), Kampagne (campaignId: Antworten seit dem Versand, wie im Kampagnen-Bericht) und Suche; sort waiting stellt voran, wer am längsten wartet (waitingSince); geblättert wird mit cursor und limit wie überall. GET /inbox/conversations/{id} liefert den Verlauf, POST /inbox/conversations/update setzt für viele auf einmal read, unread, star, unstar (für die Person hinter dem Zugang) sowie close und reopen (für alle), mit results je Kennung (updated, notFound), GET /inbox/conversation-counts die Zahlen je Ansicht, Kanal, Postfach, Kontakt-Tag und Kampagne, PUT /inbox/conversations/{id}/contact ordnet einen Kontakt zu. inbox.listThreads und Verwandte bleiben unverändert.

v1.322.0 · 2. November 2026

  • Neu bei den Automationen: zwei Aktionen der Lernplattform. „Zugang zur Lernplattform gewähren“ ruft POST /learning/grants, „Zugang zur Lernplattform entziehen“ ruft POST /learning/grants/revoke; dieses entzieht nur Vergaben aus Hand, API oder Automation, Vergaben aus einem Kauf oder einer Klasse bleiben. GET /automation-catalog nennt beide, das Feld accessId mit der Quelle learningAccess. Ausserdem tragen die Ereignisse learning.access.granted und learning.access.ended die Tage der Vergabe als grant.startDate und grant.endDate, wie die Vergabe in GET /learning/grants.

v1.321.0 · 2. November 2026

  • Neuer Bereich learning (Lernplattform, Rechte learning:read und learning:write): GET /learning/accesses listet die Zugänge, GET /learning/grants die Vergaben eines Kontakts oder eines Zugangs, POST /learning/grants gewährt einen Zugang (wiederholbar; über die API mit Quelle api, aus einer Automation mit Quelle automation), POST /learning/grants/{id}/revoke entzieht ihn mit Grund, POST /learning/grants/revoke entzieht einem Kontakt einen Zugang. Entzogen werden nur Vergaben aus Hand, API und Automation; Vergaben aus einem Kauf oder einer Klasse antworten 422 precondition-failed mit reason grant-source-protected. Verlangt das Recht LERN_BIBLIOTHEK der Organisation, sonst 403 feature-not-available.

v1.320.0 · 2. November 2026

  • Neu: drei Ereignisse der Lernplattform für Webhooks und Automationen. learning.access.granted, wenn ein Kontakt einen Zugang bekommt, aus jeder Quelle (grant.source: manual, api, automation, purchase oder class). learning.access.ended, wenn ein Zugang wirklich endet, durch Entzug oder Ablauf, auch zu einem späteren Zeitpunkt, mit grant.endedAt und grant.reason (manual, api, automation, payment, cancelled, ended, class oder expired). learning.content.released, wenn eine Sammlung oder ein Inhalt für einen Kontakt frei wird (release.targetType collection oder content, release.source rule, appointment oder manual). Je Kontakt ein Ereignis; die Nutzlast trägt Kennungen, Namen und Zeitpunkte, keinen Lernfortschritt. Gemeldet wird, sobald die Lernplattform in Betrieb ist.

v1.319.0 · 2. November 2026

  • Drei neue Rechte für die Lernplattform in GET /organization/entitlements und in den Lizenz-Endpunkten: LERN_BIBLIOTHEK (Bibliothek), LERN_KURSE (Kurse) und LERN_COMMUNITY (Community). Sie haben keine Voraussetzung; Endpunkte der Lernplattform selbst folgen.
  • DELETE /articles/{id} antwortet 409 in-use jetzt auch, wenn ein Kauf des Artikels einen Zugang der Lernplattform gewährt (usage.learningAccesses).

v1.318.0 · 1. November 2026

  • Neu: Antworten aus dem CRM über eine SendGrid-Domain. PUT /sendgrid/domains/{id}/crm-replies mit enabled wählt eine Domain mit bereitem Antwortbereich (höchstens eine; eine andere verliert die Wahl) oder löst sie; die Domain trägt crmReplies. Reply-To der Mails aus dem Kontakt ist dann der Absender vor dem @ auf dem Antwort-Host (eigener Absendername, sonst der Teil vor dem @ seiner Absenderadresse, nur wenn eindeutig, sonst der Antwort-Alias der Organisation); die Antwort landet bei dieser Person. Ohne bereiten Antwortbereich 422 precondition-failed mit reason sendgrid-replies-not-set-up; in Production bis zum Nachtrag der Datenschutzerklärung reason sendgrid-personal-not-released.

v1.317.0 · 1. November 2026

  • Neu: Zustimmung zu Terminerinnerungen eintragen POST /contacts/{id}/reminder-service/subscribe (contacts.subscribeReminders, contacts:write), das Gegenstück zu contacts.unsubscribeReminders, etwa für eine Zustimmung aus dem Onboarding vor dem ersten Termin. Body: channels (email, sms; ohne Angabe beide, soweit der Kontakt einen Wert hat) und note (Pflicht, wie zugestimmt wurde). Antwort wie getReminderService plus revocationKept: Kanäle, die der Kontakt selbst abbestellt hat; dort wird nichts eingetragen. Die handelnde Person steht im Eintrag, ohne Person no-acting-user; ohne Wert am Kontakt validation-failed.

v1.316.0 · 1. November 2026

  • Geändert, Spec gleich: conversation.sendEmail, conversation.getComposeOptions und conversation.checkPermission gehen auch an einen Kontakt mit Klientenakte ohne Freigabe der Klientendaten (vorher 404 not-found). Die Mail ist eine normale Mail im Gespräch und steht im allgemeinen Postausgang; Akte-Post ist dann nicht möglich. Den Verlauf eines solchen Kontakts (conversation.list, getEntry, getReplyBasis) liest weiter nur, wer die Freigabe hat. q in GET /outbound-emails sucht jedes Wort für sich in Betreff, Empfängeradresse und Name des Kontakts, an den die Mail ging, mit Umlauten auch in der Schreibweise mit e. E-Mail-Kampagnen: Eine neue Kampagne startet mit Klientenschutz aus (clientProtection.enabled false); POST /email-campaigns/{id}/client-protection mit enabled: false braucht Klientendaten und clients:read nur noch, wenn schon Mails der Kampagne im Klientenbereich stehen.

v1.315.0 · 1. November 2026

  • Neu: Co-Moderatoren zu Gruppenterminen. POST /appointments/{id}/co-moderators/check zeigt vor dem Einladen je Termin free, busy oder already; POST /appointments/{id}/co-moderators lädt ein Teammitglied (userId) oder einen Kontakt (contactId) ein, scope appointment oder series (dieser und alle folgenden der Terminreihe; spätere Termine der Reihe übernehmen ihn), belegte und schon eingeladene Termine stehen in skipped; POST /appointments/{id}/co-moderators/remove lädt aus (removed). Der Co-Moderator bekommt eine eigene Einladung mit Kalenderdatei und Link, ist im claritos Live-Raum ab dem Eintritt Co-Host und belegt keinen Platz; ein Teammitglied mit Ressource ist für die Zeit belegt. 422 co-moderator-without-email, not-a-group-appointment, appointment-not-open. Teilnehmer tragen isCoModerator (side PROVIDER); hosts und der Filter contactId in GET /appointments zählen Co-Moderatoren nicht.

v1.314.0 · 1. November 2026

  • Terminarten tragen practiceRelevant (Vorgabe false): Betrifft die Terminart den Praxisbetrieb? Nur dann stehen ihre Mails in einer Organisation mit Praxisbetrieb im Postausgang des Klientenbereichs, sonst im allgemeinen (letters.listEmails). Lesen in appointments.getType/listTypes, setzen in createType/updateType. Beim Umschalten wandern die schon versendeten Mails mit. Ausschalten nur mit Klientendaten (clients:read, für die API freigegeben), sonst 403 forbidden mit reason practice-off-needs-client-access. Geändert, Spec gleich: Termine, die per Telefon, in der Praxis oder als Hausbesuch stattfinden, bekommen keinen Video-Raum mehr; meetingUrl bleibt dort leer.

v1.313.0 · 1. November 2026

  • Geändert in der Regelsprache, Spec gleich: Ein Name in einer Formel, der bei genau einem Laborwert der Hauptname ist, meint diesen, auch wenn andere Werte ihn als Suchbegriff tragen ({{Kreatinin}} ist das Serum-Kreatinin, nicht mehr mehrdeutigerName). Zwei Werte mit demselben Hauptnamen bleiben mehrdeutig. formula in den Antworten zu Regeln schreibt einen Namen nur, wenn er beim Lesen zum selben Ziel führt, sonst die Kennung ({{loinc:2160-0}}, {{G-A1-01}}); jede formula lässt sich unverändert wieder senden. Laborwerte der Art Index oder Verhältnis ohne eigene Einheit sind in Formeln ohne Einheit ({{HOMA-IR}} >= 2,5); vorher galt die Beschriftung des Systemkatalogs als Einheit und einheitFehlt kam.

v1.312.0 · 31. Oktober 2026

  • Neu bei den Automationen: ein Filter auf eine Antwort im Formular am Auslöser forms.response.submitted. Im trigger.filter steht dafür response.answers.‹feld› mit dem Schlüssel einer Option als Wert, Feld und Option wie in GET /forms/{id}/analysis (das Feld hat die Form art:kennung, etwa def:… oder std:…). Der Filter passt, wenn die Antwort die Option enthält, bei Mehrfachauswahl also auch neben anderen; Ja/Nein heisst true bzw. false. Höchstens zehn solche Einträge je Regel, alle müssen passen. GET /automation-catalog nennt den Filter mit kind formAnswer und path response.answers. Bögen an der Akte melden keine Antworten, dort trifft der Filter nie.

v1.311.0 · 31. Oktober 2026

  • Geändert: DELETE /appointments/{id}/participants/{contactId} entfernt auch den letzten Teilnehmer eines Unterrichts oder eines Gruppentermins „nur intern“; der Termin bleibt mit freien Plätzen stehen. Bisher kam dort last-participant (beim Event durfte der Letzte schon gehen). Der Ausgetragene bekommt wie bisher seine Absage.

v1.310.0 · 31. Oktober 2026

  • Neu: Wortwolke der Freitexte in GET /forms/{id}/analysis. Jede Freitextfrage trägt terms (items mit term, display, count, kind word, pair oder answer, dazu belowThreshold und hidden), ohne KI gezählt: je Einreichung, erst ab 3 Einreichungen, höchstens 40, ohne E-Mail-Adressen, Web-Adressen, Telefonnummern, Zahlen und Füllwörter; andere Fragen haben terms: null. Neu auf oberster Ebene hiddenTerms. PUT /forms/{id}/analysis/hidden-terms mit terms ersetzt die Liste der ausgeblendeten Begriffe (nur Admins, forms:write); ein Einzelwort blendet jedes Wortpaar mit aus, in dem es steht.

v1.309.0 · 31. Oktober 2026

  • Neu: GET /forms/{id}/analysis/group liefert die Kontakte hinter den Filtern einer Auswertung (Zeitraum, Link, Sprache, Antwort wie bei GET /forms/{id}/analysis) als contactIds, dazu withoutContact für Einreichungen ohne Kontakt. Damit legt man wie der Reiter „Handeln“ eine Kontaktliste (POST /contact-lists, POST /contact-lists/{id}/members) oder eine Aufgabe (POST /tasks) an.

v1.308.0 · 31. Oktober 2026

  • Neu: Rücklauf der persönlichen Links eines Formulars. GET /forms/{id}/follow-up liefert je Link an einen Kontakt oder Interessenten den Stand (submitted, started, opened, not-opened, expired), wann und wie oft erinnert wurde und remindBlockedBy; Links an eine Akte zählen nicht. POST /forms/{id}/follow-up/remind mit linkIds (höchstens 50) und templateId (Nachrichtenvorlage für Kontakte) schickt jeder Person die Vorlage mit ihrem persönlichen Link, im Namen der handelnden Person über dieselbe Sendestelle wie POST /contacts/{id}/conversation/email; braucht email:write. Übersprungen wird, was eingereicht, abgelaufen, ohne Kontakt oder Adresse ist oder in den letzten 24 Stunden erinnert wurde (skipped); ohne Absender 422 precondition-failed mit Grund no-sender.

v1.307.0 · 31. Oktober 2026

  • Neu: Zusammenhänge in den Antworten eines Formulars. GET /forms/{id}/analysis/relations prüft jedes Paar aus zwei Fragen (Auswahl, Ja/Nein, Optionen einer Mehrfachauswahl mit mindestens 3 Nennungen, Zahlen; Angaben zur Person nie) und, mit contacts:read, Merkmale des Kontakts hinter der Einreichung (Land, Schlagworte, Klassen, betreuender Partner, Phase je Pipeline, Jahr der Anlage; contactFeatures). Geprüft wird über die Einreichungen, die beide Merkmale haben (mindestens 10, Gruppen mit mindestens 5), mit exaktem Test nach Fisher, Chi-Quadrat, Mann-Whitney oder Kruskal-Wallis und danach der Korrektur nach Benjamini-Hochberg über alle Paare: findings mit level relationship (q unter 0,05) oder hint (unter 0,1), höchstens 20, dazu checked und tooSmall. Mit compareA und compareB zusätzlich comparison: Kreuztabelle oder Gruppen mit Median und Spanne, Stufe aus derselben Korrektur. Filter wie bei GET /forms/{id}/analysis.

v1.306.0 · 31. Oktober 2026

  • Neu: KI-Auswertung eines Formulars. GET /forms/{id}/analysis/ai liefert die Zusammenfassung des jüngsten Laufs: Aussagen mit Art (counted gezählt, classified KI-Einordnung) und Belegen (Optionen, Einreichungen), Themen der Freitexte mit ihren Einreichungen, Vorschläge für neue Optionen; jede Zahl einer Aussage steht im Faktenblatt, andere werden nicht geliefert (discarded). POST /forms/{id}/analysis/ai startet einen Lauf (202, runId), PUT /forms/{id}/analysis/ai/setting schaltet ihn je Formular ein oder aus (Admins; Ausschalten löscht Zusammenfassungen). An die KI gehen die Fragen, gezählte Ergebnisse und Freitexte; Felder für Name, Anschrift, Geburtsdatum, E-Mail-Adresse und Telefonnummer bleiben weg, soweit sie als solche erkennbar sind (vorgefertigte Felder zur Person, Felder der Art E-Mail, Telefon, Internetadresse, eigene Felder, deren Beschriftung danach klingt). Braucht das Recht der Organisation für die KI-Auswertung (403 feature-not-available). Dazu in GET /forms/{id}/analysis neu dataQuality: Antworten bei verborgenen Fragen, mehrfach eingereicht, Pflicht fehlt.

v1.305.0 · 31. Oktober 2026

  • Neu: Bewegung als Katalog sport der Regelsprache, das Compendium of Physical Activities 2024 (noch nicht ausgeliefert). GET /physical-activities sucht einen Code (auch angefangen) oder Wörter der englischen Beschreibung; jeder Treffer nennt compendium (adult, older-adult, wheelchair), group, met mit metBasis (MET, MET60, METWC, nicht untereinander vergleichbar) und die Quellenangabe in source. Ein Eintrag ist der Code mit führender Null (01003); beim Speichern und Genehmigen einer Regel muss er eingespielt sein, sonst eintragUnbekannt. GET /standard-catalogs zeigt activities (Anzahl, Kompendien, inPlan, planRelease, Quellen). PATCH /standard-catalogs/sport mit { inPlan } gibt Bewegung für den Plan des Klienten frei oder nimmt das zurück, nur eine Person mit dem Recht „Regeln genehmigen“, nie eine Automation und nie der MCP (403 forbidden); im Plan stehen Name, Dauer und Häufigkeit, kein MET-Wert. Ohne Freigabe zählt Bewegung in internalLeftOut.

v1.304.0 · 31. Oktober 2026

  • Neu: die ICD-11 der WHO als Katalog icd11 der Regelsprache, neben icd10gm (noch nicht ausgeliefert). GET /diagnosis-codes nimmt catalog (icd10gm als Vorgabe oder icd11); jeder Treffer trägt jetzt titleDeMissing (nur ICD-11: die deutsche Vorabversion hat für den Code noch keinen Titel, title ist dann der englische), titleEn und uri (nur ICD-11; Code, Titel und URI gehören bei jeder Weitergabe zusammen, Lizenz der WHO). Beim Speichern und Genehmigen einer Regel muss ein ICD-11-Code in der aktiven Fassung stehen, sonst eintragUnbekannt; in einem persönlichen Plan steht eine Diagnose nie, sie zählt in internalLeftOut. Geändert: GET /standard-catalogs liefert diagnoses als Liste der aktiven Diagnosen-Kataloge (id, version, count) statt als einzelnes Objekt; 1.303.0 war noch nicht ausgeliefert.

v1.303.0 · 31. Oktober 2026

  • Neu: Lebensmittel als Katalog lebensmittel der Regelsprache (noch nicht ausgeliefert). Ein Eintrag ist der slug eines Lebensmittels aus GET /foods/search; beim Speichern und Genehmigen einer Regel muss er in der Datenbank stehen, sonst eintragUnbekannt. GET /rulebook-catalogs listet lebensmittel mit den Einträgen, die Regeln der Organisation verwenden. GET /standard-catalogs zeigt Lebensmittel (Anzahl, inPlan, planRelease, Quellen) und die aktive ICD-10-GM; PATCH /standard-catalogs/lebensmittel mit { inPlan } gibt Lebensmittel für den Plan des Klienten frei oder nimmt das zurück, nur eine Person mit dem Recht „Regeln genehmigen“, nie eine Automation und nie der MCP (403 forbidden). Ohne Freigabe bleiben Lebensmittel intern und zählen in internalLeftOut der persönlichen Pläne.

v1.302.0 · 31. Oktober 2026

  • Neu: Diagnosen der ICD-10-GM als Katalog icd10gm der Regelsprache (noch nicht ausgeliefert). GET /diagnosis-codes?q= sucht in der aktiven Fassung nach einem Code (auch angefangen, E11) oder Wörtern im Titel, deutsch oder russisch, und liefert Code, amtlichen Titel, russischen Titel (titleRuFrom nennt den übergeordneten Code, wenn der eigene fehlt), Ebene und ob der Code kodierbar ist; catalog mit Fassung und Quellenangabe, null, solange keine Fassung eingespielt ist. GET /rulebook-catalogs listet icd10gm, sobald eine Fassung da ist; entries nennt dort nur die Codes, die Regeln der Organisation verwenden. Beim Speichern und Genehmigen einer Regel muss jeder Code in empfehlung(icd10gm; <Code>) in der aktiven Fassung stehen, sonst eintragUnbekannt. Diagnosen stehen nie im Plan eines Klienten.

v1.301.0 · 31. Oktober 2026

  • Neu: GET /forms/{id}/responses/export, die Einreichungen eines Formulars als CSV. Eine Zeile je Einreichung, älteste zuerst: Kennung, Zeitpunkt (Berlin), Link, Sprache, dann je Frage eine Spalte in der Reihenfolge des Formulars. Auswahl als Wort von heute (sonst das Wort der Einreichung), Zahlen als Zahlen, Messwert und Raster in eigenen Spalten, eine Wiederholgruppe in einer Zelle, Berichtigungen eingerechnet. Dieselben Filter wie GET /forms/{id}/analysis. Spaltenköpfe in locale; bei en Komma, sonst Semikolon mit Dezimalkomma; BOM vorn. Formulare der Klientenakte nur mit Klientendaten-Freischaltung und clients:read.

v1.300.0 · 31. Oktober 2026

  • Neu: GET /forms/{id}/analysis, die Auswertung eines Formulars mit denselben Zahlen wie die Seite „Auswertung“. Je Frage der Nenner (shown: wem sie gezeigt wurde, bei bedingten Fragen nur bei zutreffender Bedingung), Zählung nach Options-Schlüssel samt Optionen, die es nicht mehr gibt (inForm: false), Freitexte einer „Andere“-Option an der Option (otherTexts), Kennzahlen für Zahlen und Messwerte, Freitexte im Wortlaut; Angaben zur Person nur gezählt (kind: personal). Dazu Einreichungen je Tag und Sprache und dropOff, die Abbruch-Kette aus der Messung des Formulars. Filter from, to, link (personal, none oder die Kennung eines öffentlichen Links), language, question mit option. Formulare der Klientenakte nur mit Klientendaten-Freischaltung und clients:read.

v1.299.0 · 30. Oktober 2026

  • Einwilligungs-Protokoll (GET /consent-log): neuer Zweck purposes.partnerAttribution (Partner-Zuordnung: ein Kauf wird dem Partner zugeordnet, über dessen Werbe-Code der Besucher kam). Fehlt er in älteren Einträgen, steht er auf false. Die Ausfuhr (GET /consent-log/export) hat dafür eine Spalte mehr, „Partner-Zuordnung“, nach „Auf diesem Geraet angemeldet bleiben“.

v1.298.0 · 30. Oktober 2026

  • Neu: Klientenschutz an E-Mail-Kampagnen. Feld clientProtection (enabled, changedAt; null ohne wirksamen Praxisbetrieb) und PUT /email-campaigns/{id}/client-protection mit { enabled }, in jedem Stand. Aus: Mails an Empfänger mit Akte stehen im allgemeinen Postausgang und am Kontakt; die schon versendeten wandern mit, an bringt sie zurück in den Klientenbereich. Ausschalten nur mit Freischaltung der Klientendaten, clients:read und Zugang der handelnden Person zum Klientenbereich (403 client-access-required); ohne Praxisbetrieb 422 practice-module-inactive.

v1.297.0 · 30. Oktober 2026

  • GET /organization/invitations: Nie angenommene Einladungen (offen, abgelaufen, zurückgezogen) werden am Tag nach ihrem Ablauf gelöscht und erscheinen danach nicht mehr, auch nicht mit status=EXPIRED; DELETE /organization/invitations/{id} auf eine solche Einladung antwortet dann 404 statt 204. Angenommene Einladungen bleiben. Die Beschreibung des Felds status sagt es.

v1.296.0 · 30. Oktober 2026

  • Neu: Herleitung (noch nicht ausgeliefert). GET /personal-plans/{id}/derivation liefert den Lauf, aus dem ein persönlicher Plan angelegt wurde, in der Form von POST /rulebooks/{id}/compute, dazu je gelesenem Wert die Herkunft (origins: Datum, Laborbericht); nur Personen mit dem Recht „Regeln genehmigen“, sonst 403 physicians-only. GET /care-enrollments/{id}/derivation liefert den Vorschlag, aus dem eine Betreuung gestartet wurde: Regelwerk, Fassung und Regel je Vorlage und Baustein, mit der Spur als Liste (Tiefe, Wert, Herkunft, Datum); ohne dieses Recht nur Regelwerk und Fassung (physicianView: false). Pläne und Betreuungen von vorher haben keine Herleitung (run bzw. derivation leer).

v1.295.0 · 30. Oktober 2026

  • Neues Recht FORMULAR_KI (KI-Auswertung von Formularen) in GET /organization/entitlements und in den Lizenz-Endpunkten. Es hat keine Voraussetzung und schaltet die KI-Teile der Formular-Auswertung frei, sobald diese ausgeliefert sind; Zahlen und Diagramme hängen nicht daran.

v1.294.0 · 30. Oktober 2026

  • Geändert (Entscheidung des Betreibers, noch nicht ausgeliefert): Was Regeln über einen Menschen sagen, lesen nur Personen mit dem Recht „Regeln genehmigen“. POST /rulebooks/{id}/compute und GET /rule-runs/{id} antworten sonst 403 physicians-only (über den MCP mit einer solchen Person erlaubt, für eine Automation ohne Person nie); GET /clients/{id}/rule-runs bleibt. Persönliche Pläne kommen für alle anderen ohne rules an den Empfehlungen, und Empfehlungen, die inzwischen intern sind, ohne Namen, Text und Angaben.

v1.293.0 · 30. Oktober 2026

  • Persönliche Pläne enthalten nur Lebensstil und Wohlbefinden (Entscheidung des Betreibers, noch nicht ausgeliefert): Eigene Kataloge sind intern, bis eine Person mit dem Recht „Regeln genehmigen“ sie für den Plan freigibt (inPlan im PATCH /rulebook-catalogs/{key}, gelesen mit inPlan und planRelease; nur in den Lebensstil-Bereichen, other antwortet 409 area-never-in-plan). Einträge tragen doctorsOnly (setzen nur dieselben Personen, PATCH …/entries/{entryKey}). Beides nie über eine Automation oder den MCP (403 release-needs-person). professionalOnly entfällt. An den Plänen: internalLeftOut statt professionalOnlyLeftOut, internalEntries, lifestyleConfirmation, Lücke recommendations-internal, 409 all-internal statt professional-only; POST /personal-plans/{id}/release verlangt confirmLifestyle: true.

v1.292.0 · 30. Oktober 2026

  • Geändert gegenüber 1.291.0 (noch nicht ausgeliefert): release.waitingFor in GET /organization/license trägt englische Werte (receivables, payables, subscriptions, affiliate-sales, affiliate-claims, affiliate-credit-notes, affiliate-drafts, affiliate-clawbacks, affiliate-other, sonst other). Abgeben und Zurücknehmen einer Organisation bleiben in der Anwendung (Entscheidung des Betreibers), weil am Ende eine Löschung steht.

v1.291.0 · 30. Oktober 2026

  • Neu in GET /organization/license: je Organisation release (läuft eine Abgabe: seit, Lesephase bis, Phase read-only oder stopped, Sicherung angefordert und verschickt, was die Löschung aufhält, ob sie sich zurücknehmen lässt) und releasable (ob sie sich abgeben lässt). Abgeben und Zurücknehmen selbst gehen vorerst nur in der Anwendung.

v1.290.0 · 30. Oktober 2026

  • Neu: Änderungen der Lizenz über die API, immer in zwei Schritten. POST /organization/license/changes/preview rechnet die Änderung eines Bausteins (Menge, Takt) vorab: Wirkung sofort mit anteiliger Rechnung oder zum Stichtag, Betrag jetzt und je Zeitraum, mit checksum; POST /organization/license/changes bestätigt sie mit dieser checksum. POST /organization/license/cycle-change/preview und POST /organization/license/cycle-change wechseln den Takt des Pakets zwischen monatlich und jährlich (continue für wählbare Jahresbausteine). Beim Bestätigen ist der Kopf Idempotency-Key Pflicht (422 an headers.idempotency-key), hat sich seit der Vorschau etwas geändert, kommt 409 preview-outdated. Nur der Tenant-Owner; das Bestätigen geht auch in der Lesephase. Neue Gründe (409): no-contract, package-ending, below-usage, change-pending, contract-error; 422 an body.cycle und body.quantity.

v1.289.0 · 30. Oktober 2026

  • Neu: die Lizenz der Organisation über die API (Lizenzmodell). GET /organization/license zeigt die Lizenz des Verbunds wie der Reiter „Lizenz“ (Paket mit Fassung, Takt, Preis, Zustand, Stichtag, Organisationen, Bausteine, je Organisation Wahl und Video-Stufe), nur für den Tenant-Owner. GET /organization/license/choices zeigt Wahlplätze, Wahl und Video-Stufe dieser Organisation (Tenant-Owner oder ORG_ADMIN). PUT /organization/license/choices wählt Module für die Wahlplätze, PUT /organization/license/video-tier ordnet eine gebuchte Video-Stufe zu; beides nur der Tenant-Owner, ein freier Platz gilt sofort, ein Wechsel ab dem nächsten Monatsstichtag, und beides geht auch in der Lesephase. Ohne Tenant-Owner 403 forbidden mit reason tenant-owner-required.

v1.288.0 · 30. Oktober 2026

  • Neu: Die Lesephase des Lizenzmodells gilt auch für die API und den API-MCP. Ist die Lizenz einer Organisation zu Ende, nimmt die API 30 Tage lang nur lesende Aufrufe an, danach ist auch das Schreiben gesperrt. Ein schreibender Aufruf bekommt dann 403 forbidden mit reason license-read-only, phase (read-only oder locked) und until (letzter Tag der Lesephase). Durch kommen nur Endpunkte mit einer Ausnahme der Phase; heute in der Lesephase POST /backups/runs und PUT /backups/password (Datensicherung als Export) sowie DELETE /affiliate-coupons/{id}, PATCH /affiliate-coupons/{id} mit active: false und DELETE /affiliate-tracking/webhook (Beenden). Nach der Lesephase geht keiner davon mehr durch. Lesende Aufrufe, auch POST …/validate und Vorschauen, ändern sich nicht; Automationen der Organisation laufen in der Lesephase weiter.

v1.287.0 · 30. Oktober 2026

  • Neu in GET /rooms/settings: recordingStorage mit dem Aufnahmespeicher der Organisation für Video-Aufzeichnungen im Live-Raum: tier (Video-Stufe, null ohne Stufe), usedBytes, limitBytes (null ohne Grenze) und state (free, warning ab 80 %, full ab 100 %, unlimited). Es zählen nur Video-Aufnahmen, deren Dokument besteht; der Ton-Mitschnitt für die Zusammenfassung zählt nicht. Ist der Speicher voll, startet keine neue Video-Aufzeichnung, Meetings laufen ohne weiter. PATCH /rooms/settings antwortet unverändert nur mit summary.
  • Geändertes Verhalten, Spec unverändert: PATCH /organization/members/{userId} mit clientAccess: true antwortet 403 forbidden mit reason: practice-read-only, wenn die Praxis der Organisation nur noch liest (Modul beendet oder Lesephase). Ein bestehendes Recht bleibt, Entziehen (false) geht immer.

v1.286.0 · 30. Oktober 2026

  • Geändertes Verhalten an den Endpunkten der Praxis (Regelwerke und Kataloge, Rechenverbindungen und -fälle, persönliche Pläne, Betreuungspläne, Betreuungen und Sitzungen, Biomarker-Profile und -Regelsätze), Spec unverändert: Ist das Praxis-Modul einer Organisation beendet oder die Organisation in der Lesephase (Lizenzmodell), bleiben lesende Endpunkte, das Anfordern des PDFs eines persönlichen Plans, das Rechnen ohne Speichern (POST /rulebooks/{id}/compute) und das Beenden erreichbar (POST /rule-cases/{id}/withdraw, DELETE /rule-connections/{id}, POST /personal-plans/{id}/withdraw, POST /care-plans/{id}/retire); vorher antworteten sie feature-not-available. Schreibende Endpunkte antworten dann 403 forbidden mit reason practice-read-only. Ohne Praxis bleibt es bei feature-not-available.

v1.285.0 · 30. Oktober 2026

  • Neu: PATCH /rule-connections/{id} mit creditAccountId (oder null) legt das Credit-Konto des Partners an einer Rechenverbindung fest, nur die rechnende Organisation, nur ORG_ADMIN. Ab dann bucht jede Freigabe eines persönlichen Plans aus einem Fall dieser Verbindung 1 Credit auf dieses Konto (Verbrauch), das Zurückziehen des Plans oder des Falls nimmt ihn zurück; ohne Konto wird nichts gebucht. Ein unbekanntes oder geschlossenes Konto ergibt 422 an body.creditAccountId (invalid_reference). GET /rule-connections trägt in asComputing neu creditAccount ({ id, program, customer } oder null).
  • Neuer Wert PERSONAL_PLAN in source der Credit-Buchungen (GET /credits/accounts/{id}): Verbrauch und Rücknahme aus einem persönlichen Plan, der an eine Partner-Organisation zugestellt wurde.

v1.284.0 · 30. Oktober 2026

  • Neu an den Betreuungsplan-Vorlagen: Bausteine. GET, POST, PUT /care-plans und POST /care-plans/validate tragen modules ([{ key, name }]) und an Phase und Sitzung moduleKey: Teile, die nur auf Empfehlung in eine Betreuung kommen. Eine Phase mit Baustein nimmt ihre Sitzungen mit; eine Sitzung bekommt einen eigenen Baustein nur in einer Phase ohne. Der Schlüssel (Kleinbuchstaben, Ziffern, Bindestrich) entsteht ohne Angabe aus dem Namen und bleibt über Fassungen, weil Regeln den Baustein über ihn empfehlen. Neue 422-Fehler an body.modules (too_big, required, duplicate) und an moduleKey von Phase oder Sitzung (invalid_reference).
  • Neu: Varianten je Sitzung, variants ([{ moduleKey, callGuideId, durationMinutes }], höchstens 5, je Baustein eine). Ist der Baustein beim Start gewählt, gelten Leitfaden und Dauer der Variante; die erste gewählte gewinnt. 422 an body.sessions.{n}.variants (invalid_value, required ohne Leitfaden und Dauer); ein fremder Leitfaden oder eine Dauer, die die Terminart nicht anbietet, kommen wie bei der Sitzung an callGuideId bzw. durationMinutes.
  • Geändert gegenüber 1.282.0: Speichern eines Entwurfs mit Bausteinen ohne modules bzw. mit Varianten, ohne dass eine Sitzung variants nennt, antwortet jetzt mit 422 required an body.modules bzw. body.sessions statt 409 rejected. Eine leere Liste modules entfernt alle Bausteine; eine Sitzung ohne variants verliert ihre Varianten, sobald eine andere Sitzung das Feld nennt.
  • Neu beim Start einer Betreuung (POST /care-enrollments): modules, die Schlüssel der gewählten Bausteine. Teile anderer Bausteine kommen nicht in die Betreuung, die Sitzungen werden neu gezählt; ohne Angabe keiner. Empfohlene nennt GET /clients/{id}/care-plan-suggestions. 422 an body.modules: invalid_reference für einen Schlüssel, der nicht zur Fassung gehört, too_small, wenn weniger als zwei Sitzungen blieben. Die Abschrift copy trägt modules (die gewählten) und an Phase und Sitzung moduleKey, an der Sitzung dazu variantModuleKey (Baustein, dessen Variante gilt); Varianten selbst stehen dort nicht.

v1.283.0 · 30. Oktober 2026

  • Neu an GET /rule-cases: retainUntil, das Ende der Aufbewahrungsfrist eines Falls bei der rechnenden Organisation: zehn Jahre nach seinem letzten Ereignis (Rechnen oder Zurückziehen), wie bei der Akte (§ 630f Abs. 3 BGB). Gelöscht wird nicht automatisch.

v1.282.0 · 30. Oktober 2026

  • Geändertes Verhalten an POST /care-plans und PUT /care-plans/{id} (Spec unverändert): Hat ein Entwurf Bausteine oder Varianten je Sitzung (in der Oberfläche angelegt), lehnt das Speichern ohne sie mit 409 conflict und reason rejected ab, statt sie still zu entfernen. Bausteine und Varianten in den Vorlagen-Endpunkten folgen in einer späteren Version; die Vorschläge tragen sie seit 1.281.0 (modules).

v1.281.0 · 30. Oktober 2026

  • Neu an GET /clients/{id}/care-plan-suggestions: whole (ob die ganze Vorlage empfohlen ist) und modules, die empfohlenen Bausteine der Vorlage mit key, name und sources. Ein Baustein ist ein Teil einer Vorlage (Phasen oder Sitzungen), der nur auf Empfehlung in eine Betreuung kommt; eine Vorlage erscheint auch, wenn nur ein Baustein darin empfohlen ist.

v1.280.0 · 29. Oktober 2026

  • Neu: Urteile über Hinweise aus Läufen anderer Organisationen gehen an die rechnende Organisation zurück, mit Grund und Name der Partner-Organisation, ohne den Namen der Person; nicht bei widerrufener Verbindung oder zurückgezogenem Fall. PUT /care-sessions/{id}/foreign-hints/{runId}/{rule} antwortet mit sent, foreignHints tragen judgementSent. Bei der rechnenden Organisation zählt GET /rulebooks/{id}/hint-stats sie mit (accurate/notAccurate über alle, fromPartners der Anteil der Partner); neu GET /rulebooks/{id}/hint-objections (Klientendaten, clients:read): die jüngsten Widersprüche je Regel mit Grund, by und fromPartner.

v1.279.0 · 29. Oktober 2026

  • Neu: Hinweise aus Läufen anderer Organisationen im Cockpit. GET /care-sessions/{id}/hints liefert foreignHints: je rechnender Organisation und Regelwerk der jüngste gültige Lauf an der Akte, mit runId, computedBy, rulebook, versionNumber, approvedBy, computedAt, reportId und denselben Feldern wie hints. PUT /care-sessions/{id}/foreign-hints/{runId}/{rule} speichert das Urteil (judgement, reason, runHash; nur eine Person, nie Automation oder MCP, 403 judgement-needs-person; ein zurückgezogener Lauf: 409 conflict mit reason run-withdrawn). Das Urteil bleibt in der eigenen Organisation.

v1.278.0 · 29. Oktober 2026

  • Neu: das PDF eines persönlichen Plans. POST /personal-plans/{id}/pdf fordert es an (202; nur für freigegebene oder zurückgezogene Pläne, ein Entwurf: 409 conflict mit reason not-released), GET /personal-plans/{id}/pdf liest den Stand (status: none, pending, ready, failed, dazu documentId); fertig mit einem signierten Link (url, filename, expiresAt, wenige Minuten gültig). Je Stand des Plans entsteht ein PDF; nach dem Zurückziehen meldet der Stand none, ein neues trägt den Vermerk. Klientendaten, Zugriffsprotokoll.

v1.277.0 · 29. Oktober 2026

  • Neu: persönliche Pläne aus dem Fall einer Partner-Organisation (Rechnen über die Grenze, /rule-cases). GET /rule-cases/{id}/personal-plans listet sie, POST /rule-cases/{id}/personal-plans legt einen Entwurf aus dem beim Fall gespeicherten Ergebnis an (language, title); ein zurückgezogener Fall: 409 conflict mit reason case-withdrawn. Mit POST /personal-plans/{id}/release geht eine unveränderliche Kopie in die Akte beim Partner; fehlt die Akte dort: 409 partner-record-missing.
  • Neu an Plänen: fromOrganization (Kopie aus einer anderen Organisation, deren Name; sonst null), fromCase (aus einem Fall angelegt) und am einzelnen Plan delivered (an den Partner zugestellt). POST /personal-plans/{id}/withdraw zieht eine zugestellte Kopie mit zurück; eine Kopie zieht nur die Quelle zurück (409 foreign-plan). Zieht die rechnende Organisation den Fall zurück (POST /rule-cases/{id}/withdraw), gelten auch seine Pläne nicht mehr.

v1.276.0 · 29. Oktober 2026

  • Neu: persönliche Pläne (Klientendaten, biomarkers:* und clients:*, Zugriffsprotokoll). POST /clients/{id}/personal-plans rechnet die wirksame Fassung eines Regelwerks (rulebookId, optional reportId) und legt einen Entwurf mit den Empfehlungen aus eigenen Katalogen und ihren Texten an (409 no-recommendation, professional-only); GET /clients/{id}/personal-plans, GET/PATCH/DELETE /personal-plans/{id} (Titel, coverNote, remove, texts; nur Entwurf, 409 not-draft). POST /personal-plans/{id}/release und …/withdraw nur durch eine Person mit dem Recht „Regeln genehmigen“, nie Automation oder MCP (403 release-needs-person, approve-right-missing); Freigabe nur ohne Lücken (409 plan-incomplete mit gaps). Hinweistext der Organisation: GET/PATCH /personal-plan-settings (Festlegen wie Freigeben).
  • Neu an den eigenen Katalogen: professionalOnly (nur für Fachpersonal) in GET/POST/PATCH /rulebook-catalogs…; Einträge solcher Kataloge erscheinen nie in einem persönlichen Plan.

v1.275.0 · 29. Oktober 2026

  • Neu: eigene Empfehlungs-Kataloge mit Texten. POST /rulebook-catalogs legt einen Katalog an (names, area: nutrition, exercise, sleep, mental, supplements, other; der Schlüssel entsteht aus dem ersten Namen und bleibt), GET /rulebook-catalogs/{key} liest ihn mit allen Einträgen und Texten, PATCH /rulebook-catalogs/{key} ändert Namen, Bereich, Reihenfolge oder archived. Einträge: POST /rulebook-catalogs/{key}/entries (names, texts je Sprache als HTML, beim Speichern gesäubert) und PATCH /rulebook-catalogs/{key}/entries/{entryKey}. Ein Name darf in einem Katalog nur einmal vorkommen (422 duplicate an body.names), zu viele Kataloge oder Einträge 409 too-many.
  • Geändert: GET /rulebook-catalogs nennt neben dem Katalog der Wege auch die eigenen Kataloge, die nicht archiviert sind (ohne archivierte Einträge). Eine Regel empfiehlt einen Eintrag wie einen Weg; ein Name aus mehreren Wörtern darf in der Formel auch ohne Anführungszeichen stehen (empfehlung(Schlaf; Ruhe und Atmung)).

v1.274.0 · 29. Oktober 2026

  • GET /clients/{id}/care-plan-suggestions nimmt jetzt auch die Wege aus Läufen anderer Organisationen (rule-runs, je rechnender Organisation und Regelwerk der jüngste), wenn ihr deren Betreuungsplan übernommen habt: Vorgeschlagen wird eure eigene Kopie. Neu je Quelle computedBy (Name der rechnenden Organisation, sonst null); rulebookId ist bei solchen Quellen null. Übernommen werden Betreuungspläne nur in der Oberfläche.

v1.273.0 · 29. Oktober 2026

  • Neu: Rechnen über die Grenze einer Organisation. GET /rule-connections, POST /rule-connections (eine Verbindung mit den eigenen Regelwerken anlegen, der Code rech_… kommt einmal zurück und ist sieben Tage einlösbar), POST /rule-connections/redeem (Code einer anderen Organisation einlösen, legalBasisConfirmed: true bestätigt die Rechtsgrundlage) und DELETE /rule-connections/{id}. Anlegen, Einlösen und Widerrufen nur ORG_ADMIN; Anlegen und Einlösen nur eine Person, nie eine Automation und nie über den MCP (403 forbidden mit reason connection-needs-person).
  • Neu: POST /clients/{id}/rule-runs lässt über eine aktive Verbindung bei der anderen Organisation rechnen: Es reisen nur die Werte, die die wirksame Fassung des Regelwerks liest, dazu Name, Geburtsdatum, Alter und Geschlecht; nie aus einer Automation (403 request-needs-person). Zurück kommt ein Lauf ohne Formeln: GET /clients/{id}/rule-runs, GET /rule-runs/{id} (Ergebnisobjekt wie bei compute, Regeln mit Namen, Einheit, Gruppen und Hinweis). Die rechnende Organisation sieht ihre Fälle unter GET /rule-cases und zieht einen mit POST /rule-cases/{id}/withdraw zurück (Recht „Regeln genehmigen“, nur eine Person); der Lauf beim Partner trägt dann status: withdrawn.

v1.272.0 · 29. Oktober 2026

  • GET /rulebook-sources nennt jetzt auch Raster und Wiederholgruppen der Bögen an der Akte: je Zelle eines Rasters anamnese:<Block>.<Zeile>.<Spalte> (mit nur einer Spalte anamnese:<Block>.<Zeile>), je Auswahl-Spalte einer Wiederholgruppe eine Menge anamnese:<Block>.<Spalte> über alle Zeilen und anamnese:<Block>.anzahl. POST /rulebooks/{id}/compute liest sie aus der jüngsten Einreichung, die den Block beantwortet hat, mit Korrekturen.
  • Neu: GET /rulebook-catalogs mit den Katalogen, aus denen Regeln Empfehlungen geben, heute der Katalog der Wege (weg: die Betreuungsplan-Vorlagen, Schlüssel ist die erste Fassung einer Vorlage). Neu: GET /clients/{id}/care-plan-suggestions (careplans:read und clients:read, Klientendaten, Zugriffsprotokoll) mit den Wegen, die die genehmigten Regelwerke für einen Klienten vorschlagen, je mit den Regeln und der jüngsten freigegebenen Fassung (plan). Ein Vorschlag startet nichts; gestartet wird mit POST /care-enrollments.

v1.271.0 · 29. Oktober 2026

  • Hinweise im Cockpit: Jede Regel in den Antworten unter /rulebooks trägt hint ({ color, action } mit color red, gold oder grey, sonst null). Beim Speichern (PUT /rulebooks/{id}/draft/rules/{key}, POST /rulebooks/{id}/draft/validate) setzt hint den Hinweis, null nimmt ihn weg, ohne Angabe bleibt er. Nur eine Regel, die ja oder nein ergibt, kann ein Hinweis sein (422 auf body.hint); der Hinweis gehört zur Prüfsumme. Neu: GET /rulebooks/{id}/hint-stats mit den Urteilen der Coaches je Regel (accurate, notAccurate).
  • Neu im Bereich careplans: GET /care-plans/{id}/rulebooks, POST /care-plans/{id}/rulebooks (Regelwerk verknüpfen, nur im Entwurf einer eigenen Vorlage, sonst 409 plan-not-editable), PATCH /care-plans/{id}/rulebooks/{rulebookId} (active, immer) und DELETE /care-plans/{id}/rulebooks/{rulebookId}. GET /care-sessions/{id}/hints liefert die Hinweise einer Sitzung (Rot, Gold, Grau, state applies oder cannot-assess mit missing, Urteil, runHash; clients:read, Zugriffsprotokoll). PUT /care-sessions/{id}/hints/{versionId}/{rule} speichert das Urteil (accurate, oder not-accurate mit reason), nur durch eine Person: nie eine Automation, nie ein KI-Agent über den MCP (403 forbidden mit reason judgement-needs-person).

v1.270.0 · 29. Oktober 2026

  • GET /rulebook-sources nennt neben Laborwerten und Angaben zur Person jetzt auch die Anamnese aus den Feldern der Akte (anamnese:<Schlüssel des Feldes>, bei Messwerten mit mehreren Teilen anamnese:<Schlüssel>.<Teil>) und den Stand einer Betreuung (plan:sitzung, plan:tag, plan:phase). Regeln dürfen sie lesen. POST /rulebooks/{id}/compute liest die Anamnese mit; den Stand einer Betreuung kennt er nicht, weil er ohne Sitzung rechnet: Regeln, die ihn brauchen, ergeben dort „unbekannt“ (unknown).
  • Geändert: callMinutes in GET /affiliates/activity zählt nur noch die Dauer von Gesprächen: Telefonate mit einer fertigen Gesprächsnotiz, die nicht nur eine Mailbox festhält, oder mit einem Leitfaden samt Ergebnis, und angenommene Telefonate ohne Notiz ab 30 Sekunden, die keine Mailbox sind. Bisher zählte die Dauer jedes angenommenen Telefonats, auch einer Mailbox; die Werte können deshalb kleiner ausfallen. calls ist unverändert.
  • Geändert: PATCH /organization lehnt einen Wechsel von type auf BUSINESS oder HOLDING mit 409 conflict und reason: organization-limit ab, wenn das Lizenzpaket keinen freien Platz für eine weitere Geschäfts- oder Holding-Organisation hat. Das gilt nur für Pakete mit festgelegter Zahl an Organisationen; bestehende Lizenzen ohne diese Zahl sind nicht betroffen.

v1.269.0 · 29. Oktober 2026

  • Neu: Regelwerke der Regelsprache unter /rulebooks (biomarkers:read, biomarkers:write), dieselben wie im Bereich „Regeln“ der Anwendung. Lesen und Pflegen: GET /rulebooks, GET /rulebooks/{id} (mit ?version= eine bestimmte Fassung), POST /rulebooks, PATCH /rulebooks/{id}, DELETE /rulebooks/{id} und GET /rulebook-sources (was Regeln lesen können: Laborwerte und Angaben zur Person, mit Namen und Einheiten). Regeln im Entwurf: PUT /rulebooks/{id}/draft/rules/{key} als Formel (formula, in der Sprache der Anfrage, wie in der Formelzeile) oder als Baum (expression), POST /rulebooks/{id}/draft/validate als Probelauf und DELETE /rulebooks/{id}/draft/rules/{key}. Jede Regel kommt als Formel in drei Sprachen und als Baum zurück. Fassungen: POST /rulebooks/{id}/versions (Entwurf als Kopie der wirksamen), DELETE /rulebooks/{id}/draft und POST /rulebooks/{id}/draft/approve.
  • Genehmigen (POST /rulebooks/{id}/draft/approve) darf nur eine Person mit dem Recht „Regeln“ der Organisation (sonst 403 forbidden mit reason approve-right-missing), nie eine Automation und nie ein KI-Agent über den MCP (403 forbidden mit reason approve-needs-person): Die Genehmigung ist die Entscheidung einer Ärztin oder eines Arztes. Eine Fassung mit Fehlern antwortet 422, eine ohne Regeln 409 version-empty. Beim Genehmigen wird eine Prüfsumme über die Regeln gespeichert (checksum).
  • Neu: POST /rulebooks/{id}/compute mit { clientId, rules? } (biomarkers:read und clients:read, dazu die Freischaltung der Klientendaten; der Zugriff steht im Zugriffsprotokoll) rechnet die wirksame Fassung mit den freigegebenen Laborwerten des Klienten und liefert das Ergebnisobjekt: values, inputs, groups, trace, die Fassung mit checksum und Genehmigung sowie hash. Ohne genehmigte Fassung 409 no-effective-version; passen die Regeln nicht mehr zu ihrer Prüfsumme, 409 checksum-mismatch, und es wird nicht gerechnet.
  • Veraltet: die acht Endpunkte unter /biomarker-rule-sets (biomarkers.listRuleSets, getRuleSet, createRuleSet, validateRules, replaceRules, deleteRuleSet, confirmRuleSet, unconfirmRuleSet). Sie antworten bis zum 31.12.2026 weiter, mit den Köpfen Deprecation und Sunset, und entfallen danach. Im API-MCP sind sie ab dieser Version ausgeblendet. Ihre Regelwerke werden nicht übertragen; legen Sie Regeln unter /rulebooks an.

v1.268.0 · 27. Oktober 2026

  • Behoben: POST /email-campaigns/{id}/report/fetch-reasons ordnet jetzt auch Rückläufer zu, die SendGrid in derselben Sekunde wie den Versand meldet (etwa sofortige Abweisungen von Gmail). SendGrid führt den Zeitpunkt in den Sperrlisten in ganzen Sekunden; solche Einträge galten bisher als vor dem Versand und zählten unter withoutEntry.

v1.267.0 · 27. Oktober 2026

  • Geändert: POST /email-campaigns/{id}/report/fetch-reasons liest nach Bounces und Blocks auch SendGrids Liste Invalid Emails, aber nur für Rückläufer, die noch keinen Grund und keinen Eintrag in Bounces haben; ein Treffer wird wie ein Rückläufer gespeichert (type bounce, source suppression-list). Neu in der Antwort: read.invalidEmails. Ein eingeschränkter Schlüssel braucht dafür suppression.invalid_emails.read; fehlt das Recht oder antwortet SendGrid mit einem Fehler, ist read.invalidEmails null (statt 0 für „gelesen und leer“ oder „nicht nötig“), die Gründe aus Bounces und Blocks bleiben erhalten und diese Mails zählen unter withoutEntry.

v1.266.0 · 27. Oktober 2026

  • Neu: Grundeinstellung des Finders GET /finder/settings (finder:read: enabled, brandId, taxonomyCount) und PATCH /finder/settings (finder:write, Rumpf { brandId }, null für das Standard-Board der Organisation). Ändern nur Admins der Organisation (sonst 403 forbidden); ist der Finder nicht eingeschaltet, 403 feature-not-available; ein Board, das es in der Organisation nicht gibt, 422 validation-failed mit invalid_reference an body.brandId. Die Boards liefert GET /sites/brands. Neues Recht finder:write: Erweitern Sie Ihre Schlüssel, wenn Sie die Einstellung setzen wollen.

v1.265.0 · 27. Oktober 2026

  • Neu: Kontakte zusammenführen POST /contacts/{id}/merge (contacts:write). Der Kontakt im Pfad bleibt, die Kontakte in mergeContactIds (1 bis 20, gleicher Typ) werden mit allen Verweisen auf ihn umgehängt und gelöscht; endgültig. fieldSources nennt je Feld die Kennung des Beteiligten, dessen Wert gilt; Tags werden vereinigt. Antwort { contact, mergedContactIds, reassignedReferences }. 409 mit reason type-mismatch, bookings-on-multiple oder je Sperre (client-records-on-multiple, practitioner-profiles-on-multiple, sales-profiles-on-multiple, company-profiles-on-multiple, marketplace-subscriptions-on-multiple, calendars-on-multiple). Derselbe Ablauf wie in der Anwendung.
  • Neu: Ereignis contacts.contact.merged, einmal je Zusammenführung, auch aus der Anwendung, mit dem bleibenden Kontakt (contact, Form wie bei contacts.contact.updated), mergedContactIds und reassignedReferences. Für die gelöschten Kontakte kommt kein contacts.contact.deleted und für den bleibenden kein contacts.contact.updated: Hängen Sie Ihre Datensätze der gelöschten Kennungen auf den bleibenden Kontakt um. Bisher meldete das Zusammenführen kein Ereignis.
  • Geändert: Die beiden 409 bei DELETE /contacts/{id} (in-use, client-record-retained) nennen im detail den Weg POST /contacts/{id}/merge.
  • Geändert: contacts.contact.created kommt jetzt auch für Behandler, die der Longevity-Finder beim Prüfen eines Zertifikats neu anlegt, und für Profile, die einzeln aus einem anderen Verzeichnis übernommen werden. Damit meldet jede Neuanlage eines Kontakts, gleich auf welchem Weg; ausgenommen bleiben Massen-Importe und Massen-Übernahmen (1.263.0) sowie Testfälle, die claritos zum Üben in eine Organisation übergibt.

v1.264.0 · 27. Oktober 2026

  • Neu: Bericht einer Kampagne GET /email-campaigns/{id}/report mit Zustellung, Gründen der Rückläufer (SMTP-Code, Kategorie von SendGrid, Antwort des Servers ohne E-Mail-Adressen), Tranchen, Anbietern, Domains, Folgen (Sperrliste, Widerrufe ohne die Rücknahme der Einwilligungen eines Imports), Antworten, Klicks je Link, Öffnungen und gebuchten Terminen; dazu das Anhalten mit der Meldung von SendGrid (run.providerMessage, run.haltMeaning). Abrufe, die vermutlich kein Mensch waren (Sicherheitsfilter, Vorabrufe), zählen getrennt (botClicks, prefetches).
  • Neu: GET /email-campaigns/{id}/recipients (Seiten über den Cursor, Filter group, batch, domain, provider, reasonType, smtpCode, reasonCategory, search, updatedSince) und GET /email-campaigns/{id}/recipients/{recipientId} mit dem Verlauf aller Meldungen, Sperre, Einwilligung, Antworten (nur Gespräch, Zeit, Stimmung), Klicks, Öffnungen und Terminen (appointmentId, appointmentTypeId, appointmentTypeName in der Hauptsprache der Organisation, status wie bei GET /appointments). Beide brauchen zusätzlich contacts:read.
  • Neu: POST /email-campaigns/{id}/report/fetch-reasons holt Gründe der Rückläufer aus SendGrids Sperrlisten nach (bei SendGrid wird nichts geändert; wiederholbar); 409 mit Grund sendgrid-suppression-forbidden, wenn der Schlüssel die Listen nicht lesen darf. Neu: GET/PUT /email-campaigns/tracking mit clicksPerPerson (Klicks je Person oder nur je Link, Schalter der Organisation; ändern nur Admins).
  • Neu: Ereignisse campaigns.email.clicked und campaigns.email.opened, nur für Abrufe, die vermutlich von Menschen stammen; gesendet rund acht Sekunden nach dem Abruf, damit ein Sicherheitsfilter, der alle Links einer Mail auf einmal abruft, vorher erkannt ist. occurrence sagt first beim ersten Klick eines Empfängers auf diesen Link bzw. seiner ersten Öffnung, sonst repeat. contactId, recipientId und occurrence stehen nur darin, wenn die Organisation Klicks je Person zählt (sonst null); zählt sie nur je Link, filtert claritos Programme ohne Browser, zu frühe Abrufe und HEAD, aber keine Serien, weil kein Abruf eine Person trägt. Beide sind Auslöser der Automationen, mit Filter auf eine Kampagne und auf occurrence. Geändert: Kampagnen haben das Feld measureOpens (Öffnungen mit eigenem Bild messen, Vorgabe aus), lesbar und beim Anlegen und Ändern setzbar.

v1.263.0 · 27. Oktober 2026

  • Geändert: contacts.contact.created kommt jetzt auch bei diesen Neuanlagen: ein neuer Käufer aus einem Checkout (auch bei der Einrichtung einer Lizenz), im Affiliate-Programm (Freigabe einer Bewerbung, Closer-Service, Team im Partner-Portal, eine weitere Person aus dem Bewerbungsformular, ein übernommener Interessent), eine aus einem Brief übernommene Ansprechperson, ein neuer Geschäftspartner bei der Anlage eines Belegs und Angehörige, die ein Kunde im Portal anlegt. Trägt der neue Kontakt Tags, kommt je Tag contacts.tag.added wie bei POST /contacts. Wird ein vorhandener Kontakt verwendet, kommt kein Ereignis.
  • Geändert: Massen-Übernahmen senden keine Ereignisse mehr, weder contacts.contact.created noch contacts.tag.added: die Übernahme der Stripe-Kunden, der DATEV-Stammdaten und der Partnerliste des Portals in der Buchhaltung sowie der Stammdaten-Import der Credits, auch über POST /credits/import-profiles/{id}/master-data. Bisher kam je neuem Kontakt ein Ereignis, und ein Lauf legt oft Hunderte an. Das gilt auch für den Ansprechpartner, den eine solche Übernahme anlegt, wenn aus einer Person mit USt-IdNr. ein Unternehmen wird. Teilt claritos dagegen einen schon vorhandenen Kontakt so auf (Zuordnung zu DATEV, geänderte USt-IdNr. in der Partnerliste, Personenunternehmen ordnen, Kontaktformular), kommt für den neuen Ansprechpartner weiterhin contacts.contact.created. Wer diese Kontakte braucht, liest sie nach dem Lauf über GET /contacts.

v1.262.0 · 27. Oktober 2026

  • Geändert: contacts.contact.created kommt jetzt auch, wenn ein Formular einen neuen Kontakt anlegt: Einsendungen über einen Formular-Link (/f/…), ein Funnel-Formular oder POST /forms/{id}/responses, ein persönlicher Link (POST /forms/{id}/personal-links) sowie Firmen- und Vertriebler-Profile. Bisher meldeten nur Anlagen von Hand, über POST /contacts und aus Dokumenten. Findet das Formular einen vorhandenen Kontakt, kommt kein Ereignis. Die Regel lautet: Jede Neuanlage meldet, Massen-Importe nicht; weitere Anlagewege folgen und stehen dann hier.

v1.261.0 · 27. Oktober 2026

  • Neu: Lizenz-Logo eines Formulars in zwei Schritten, POST /forms/{id}/license-logo/upload (signierte Adresse) und POST /forms/{id}/license-logo/confirm (erst danach zeigt das Formular das Logo; Datei noch nicht da: 422 an body.storageKey), entfernen mit DELETE /forms/{id}/license-logo; GET /forms/{id} trägt licenseLogoUrl. POST /forms/{id}/personal-links legt aus den Angaben einer Person (values mit std:-Feldern, optional documentId) den Kontakt an oder findet ihn und liefert einen vorausgefüllten Link für sieben Tage (url, contactId, validUntil; 201, braucht forms:write und contacts:write). Neuer Grund target-not-supported (409) für Formulare, deren Ziel keinen persönlichen Link kennt. Archivierte Formulare: 409 archived bei allen vier.

v1.260.0 · 27. Oktober 2026

  • Neu: PATCH /forms/{id} ändert die Einstellungen eines Formulars wie der Baukasten (Name, Anrede, öffentlicher Link, Portal, consentMode, Anzeige, Adressfinder, Lizenz-Hinweis, Abschluss); Kurzname, Ziel, Seiten und Einwilligungen setzt weiter PUT (mitgeschickt 422 invalid_combination); ein archiviertes Formular ergibt 409 archived. GET /forms/{id}/share-link liest, POST /forms/{id}/share-link legt den Teilen-Link der Organisation an (wiederholbar; neuer Grund public-access-disabled, 409). GET /forms/{id} und die Antworten von POST /forms, PUT /forms/{id} und dem Einfügen einer Vorlage tragen die Einstellungen mit: showProgress, showSummary, showFieldLabels, showClientHeader, reminderService, recognitionCard, translateResponses, thirdPartyMode, addressFinderMode, addressFinderPlaceholder, licenseLabel, completion. Geändert: publicUrl in GET /forms und GET /forms/{id} ist nur noch der Link der Organisation; bisher konnte dort der Werbe-Link eines Vermittlers stehen, über den jede Einsendung diesem Vermittler zugeschrieben wurde. Ohne Link der Organisation steht dort null.

v1.259.0 · 26. Oktober 2026

  • Neue Ereignisse contacts.websiteAnalysis.completed und contacts.websiteAnalysis.failed, genau einmal je Lauf der Webseiten-Analyse, auch für Läufe aus Portal, Leitfaden, Meeting und API. Die Nutzlast websiteAnalysis trägt nur Kennungen und Zustand: contactId (angefragt), targetContactId (mit dem Ergebnis), topicId, topicName, language, source (app, portal, callGuide, meeting, api), userId, partnerContactId, affiliateId, startedAt, finishedAt; bei completed dazu pagesRead und unverifiedQuotes, bei failed der feste reason wie failure.reason im GET. Kein Seiten- oder Ergebnistext: das Ergebnis liefert GET /contacts/{id}/website-analysis. In Automationen als Auslöser mit Filtern auf Weg und Grund.

v1.258.2 · 26. Oktober 2026

  • Geändert: Die Webseiten-Analyse hat keinen Freigabe-Schalter mehr. enabled entfällt in den Antworten von GET/POST/PUT /contacts/{id}/website-analysis und GET/PUT /website-analysis/settings, der Start antwortet nicht mehr 403 feature-not-available. 1.258.0 und 1.258.1 waren nie in Production.

v1.258.1 · 26. Oktober 2026

  • Geändert: POST /contacts/{id}/website-analysis nimmt ohne language die Sprache der Organisation (wenn de, en oder ru, sonst de) und antwortet 403 feature-not-available vor jeder anderen Prüfung, solange die Funktion in der Umgebung nicht freigegeben ist.

v1.258.0 · 26. Oktober 2026

  • Neu: Webseiten-Analyse am Kontakt. GET /contacts/{id}/website-analysis (contacts.getWebsiteAnalysis) liest Gesprächsanlässe aus der Webseite des Kontakts (current als HTML mit gelesenen Seiten, running, failure, history, dailyLimit); beim Interessenten eines Partners liegt das Ergebnis am Firmenkontakt (targetContactId). POST (contacts.startWebsiteAnalysis, 202) startet sie mit topicId und language, PUT (contacts.updateWebsiteAnalysis) speichert einen Stand von Hand; beides nur mit handelnder Person. Fehler: 422 precondition-failed mit reason: no-website oder daily-limit-reached, 409 analysis-running, 403 feature-not-available, solange die Funktion in der Umgebung nicht freigegeben ist.
  • Neu: GET/PUT /website-analysis/topics (contacts.listWebsiteTopics, contacts.setWebsiteTopics) liest und ersetzt die Themen-Prompts der Organisation oder mit campaignId die einer Affiliate-Kampagne (name, prompt, isDefault, höchstens 20, eine Vorgabe). GET/PUT /website-analysis/settings (contacts.getWebsiteAnalysisSettings, contacts.setWebsiteAnalysisSettings) liest und setzt die Tagesgrenze (dailyLimit 0 bis 500). Ändern nur ORG_ADMIN.

v1.257.0 · 26. Oktober 2026

  • Gesprächsleitfäden: nextCallGuideId an Punkten und Antworten im content von /call-guides (lesen und schreiben), „Weiter mit Leitfaden …“. Der Ausgang wird damit zum Ende: Der Lauf schliesst mit seinem Ergebnis, der Ziel-Leitfaden beginnt im selben Gespräch. Ein next ungleich null daneben ergibt 422 invalid_combination an diesem Ausgang; ein Ziel, das kein aktiver Leitfaden der Organisation ist, 422 sprung-ziel-unbekannt.
  • Ereignis callguides.run.completed: guideRun.previousRunId (der Lauf, aus dem mit „Weiter mit Leitfaden …“ hierher gesprungen wurde, sonst null) und guideRun.nextGuideId (der Ziel-Leitfaden, wenn der Lauf mit einem Sprung endet, sonst null).

v1.256.0 · 26. Oktober 2026

  • Eigene Felder: GET /organization/custom-fields (mit Ordnern), POST /organization/custom-fields, PATCH /organization/custom-fields/{id}, POST /organization/custom-fields/{id}/archive und /unarchive. Lesen mit organization:read, Schreiben mit organization:write und ORG_ADMIN. Kurzname, Typ und Entitäten sind nach dem Anlegen fest (422 immutable); Auswahlen tragen einen festen key, Umbenennen über den Schlüssel lässt gespeicherte Werte unberührt. Neue Gründe custom-field-slug-taken und system-field (beide 409).

v1.255.0 · 26. Oktober 2026

  • Pipelines (PI.37): Phasen tragen partnerRights (view, moveIn, moveOut, edit, delete), lesbar und schreibbar über die Phasen-Endpunkte (nur vollständig; ohne view kein anderes Recht). Bei einer Abschluss-Phase heisst moveIn abschliessen und moveOut wieder aufnehmen. partnerVisibility bleibt lesbar (aus den Rechten abgeleitet) und schreibbar (wird in Rechte überführt, delete nie); partnerRights geht vor.

v1.254.0 · 26. Oktober 2026

  • Pipelines (PI.31, Anrufliste): callList.businessOnly (nur Unternehmer und Freiberufler, B2B; der Dialer fragt in dieser Pipeline nie nach einer Einwilligung, ein Widerruf sperrt weiter), schreibbar über PATCH /pipelines/{id}. Jede Änderung wird protokolliert; callList.businessOnlyChange nennt die letzte (at, via, userId, nur lesbar).

v1.253.0 · 26. Oktober 2026

  • Pipelines (PI.28, Anrufliste): Phasen tragen onCallList (Karten der offenen Phase stehen auf der Anrufliste), Pipelines callList mit busy (followUp mit busyFollowUpMinutes oder end), noAnswerRetryMinutes, ringSeconds, hours (days 1–7, from, to) und firstCallStageId; schreibbar über PATCH /pipelines/{id} (callList, Teilangaben) und an den Phasen (onCallList). Die Liste selbst wählt der Dialer im Portal bzw. CRM.

v1.252.0 · 25. Oktober 2026

  • Pipelines (PI.27): neu GET /pipelines/lead-quality (from, to, optional pipelineId): Einträge der Vertriebs-Pipelines, die im Zeitraum angelegt wurden, je Quelle (kind form/funnel/existing mit sourceId und name, sonst via) und je Kampagne (utmCampaign, utmSource) mit leads, open, parked, won, lost, unqualified und den Anteilen unqualifiedShare, wonShare (0 bis 1 an allen Leads der Gruppe).

v1.251.0 · 25. Oktober 2026

  • Pipelines (PI.26): Einträge tragen leadSource (form, funnel oder existing für den Bestand, mit sourceId und utm aus dem Funnel-Besuch: source, medium, campaign), ab jetzt für neue Einträge. Neu GET/POST /pipelines/{id}/backfill: Nachzug der Pflicht-Pipeline, übernimmt Interessenten der freigegebenen Häuser ohne offenen oder geparkten Eintrag in die Eingangsphase (running/finished/failed, candidates, created, failed); startet auch von selbst beim Einschalten von couplings.prospectsRequired. Ohne eingeschaltete Pflicht precondition-failed (prospects-not-required), bei laufendem Nachzug conflict.

v1.250.0 · 25. Oktober 2026

  • Gesprächsleitfäden (Telefonie TW.48b): notReached[].cardStatusEvent kennt absence (Abwesenheitsansage); die Vorlage der Situationen setzt es an der Abwesenheit. Die Werte folgen den Auslösern des Kartenstatus der Pipelines (PI.22b).

v1.249.0 · 25. Oktober 2026

  • Pipelines (PI.22b): neuer Auslöser des Kartenstatus absence (Anruf: Abwesenheitsansage) neben busy, noAnswer, voicemail und invalidNumber, an Kartenstatus (trigger), im Ereignis pipelines.entry.cardStatusChanged und als situation von POST /pipelines/entries/{id}/outcome (ein Versuch, kein Phasenwechsel).

v1.248.0 · 25. Oktober 2026

  • Pipelines, Vertriebsablauf (PI.25): Phasen nennen appointmentTypeIds (Terminarten) und role (preSetter, setter, closer). Wird ein Termin einer genannten Art für den Kontakt eines offenen Eintrags gebucht, umgebucht, abgesagt oder nicht wahrgenommen, folgt der Kartenstatus; bei einer Buchung wird der Gastgeber zuständig und hält die Rolle der Phase, wer bis dahin zuständig war, die Rolle davor. Neue Anforderungsart appointment mit appointmentTypeId (null = irgendeine). Einträge tragen bookedAppointmentTypeIds und roles (Person, Name, Termin). Eine fremde Terminart ergibt invalid_reference.

v1.247.0 · 25. Oktober 2026

  • Gesprächsleitfäden (/call-guides, lesen und schreiben): content.results[].pipelineEffect mit pipelineId, stageId, reasonId, packageId, cardStatusId ist die Wirkung des Ergebnisses in der Pipeline beim Abschliessen. content.notReached[].cardStatusEvent (busy, noAnswer, voicemail, invalidNumber, dieselben Werte wie trigger in pipelines.entry.cardStatusChanged) ist das Ereignis, mit dem eine Situation den Kartenstatus setzt. Bisher zeigte die API beide nicht, und ein PATCH mit content verlor sie.

v1.246.0 · 25. Oktober 2026

  • Pipelines, Vertriebsablauf (PI.24): POST /pipelines/entries/{id}/outcome hält ein Ergebnis an der Karte fest: Kartenstatus, Phase mit Grund (dieselben Anforderungen wie moveEntry), Paket und Wiedervorlage in einem Aufruf, oder notReached mit situation (busy, noAnswer, voicemail, invalidNumber): ein Versuch, nie ein Phasenwechsel. Einträge tragen attemptsInStage und lastAttemptAt (jeder Phasenwechsel setzt die Versuche auf 0). Neuer Weg guide in via (Ergebnis eines Leitfadens) im Verlauf und in pipelines.entry.stageChanged/cardStatusChanged.

v1.245.0 · 25. Oktober 2026

  • Neu: GET /contacts/{id}/phone-consent und PUT /contacts/{id}/phone-consent (contacts.getPhoneConsent, contacts.setPhoneConsent): die Einwilligung des Kontakts in Anrufe, getrennt von E-Mail und SMS. Antwort mit state (granted, revoked, none), since, number, callable (yes wählen: Unternehmen oder dokumentierte Einwilligung; ask vorher fragen: Verbraucher ohne Einwilligung; no nicht wählen: widerrufen, auch bei Unternehmen) und history mit reason und by (userId oder contactId, name). PUT nimmt granted, reason (Pflicht, höchstens 2.000 Zeichen) und optional number, nur mit handelnder Person (no-acting-user), ein Nicht-Mitglied bekommt 403.
  • Neu: GET /contacts/{id}/reminder-service (contacts.getReminderService) und POST /contacts/{id}/reminder-service/unsubscribe (contacts.unsubscribeReminders): ob der Kontakt Terminerinnerungen per E-Mail und SMS bekommen darf (email, sms je mit state, value, since), und das Abbestellen beider Kanäle, wiederholbar, nur mit handelnder Person, die Mitglied ist.

v1.244.0 · 25. Oktober 2026

  • Automationen: Der Auslöser pipelines.entry.cardStatusChanged hat den Filter „Kartenstatus: eines von“, im Katalog (GET /automation-catalog) als Pfad toCardStatus.id mit kind pipelineCardStatus. Gespeichert wird er wie pipelineStage als Liste von Kennungen (der neue Kartenstatus); Kennungen, die nicht zur Organisation oder zu den gewählten Pipelines gehören, weist das Speichern ab.

v1.243.0 · 25. Oktober 2026

  • Gesprächsleitfäden: (1) callguides.run.completed kommt jetzt beim ersten ausdrücklichen Abschluss eines Laufs („Gespräch abschliessen“) mit dem Ergebnis, das die Person wählt (resultId/resultName), nicht mehr von selbst, sobald der Hauptweg am Ende ist; weiterhin einmal je Lauf, Wiederöffnen und erneutes Abschliessen melden nichts. (2) Neu content.notReached an /call-guides (lesen und schreiben): Situationen „Nicht erreicht“ mit id, name und suggestion (hours, businessDays, manual, none). Ein Abschluss mit einer solchen Situation meldet kein callguides.run.completed, ein späterer Abschluss mit Ergebnis meldet einmal. Bisher zeigte die API die Liste nicht, und ein PATCH mit content verlor sie. (3) Eine Checkout-Aktion darf links: [] tragen: Dann gilt nur der Checkout-Link des Pipeline-Eintrags; trägt der Eintrag einen, gewinnt er auch gegen eigene Links der Aktion. Unvollständig ist eine Checkout-Aktion nur noch ohne templateId.

v1.242.0 · 25. Oktober 2026

  • SendGrid-Rückmeldungen (SV.198): POST /sendgrid/events legt je SendGrid-Konto nur noch EINEN Webhook an. Steht im Konto schon einer von claritos (etwa von einer anderen Organisation am selben Konto), hängt sich die Verbindung daran; weitere werden zusammengeführt. Neue Gründe in 422 precondition-failed: sendgrid-webhook-limit (der SendGrid-Tarif erlaubt keinen weiteren Webhook) und sendgrid-webhook-forbidden (SendGrid hat den Schlüssel für Webhooks abgewiesen); beide kamen bisher als sendgrid-events-failed, das jetzt den Grund von SendGrid im detail trägt. checkError kann neu sendgridVerbindung.fehler.ereignisseTarif oder sendgridVerbindung.fehler.ereignisseRecht sein. Meldungen gehen nur noch an die Organisation, deren Mail sie betreffen: Rückläufer einer anderen Organisation am selben Konto sperren keine Adresse mehr.

v1.241.0 · 25. Oktober 2026

  • Pipelines, Vertriebsablauf (PI.23): Pakete. Pipelines tragen packages (Name, Artikel, Checkout-Link, default), PUT /pipelines/{id}/packages speichert die ganze Liste (höchstens eine Vorgabe, Fehlende archiviert, nur Org-Admins). Einträge tragen packageId, packageName und checkoutLinkId; packageId setzt man in POST /pipelines/entries, PATCH /pipelines/entries/{id} und moveEntry (Artikel und Netto-Wert aus dem Paket, ausser valueCents steht im selben Aufruf). Neue Anforderungsart package (Pfad body.packageId). Die Vorgabe wird nicht von selbst an neue Einträge geschrieben.
  • Pipelines, Support (PI.19b): Eine freigegebene SLA-Gutschrift geht an die Faktura und steht als „Nachlass“ auf der nächsten Abo-Folgerechnung oder dem nächsten Entwurf von Hand. Neuer slaCredit.status scheduled mit scheduledAt; scheitert die Übergabe, bleibt released mit handoverError, und POST …/sla-credit/release versucht es erneut.

v1.240.0 · 23. Oktober 2026

  • Pipelines, Vertriebsablauf (PI.22): Kartenstatus, der Stand der Dinge an der Karte unabhängig von der Phase. Pipelines tragen cardStatuses (Name, Farbe, Reihenfolge, trigger), Einträge cardStatus und cardStatusSince. Neu: PUT /pipelines/{id}/card-statuses speichert die ganze Liste (Fehlende werden archiviert, nur Org-Admins), GET /pipelines/{id}/card-statuses/report liefert Anzahl offener Einträge und Zeit je Phase und Kartenstatus sowie die Wechsel im Zeitraum. PATCH /pipelines/entries/{id} setzt cardStatusId (null = ohne), GET /pipelines/entries filtert mit cardStatusId (none = ohne). Neues Ereignis pipelines.entry.cardStatusChanged mit fromCardStatus, toCardStatus, trigger und via; die Anlage meldet keines, created trägt den Status schon.

v1.239.0 · 23. Oktober 2026

  • Neu: POST /invoices/{id}/collect zieht eine offene Abo-Rechnung jetzt von der Karte oder dem Lastschrift-Mandat des Abos ein, statt auf den täglichen Lauf zu warten. Antwort result: charged (Karte belastet, Bestätigung per Webhook) oder submitted (Lastschrift eingereicht, bezahlt mit dem Eingang). 409 mit reason not-collectable, skipped oder collection-failed.

v1.238.0 · 23. Oktober 2026

  • Neu: Sitzung einer Betreuung abschliessen (Praxis BP.3a). POST /care-sessions/{id}/complete schliesst die Sitzung und ihren Leitfaden in einem Zug: erst den Lauf mit guide.outcomeId (Pflicht, wenn der Leitfaden Ergebnisse hat) und guide.reasons (Begründung je offenem Pflichtschritt; fehlt eine, 422 mit Pfad body.guide.reasons.<Schritt>), scheitert er, bleibt die Sitzung offen. POST /care-sessions/{id}/reopen öffnet beides wieder. Neues Feld completedAt. Geändert: running ist nach dem Abschluss false (vorher vier Stunden ab Beginn), und start auf eine abgeschlossene Sitzung antwortet conflict mit session-completed.

v1.237.0 · 23. Oktober 2026

  • Pipelines, Vertriebsablauf (PI.21): vierter Abschluss-Typ parked (je Pipeline zuschaltbar über POST /pipelines/{id}/stages mit type: "parked", höchstens einmal). Parken verlangt einen Grund und followUpAt in der Zukunft, sonst 422 mit dem Pfad body.followUpAt (Art followUp in checkMove). Einträge tragen followUpAt; jeder Wechsel setzt es neu. Die Prognose nennt parked (Anzahl, Wert) und rechnet geparkte Einträge nicht. Der Auslöser pipelines.entry.closed filtert auch nach outcome parked.

v1.236.0 · 23. Oktober 2026

  • Terminarten tragen callGuideId: den Leitfaden (GET /call-guides), der im Gespräch und im Meeting dieser Terminart vorgeschlagen wird. Lesen in appointments.getType/listTypes, setzen in createType/updateType (null für keinen). Nur ein aktiver Leitfaden dieser Organisation, sonst validation-failed an body.callGuideId.

v1.235.0 · 23. Oktober 2026

  • Geändert: PATCH /contacts/{id} zieht bei geänderter E-Mail oder Telefonnummer die Interessenten der Partner mit, deren Kontakt das ist, und lehnt ab, statt Kontakt und Interessent auseinanderlaufen zu lassen: 409 conflict mit reason: prospect-email-taken, wenn ein anderer Interessent der Organisation die neue E-Mail schon trägt; 400 validation-failed an body.email (required), wenn die E-Mail eines Interessenten ohne Firmennamen geleert würde; 409 reason: prospect-not-saved, wenn der Interessent nicht gespeichert werden konnte. In allen drei Fällen ist am Kontakt nichts geändert. Unveränderte Felder lösen nichts aus.

v1.234.0 · 22. Oktober 2026

  • Pipelines, Abschluss im Support (PI.19): Phasen tragen noReply (remindAfter, closeAfter, unit businessDays oder days): Erinnerung und Schluss ohne Antwort in einer Phase mit stehender Uhr, beides mit kurzer Mail an den Kunden (Kanal system). Einträge tragen noReplyRemindAt, noReplyCloseAt, previousEntryId (eine Antwort mehr als 14 Tage nach dem Abschluss legt einen neuen Fall an; bis 14 Tage öffnet sie den alten wieder) und slaCredit (Gutschrift einmal je Fall mit verletzter Frist, mit strukturierter calculation). Neu POST /pipelines/entries/{id}/sla-credit/release und …/discard (ORG_ADMIN, ORG_ACCOUNTANT; 409 sla-credit-decided, sla-credit-zero). Die Quelle einer Nachricht über die API ist jetzt human mit dem OAuth-Zugang einer Person, ai über den API-MCP, sonst automatic. Die Prognose nennt valueMode und risk; Support-Pipelines liefern dort die erwarteten Gutschriften negativ statt null.

v1.233.0 · 22. Oktober 2026

  • Pipelines: zwei Namen aus 1.229.0 an die Regel der Zählfelder angeglichen, bevor sie ausgeliefert werden: am SLA caseCount statt casesCount, in slaTargets[] des Eintrags breachCount statt breaches.

v1.232.0 · 22. Oktober 2026

  • Formulare: POST /responses/{id}/pdf verlangt forms:write statt forms:read, wie jeder Endpunkt, der ein PDF erzeugt (invoices.renderPdf, orders.renderPdf, time.renderReportPdf): Er legt ein Dokument an und stösst die Erzeugung an. Der Stand (GET /responses/{id}/pdf/{documentId}) bleibt bei forms:read. 1.231.0 wurde mit forms:read nie ausgeliefert.

v1.231.0 · 22. Oktober 2026

  • PDF einer Einsendung über die API: POST /responses/{id}/pdf erzeugt das PDF im Briefpapier der Organisation (202 mit documentId, status pending), GET /responses/{id}/pdf/{documentId} nennt den Stand (pending, ready mit url, failed), POST /responses/{id}/pdf/{documentId}/send schickt es per E-Mail an den Klienten der Akte. Bögen der Klientenakte nur mit Klientendaten-Freischaltung, clients:read und Aktenzugang der handelnden Person; fehlt der Aktenzugang, 403 forbidden mit reason client-access-required (ebenso jetzt bei POST /form-templates/{id}/insert). Senden: 422 not-a-client-form bzw. contact-without-email, 409 pdf-not-ready.

v1.230.0 · 22. Oktober 2026

  • Vorlagen der Formular-Bibliothek über die API: GET /form-templates (eigene und von anderen Organisationen bereitgestellte, Filter targetEntity, Suche q), GET /form-templates/{id} (Vorschau in der Anrede addressForm), POST /form-templates/{id}/insert (neues Formular aus der Vorlage, 201 mit der Definition und notes), POST /form-templates (eigenes Formular bereitstellen, mit templateId als neue Fassung) und DELETE /form-templates/{id} (nur eigene; eingefügte Formulare bleiben). Lesen mit forms:read, Schreiben mit forms:write und nur für Admins der Organisation; eine Vorlage für die Klientenakte nur mit Aktenzugang (forbidden) und Praxis-Zuschnitt (feature-not-available). targetEntity in GET /forms und GET /forms/{id} nennt jetzt alle vier Ziele (auch VERTRIEBLER_PROFIL und VERTRIEB_FIRMENPROFIL); die Antworten trugen sie schon, die Beschreibung fehlte.

v1.229.0 · 22. Oktober 2026

  • Pipelines, Support mit SLAs (Stufe 4): neu /pipelines/slas (lesen, anlegen, ändern mit archived, löschen nur unbenutzt, sonst 409 sla-in-use) mit Kalender (weeklyHours wie die Öffnungszeiten), Fristen je Art (firstResponse, nextResponse, update, restore, resolution) und Priorität mit ausdrücklicher Einheit (minutes, hours, businessMinutes, businessHours, businessDays), Folge als Gutschrift mit Deckel, Kunden. Neu GET/POST /pipelines/entries/{id}/messages (Antwort an den Kunden geht als Mail hinaus; source leitet der Server ab, über die API automatic). Einträge tragen descriptionHtml, priority, requestedPriority, sla, slaStatus, slaDueAt, slaTargets, restoredAt (schreibbar: Beschreibung, Priorität, restored), Phasen slaClock, Pipelines customerPortalRequests. Ereignisse pipelines.entry.slaDueSoon, pipelines.entry.slaBreached, pipelines.message.created. Neuer Grund not-a-support-case.

v1.228.0 · 22. Oktober 2026

  • Formulare ersetzen über die API: PUT /forms/{id} ersetzt ein Formular als Ganzes mit demselben Rumpf wie POST /forms (Kopf ohne Angabe mit der Vorgabe, Seiten, Elemente). Was der Rumpf nicht kennt, bleibt (Freigaben, Links, Abschluss, Darstellung); bisherige Einsendungen bleiben lesbar. Antwort 200 mit der Definition und build. targetEntity lässt sich nicht ändern (422 an body.targetEntity); ein archiviertes Formular ergibt 409 conflict mit reason archived wie bei POST /forms/{id}/responses, ein Kurzname eines anderen Formulars 409 form-slug-taken. Nur Admins der Organisation, Scope forms:write. Der Grund archived hat jetzt einen Text in der Fehlerseite.

v1.227.0 · 22. Oktober 2026

  • Formulare anlegen über die API: POST /forms legt ein Formular als Ganzes an (Kopf, Seiten, Elemente nach kind: text, standardField, field mit new für ein neues eigenes Feld, matrix, repeater; Bedingungen in condition; Häkchen in consents), über denselben Bau wie der Formular-Baukasten. Antwort 201 mit der Definition wie GET /forms/{id} und build (createdFields, reusedFields, notes). POST /forms/validate prüft denselben Rumpf, ohne zu speichern (valid, errors, notes, geplante Seiten, Elemente und Felder). GET /forms/building-blocks nennt Standardfelder, vorhandene eigene Felder, Feldarten für neue Felder, die Sprache der Bedingungen und den Aufbau von Raster und Wiederholer. Nur Admins der Organisation (sonst 403 forbidden); Scope forms:write zum Anlegen, forms:read für Prüfen und Bausteine. Fehler 422 validation-failed mit Pfad body.pages.<i>.elements.<j>… (Indizes ab 0) und Code invalid_reference, required, invalid_value, invalid_combination oder too_big; ein vergebener Kurzname 409 conflict mit reason form-slug-taken (im Prüflauf ein Fehler mit diesem Code). Bögen der Klientenakte nur mit Praxis-Zuschnitt.

v1.226.0 · 22. Oktober 2026

  • Formulare: POST /forms/{id}/archive und POST /forms/{id}/unarchive archivieren ein Formular bzw. holen es zurück, wie im Formular-Baukasten (Scope forms:write, nur Admins der Organisation, sonst 403 forbidden; ein Schlüssel ohne handelnde Person bekommt no-acting-user). Antwort 200 mit dem Formular; ein zweiter Aufruf ändert nichts. Ein archiviertes Formular nimmt über seine Links nichts an, POST /forms/{id}/responses antwortet 409 (archived). Neu in GET /forms/{id}: consentMode, die Einwilligungs-Art des Formulars (none, optional, promotion).

v1.225.0 · 22. Oktober 2026

  • Partner-Schlüssel (Lead-API): Neben den Schlüsseln der Organisation gibt es Schlüssel, die an genau einen Partner (Affiliate) gebunden sind, ausgestellt vom Partner im Partner-Portal oder von einem Admin der Organisation. Ein Partner-Schlüssel ruft nur GET /forms/{id}, POST /forms/{id}/responses und POST /appointment-types/{id}/partner-links, sonst 403 forbidden mit reason partner-key-endpoint; der API-MCP nimmt ihn nicht an. Er sendet immer für seinen Partner ein (ein anderes affiliateId ergibt 422 an body.affiliateId, Code partner-affiliate), sieht nur Formulare, die für das Partner-Portal freigegeben sind und Interessenten anlegen (sonst 404), und nur die Interessenten seines Partners. In GET /forms/{id} zählt responseCount dann nur die Einsendungen seines Partners, publicUrl ist null. Anleitung: /developers/partner-leads.

v1.224.0 · 22. Oktober 2026

  • E-Mail-Kampagnen in zwei Arten (kind: marketing oder notice). Eine Mitteilung (notice) geht ohne Werbe-Einwilligung und ohne Abmeldelink an alle der Auswahl, nimmt Vorlagen mit purpose transactional und braucht vor dem Start keine Prüfung (deepCheckRequired). Der Inhalt steht jetzt in der Kampagne: subject, bodyHtml, subjectInformal, bodyHtmlInformal und salutation, aus der Vorlage kopiert und änderbar, ohne die Vorlage zu ändern (template mit modified). Dazu document (Unterlage als persönlicher Link je Empfänger, linkExpiresDays) und attachment (PDF bis 5 MB). GET /email-campaigns/setup nennt kinds, personalSender und je Vorlage kind; GET /email-campaigns filtert mit kind, POST /email-campaigns/recipient-count nimmt kind. Neu: POST /email-campaigns/{id}/document/replace (korrigierte Fassung, die Links bleiben) sowie GET und PUT /email-campaigns/notice-permissions (wer außer den Admins Mitteilungen senden darf). Mitglieder mit diesem Recht sehen über die API nur Mitteilungen und senden mit ihrer persönlichen SendGrid-Adresse (senderLocalPart und senderDomain dürfen dann fehlen); für Admins bleibt alles wie bisher. kind lässt sich nach dem Anlegen nicht ändern (422 immutable). Neue Fehler: 422 unknown-field an body.bodyHtml für Felder, die es nicht gibt, 403 campaign-kind-not-allowed, 422 notice-sender-missing, download-links-not-configured und campaign-document-missing.

v1.223.0 · 22. Oktober 2026

  • Formulare: Zwei Werte von bookingError an POST /forms/{id}/responses heissen jetzt wie bei appointments.createPartnerLink (1.220.0): prospect-without-contact statt contact-missing und appointment-type-not-released-to-partner statt appointment-type-not-released. Die alten Namen aus 1.221.0 wurden nie ausgeliefert.

v1.222.0 · 22. Oktober 2026

  • Neue Alarm-Art AUTOMATION_RUN_HALTED (in GET /organization/api-alerts und PUT /organization/api-alerts/rules/{kind}): Hält eine Automation einen Lauf an einem behebbaren Grund an (precondition-failed mit fixable: true), meldet sie sich über die Glocke an Inhaber und Org-Admins, auf Wunsch per E-Mail, höchstens einmal je Regel und Grund in 24 Stunden. Ausgenommen sind fehlende Pflichtangaben einer Pipeline-Phase: Dort entsteht wie bisher eine Aufgabe.

v1.221.0 · 22. Oktober 2026

  • Formulare: POST /forms/{id}/responses nimmt optional appointmentTypeId und senderContactId. Mit einer Terminart enthält die Antwort zusätzlich bookingUrl, den persönlichen Partner-Terminlink des neuen Interessenten (bucht ohne erneute Eingabe beim Vermittler), oder bookingError, warum es keinen gibt: prospect-not-found (kein Interessent, etwa ohne Vermittler), contact-missing, appointment-type-not-released, sender-not-in-team, booking-failed. Scheitert nur der Link, bleibt die Einsendung bestehen (201). Dafür braucht der Schlüssel zusätzlich appointments:write, sonst 403 insufficient-scope vor dem Einsenden. Mit einem Partner-Schlüssel gilt der Link nur für Interessenten des eigenen Vermittlers. Ohne appointmentTypeId ist die Antwort unverändert.

v1.220.0 · 22. Oktober 2026

  • Neu: POST /appointment-types/{id}/partner-links (appointments.createPartnerLink) liefert mit prospectId den persönlichen Buchungslink des Partners für diesen Interessenten, vorhanden oder neu (kind PARTNER, mit contactId, affiliateId, senderContactId). Dieselben Regeln wie im Partner-Portal: nur für den Partner freigegebene Terminarten, Absender aus seinem Team (optional senderContactId, sonst die zuständige Person des Interessenten bzw. der Inhaber des Partners). Neue Gründe für precondition-failed: prospect-without-contact, appointment-type-not-released-to-partner.

v1.219.0 · 22. Oktober 2026

  • Pipelines: Die Szenarien der Prognose heissen worst, normal, best (in forecast.months[].weightedCents, in den Töpfen und in effectiveProbability der Phasen), die Schreibfelder an den Phasen probabilityWorst/probabilityBest. Sie ersetzen bad/good und probabilityBad/probabilityGood aus 1.218.0, das nicht ausgeliefert wurde.

v1.218.0 · 22. Oktober 2026

  • Pipelines, Prognose und Lernen: neu GET /pipelines/{id}/forecast (zwölf Monate ab dem laufenden, gewichteter Wert je Monat in den Szenarien bad, normal, good, Töpfe overdue, withoutDate, later, Anteil Messung, Herkunft des Datums; je offener Phase wirksame Wahrscheinlichkeit, Verweildauer und Restlaufzeit; forecast ist null ohne Wertmodus revenue). Phasen tragen effectiveProbability (wirksame Wahrscheinlichkeit nach learningMode mit Szenarien, measuredPercent, decidedCases) und probabilityBad/probabilityGood (Szenarien von Hand, schreibbar mit POST/PATCH .../stages). Verhalten: learningMode wirkt jetzt; probability und weightedValueCents am Eintrag rechnen ohne Überschreibung mit der wirksamen Wahrscheinlichkeit der Phase statt mit der Vorgabe (bei learningMode default unverändert).

v1.217.0 · 22. Oktober 2026

  • Pipelines: couplings trägt prospectsRequired (Interessenten der Affiliates werden in dieser Pipeline geführt; arbeitet ein Affiliate an einem ohne Eintrag, bittet das Portal um Zuordnung) und prospectsAutomatic (ohne Rückfrage in der Eingangsphase anlegen), lesbar in GET /pipelines/{id}, schreibbar mit PATCH /pipelines/{id}.

v1.216.0 · 22. Oktober 2026

  • Automationen: drei neue Aktionen für Pipelines im Katalog (GET /automation-catalog) und in POST/PATCH /automations, je ein Endpunkt: pipelines.createEntry (Eintrag anlegen), pipelines.moveEntries (Phase setzen, auch Abschliessen mit Grund; der jüngste oder alle offenen Einträge des Kontakts oder ein bestimmter) und pipelines.updateEntry (Wert, zuständige Person, Abschlussdatum). Die Pflichtangaben einer Phase gelten auch hier: Fehlt eine, scheitert der Schritt behebbar. Neue Filterarten pipeline und pipelineStage („eines von“) an den Auslösern pipelines.entry.*, beim Abschluss outcome. Neue Datumsquellen pipelines.entry.expectedCloseDate und pipelines.entry.rotting (Eintrag liegt zu lange in seiner Phase). Feldquellen pipeline, pipelineStage, pipelineReason, Objekt entry. Behoben: Bei Datums-Auslösern galten Filter „eines von“ bisher nicht.

v1.215.0 · 22. Oktober 2026

  • Pipelines, Kopplungen: Pipelines tragen couplings (quoteValue, quoteAcceptedStageId, paidMeansSuccessful, leadSources), lesbar in GET /pipelines und GET /pipelines/{id}, schreibbar mit PATCH /pipelines/{id} (leadSources ersetzt die Liste als Ganzes). Neu GET /pipelines/assignments und POST /pipelines/assignments/{id}/resolve: offene Zuordnungen von Zahlungen, angenommenen Angeboten und Leads zu einem Eintrag, wenn der Eintrag nicht eindeutig ist. Neu POST /pipelines/entries/move für Automationen: Phase setzen für einen bestimmten Eintrag, den jüngsten offenen oder alle offenen eines Kontakts; alles oder nichts, fehlende Angaben als precondition-failed mit stage-requirements-missing und fixable: true.

v1.214.0 · 22. Oktober 2026

  • Pipelines: Phasen haben eine optionale Farbe color (eine der zwölf Kategorie-Farben wie color der Leitfäden, null = ohne Farbe), zu lesen in GET /pipelines/{id} und zu setzen mit POST /pipelines/{id}/stages und PATCH /pipelines/{id}/stages/{stageId}. Die Pipeline trägt stageColorDisplay (dot = Punkt neben dem Namen, fill = Kopf in voller Farbe), Vorgabe dot, zu setzen mit PATCH /pipelines/{id}.

v1.213.0 · 21. Oktober 2026

  • Neu: Medien zur Stunde für den Live-Raum (Bereich appointments). GET/PUT /appointment-types/{id}/lesson-media liest bzw. ersetzt die Liste der Terminart (assetIds, höchstens 50, Reihenfolge = position). GET/PATCH /appointments/{id}/lesson-media zeigt die wirksame Liste des Termins (media) und seine Abweichungen (added, hidden); add ergänzt nur für diesen Termin, hide blendet Medien der Terminart aus, ein gesetztes Feld ersetzt seine Liste. Nach dem Ende des Termins 422 precondition-failed mit appointment-ended. GET /lesson-media/options sucht Videos und PDFs der Bibliothek (q). Schreiben nur mit dem Recht, Termine zu verwalten.

v1.212.0 · 21. Oktober 2026

  • Formulare, nur Verhalten, für Einsendungen über den öffentlichen Link (/f/…): Ist die Person sicher bekannt (persönlicher Link an einen Kontakt, gemerktes Gerät oder per Code bestätigte E-Mail-Adresse) und besteht für genau die Adresse bzw. Nummer im Feld eine Werbe-Einwilligung, die höchstens 24 Monate alt und nicht widerrufen ist, fragt der Bogen sie nicht erneut. Die Einsendung (GET /forms/{id}/responses, GET /responses/{id}, forms.response.submitted) trägt für diesen Kanal dann keinen Eintrag mit purpose MARKETING; das ist kein Nein, der Stand der Einwilligung steht am Kontakt. Ein gesetztes Häkchen erscheint wie bisher. Einsendungen über POST /forms/{id}/responses sind nicht betroffen.

v1.211.0 · 21. Oktober 2026

  • Neu: Pipelines (Bereich pipelines, Rechte pipelines:read bzw. pipelines:write). GET/POST /pipelines, GET/PATCH /pipelines/{id}, Phasen (/pipelines/{id}/stages, Reihenfolge PUT …/stages/order) und Abschluss-Gründe (/pipelines/{id}/reasons); Pipelines und Phasen pflegen nur Org-Admins. Einträge unter /pipelines/entries: anlegen, ändern, move (auch abschliessen), move/check, reopen, history. Beim Phasenwechsel gelten dieselben Anforderungen wie in der Oberfläche, beim Überspringen addiert: Fehlt etwas, kommt 422 mit je einem Fehler stage-requirement; gesperrt precondition-failed mit stage-skip-locked bzw. stage-back-locked (fixable: false), archivierte Pipeline pipeline-archived (fixable: true). Ereignisse pipelines.entry.created, .stageChanged, .closed, .valueChanged. Beträge als valueCents. Dazu DELETE /articles/{id}: 409 in-use auch, wenn Einträge einer Pipeline ihren Wert aus dem Artikel haben (usage.pipelineEntries).

v1.210.1 · 21. Oktober 2026

  • Verhalten: Die Quelle mollie der Abo-Vorschau (/provider-subscriptions) liefert Zahlen, sobald die Organisation Mollie mit dem Recht subscriptions.read verbunden hat (neue Verbindungen fragen es an, bestehende verbinden einmal neu). Gelesen werden die Abos aller Mollie-Profile der Organisation, abgeglichen nachts und über POST /provider-subscriptions/sync; netCents bleibt leer (Mollie nennt kein Netto). Bis zum Neuverbinden bleibt es bei needs-reconnect. Spezifikation gleich.

v1.210.0 · 21. Oktober 2026

  • Neu: Abo-Vorschau für Abos, die beim Zahlungsanbieter selbst angelegt sind (nicht die claritos-eigenen unter /subscriptions). GET /provider-subscriptions listet den Spiegel (Filter source: stripe-connect, stripe-platform, mollie; status; contactId über die E-Mail). GET /provider-subscriptions/forecast liefert je Währung diesen Monat ab heute und die nächsten elf Monate, brutto oder mit net=true netto, und je Quelle state, syncedAt, needsReconnect. POST /provider-subscriptions/sync stösst den Abgleich an (202; 409 sync-locked mit retryAfter, 409 source-not-ready). Rechte subscriptions:read bzw. subscriptions:write. Mollie meldet needs-reconnect, bis die Organisation Mollie mit dem Recht für Abos neu verbunden hat.

v1.209.0 · 21. Oktober 2026

  • Geändert: GET /affiliates/activity zählt unter emails jetzt auch Mails aus dem Postfach der Partner im Partner-Portal (Mail-Client und Leitfaden), und zwar auch je Person (people[].counts.emails, vorher null). Festgehalten sind nur Zeitpunkt, Person und Empfängerzahl, kein Inhalt; gezählt ab der Einführung. Werbemittel-Versände zählen nur noch bis zum ersten solchen Beleg der Organisation, sonst stünde dieselbe Mail doppelt da. Dazu ist das Beispiel berichtigt: previousPeriod ist dort gleich lang wie period.

v1.208.0 · 21. Oktober 2026

  • Neu: Abo direkt über die erste Rechnung. Rechnungen haben das Feld subscription (intervalMonths 1 bis 60, periods 2 bis 600 oder null = bis zur Kündigung; null = kein Abo), lesbar und schreibbar über POST /invoices und PATCH /invoices/{id}. Beim Festschreiben (POST /invoices/{id}/issue) entsteht das Abo, die Rechnung ist sein erster Zeitraum (billingContractId); der Leistungszeitraum wird auf diesen Zeitraum gesetzt. Fehler: 422 an body.subscription…, body.contactId oder body.items, 409 subscription-exists.
  • Neu: Abo-Status AWAITING_FIRST_PAYMENT (GET /subscriptions, Filter status): aus einer Rechnung angelegt, erste Rechnung noch offen. Bezahlt wechselt das Abo auf ACTIVE, fällige Folgerechnungen entstehen sofort; der Storno der ersten Rechnung setzt es auf CANCELLED. Clients, die nur die bisherigen vier Werte kennen, sollten einen unbekannten Status nicht als laufend werten.

v1.207.0 · 21. Oktober 2026

  • Neu: GET /affiliates/activity liefert das Geschehen der Affiliates wie der Dashboard-Baustein: Telefonate und Gesprächszeit, Meetings (Termine und Live-Räume), Abschlüsse samt Umsatz je Währung, neue Interessenten, Nachrichten (E-Mail, SMS, Brief) und erledigte Aufgaben, je Affiliate und Person, für from bis to (Vorgabe die letzten 30 Tage) und den gleich langen Zeitraum davor. Filter affiliateId. Nur mit der Affiliate-Verwaltung in der Lizenz, sonst 403 feature-not-available.

v1.206.0 · 21. Oktober 2026

  • Neu: GET /contacts filtert mit responsible nach Zuständig, kommagetrennt (höchstens 20): Nutzer-Kennungen von Mitgliedern, me für die handelnde Person des Schlüssels, partner für Kontakte, um die sich nur ein Partner kümmert. Es gilt dieselbe Regel wie im Filter „Zuständig“ der Anwendung (ein Mitglied vor einem Partner; wer die Organisation verlassen hat, zählt nicht); responsible=me entspricht dem Schalter „Nur eigene“. Ein Schlüssel ohne Anleger bekommt für me 422 no-acting-user, ein unbekannter Wert 400 validation-failed.

v1.205.1 · 21. Oktober 2026

  • Behoben: DELETE /invoices/{id} antwortete bei einem Entwurf 204, ohne ihn zu löschen (seit 1.179.0; betroffen war jeder Entwurf, der nicht zu einem Credits-Lauf gehört). Jetzt wird er gelöscht. Wird dabei keine Zeile gelöscht (etwa weil der Entwurf im selben Moment festgeschrieben wurde), antwortet der Endpunkt 404 not-found statt 204. Entwürfe eines Credits-Laufs bleiben 409 credits-run.

v1.205.0 · 21. Oktober 2026

  • Geändert: POST/PATCH /message-templates nehmen das Feld {{terminlink.<Terminart-Kennung>}} an (bisher 400 unknown-field). Erlaubt sind bei usage: contacts die Terminarten mit persönlichem Link, im Partner-Portal die an Partner freigegebenen; sonst 400 unknown-field mit Hinweis auf die Terminart. Beim Versand wird daraus je Empfänger ein persönlicher Buchungslink (im HTML als Link). Neu: Lässt er sich für den Kontakt nicht anlegen, antworten POST /outbound-emails und POST /sms mit vorlageId mit 422 und reason: booking-link-unavailable, statt mit leerer Stelle zu senden.

v1.204.0 · 21. Oktober 2026

  • Neu: reminderService in POST /appointments: Der Kunde wünscht Terminerinnerungen (Erinnerungsservice), nur auf seinen ausdrücklichen Wunsch, ohne Angabe Nein; nur am Einzeltermin, festgehalten für E-Mail-Adresse und Handynummer am Kontakt mit Quelle „Schnittstelle“, ein früherer Widerruf des Kunden bleibt. Geändert: Erinnerungen vor dem Termin an Kunden werden wieder eingeplant, gehen aber nur mit dieser Zustimmung hinaus (geprüft beim Versand, gegen genau die Adresse bzw. Nummer), und jede trägt einen Link zum Abbestellen. Bestätigung, Absage und Verschiebung gehen immer.

v1.203.0 · 20. Oktober 2026

  • Neu: contactId in POST /appointment-types/{id}/links liefert den persönlichen Buchungslink dieses Kontakts, vorhanden oder neu (kind PERSONAL): Der Termin hängt am Kontakt; hat die Terminart keinen Bogen, bucht er ohne weitere Angaben. Dafür braucht die Terminart die Freigabe „persönlicher Link“; neue Gründe für precondition-failed: appointment-type-not-personal, appointment-type-internal-only. Ohne contactId wie bisher ein neuer offener Link.

v1.202.0 · 20. Oktober 2026

  • Neu: reminderPlanId in POST /appointment-types und PATCH /appointment-types/{id} ordnet der Terminart einen Erinnerungsplan zu (GET /appointment-reminder-plans), null heisst keine Erinnerungen. Ohne Angabe bekommt eine neue Terminart den Standardplan der Organisation, eine bestehende behält ihren. Geändert: Erinnerungen vor dem Termin an Kunden werden nicht eingeplant, bis der Kunde dem Erinnerungsservice zugestimmt hat; Bestätigung, Absage und Verschiebung gehen immer.

v1.201.0 · 20. Oktober 2026

  • Aufgaben-Erinnerungen (Kern KR.41). Neu: GET /tasks/reminder-settings und PUT /tasks/reminder-settings (tasks:read/tasks:write, Schreiben nur für Admins der Organisation) lesen und setzen die Vorgabe: Zeitpunkte vor der Fälligkeit in minutesBefore (0, 15, 60, 180, 1440, 2880, 10080; Unbekanntes fällt still weg) und Wege in channels (BELL, EMAIL, SMS). Ohne gespeicherte Vorgabe gilt die Glocke zur Fälligkeit; E-Mail und SMS erst, wenn eine Admin-Person sie einschaltet. Aufgaben mit Fälligkeit lösen jetzt Erinnerungen an die zuständige Person aus, auch wenn sie über die API angelegt wurden. Neu an der Aufgabe: dueHasTime (ob dueDate eine Uhrzeit trägt). Beim Schreiben von dueDate gilt ein Datum allein oder Mitternacht UTC als ohne Uhrzeit; ohne Uhrzeit ist die Aufgabe an ihrem Tag fällig, erinnert wird um 8:00 Uhr (Berlin). kind an SMS (GET /sms, Ereignisse sms.message.*) kennt den neuen Wert TASK_REMINDER.

v1.200.0 · 20. Oktober 2026

  • Neu: PATCH /telephony (telephony.updateOptions) schaltet die Anrufbeantworter-Erkennung der Organisation an oder aus (answeringMachineDetection), und GET /telephony zeigt ihren Stand im neuen Feld answeringMachineDetection (ohne verbundenes Konto false). Die Erkennung ist für jede Organisation zunächst an: Bei ausgehenden Anrufen meldet Twilio, ob ein Mensch, ein Anrufbeantworter oder ein Fax abnahm; das braucht die Auswertung der Telefonate, um Mailboxen zu zählen. Sie läuft im Hintergrund, der Angerufene wartet nicht, und Twilio berechnet sie je angenommenem Anruf auf dem Konto der Organisation. Nur ORG_ADMIN, Recht telephony:write.

v1.199.0 · 20. Oktober 2026

  • Neu: Sitzungen einer Betreuung (Praxis BP.2). GET /care-enrollments/{id}/sessions listet die geöffneten Sitzungen, GET /care-sessions/{id} liest eine. POST /care-enrollments/{id}/sessions/open öffnet die Sitzung an einer Position der Abschrift (beim ersten Mal angelegt, danach dieselbe), POST /care-enrollments/{id}/sessions legt eine spontane Sitzung ausserhalb des Plans an (adHoc, ohne position; etwa bei einer Krise, nur in einer laufenden oder pausierten Betreuung, sonst conflict mit enrollment-ended). POST /care-sessions/{id}/start beginnt eine Sitzung: running ist dann vier Stunden lang true. PATCH /care-sessions/{id} setzt den Sitzungstyp (standard, safety, gentle, catch-up, relief) mit kurzem Grund. Rechte wie bei den Betreuungen: careplans:read/:write und clients:read/:write, Klientendaten-Freigabe, Zugriffsprotokoll. Der Leitfaden-Lauf einer Sitzung hat keinen Endpunkt; seine Kennung steht in guideRunId.

v1.198.0 · 20. Oktober 2026

  • Formulare, nur Verhalten, für Einsendungen über den öffentlichen Link (/f/…): (1) Bei einem Formular mit Werbung, dessen E-Mail oder Telefon per Link nach dem Absenden bestätigt wird, fragt der Bogen die Werbe-Einwilligung erst nach dem Absenden. Ein „Ja“ wird danach an die Einsendung angehängt: GET /forms/{id}/responses und GET /responses/{id} zeigen dann eine angenommene Einwilligung mit purpose MARKETING, die forms.response.submitted beim Absenden noch nicht enthielt; ein eigenes Ereignis für das spätere „Ja“ gibt es nicht. Ein „Nein“ hinterlässt nichts. Wirksam wird die Werbe-Einwilligung erst mit dem Klick in der Bestätigung. (2) Neue Einwilligungs-Art „Werbeaktion“: Der Absenden-Knopf ist der Wunsch nach Werbung, der Wortlaut steht darüber. Die Einsendung trägt die Einwilligung als accepted true, ohne dass ein Häkchen gezeigt wurde. Einsendungen über POST /forms/{id}/responses sind davon nicht betroffen; dort bleiben Werbe-Einwilligungen Häkchen.
  • Nur Dokumentation: Das Beispiel von GET /forms/{id} zeigt statt des entfallenen Anfrage-Häkchens (purpose INQUIRY, seit 1.197.0) ein freiwilliges Werbe-Häkchen (purpose MARKETING, required false). Das Beispiel einer Einsendung behält INQUIRY, weil ältere Einsendungen es tragen.

v1.197.0 · 20. Oktober 2026

  • Formulare, nur Verhalten: Das Pflicht-Häkchen „Kontakt zu meiner Anfrage“ (purpose INQUIRY) entfällt. Eine Anfrage zu beantworten braucht keine Einwilligung; der Bogen zeigt dafür einen Datenschutzhinweis. GET /forms/{id} nennt in consents keine Einwilligung mit INQUIRY mehr. Werbe-Einwilligungen (MARKETING) und ältere Häkchen für Anfrage und Werbung zusammen (purpose null, Kanal E-Mail oder Telefon) erscheinen nur, wenn das Formular Werbung erlaubt; das ist die Vorgabe für alle bestehenden Formulare. Eigene Einwilligungen (Kanal CUSTOM) unverändert. POST /forms/{id}/responses verlangt für E-Mail oder Telefon kein Anfrage-Häkchen mehr: validation-failed mit body.consents.<elementId> kommt nur noch für eigene Pflicht-Einwilligungen und ältere zusammengefasste Häkchen. Ein mitgeschicktes true für das entfallene Häkchen ist kein Fehler, es wird nicht gespeichert. Neue Einsendungen (GET /forms/{id}/responses, forms.response.submitted) und consent/consentPurposes von leads.lead.created tragen kein INQUIRY mehr; ältere Einsendungen behalten es, deshalb bleibt der Wert im Schema.

v1.196.0 · 20. Oktober 2026

  • Geändert: Terminserien haben bis 100 statt 10 Schritte. In POST /appointment-series-templates und PATCH /appointment-series-templates/{id} gilt steps für 2 bis 100 Schritte und samePersonAsStep bis 100; ebenso appointments in POST /appointment-series, {step} in /appointment-series/{id}/steps/{step} und following in POST /appointments/{id}/reschedule-with-series.

v1.195.0 · 19. Oktober 2026

  • Geändert: Der Text eines Erinnerungsschritts (bodyHtml, auch in informal) behält in PATCH /appointment-reminder-steps/{id} nur noch die Auszeichnung der Maske: Absatz, Fett, Kursiv, Unterstrichen, Durchgestrichen, Listen und Zeilenumbruch. Ein Link wird zu seinem Text, Bilder und Attribute entfallen. Bestätigung, Absage und Verschiebung gehen immer hinaus und sollen keinen werbenden Bestandteil tragen.

v1.194.0 · 19. Oktober 2026

  • Neu, nur für ORG_ADMIN: API-Alarme der Organisation lesen (GET /organization/api-alerts: Aufrufe und Fehler für 24 Stunden und 7 Tage, Regeln je Art, letzte Alarme, Alarm-Adresse), eine Alarm-Art einstellen (PUT /organization/api-alerts/rules/{kind}) und die Alarm-Adresse setzen (PUT /organization/api-alerts/email). Dazu die Installationen der claritos-App in LeadConnector lesen (GET /organization/integrations/leadconnector) und eine trennen (DELETE /organization/integrations/leadconnector/{id}); installiert wird weiterhin in LeadConnector selbst. Rechte organization:read bzw. organization:write.

v1.193.0 · 19. Oktober 2026

  • Neues Ereignis careplans.enrollment.resumed: Eine pausierte Betreuung läuft wieder (Status ACTIVE aus PAUSED). Nutzlast wie bei den übrigen careplans.enrollment.* (nur Kennungen und Zustände); Klientendaten, geht nur an Endpunkte mit clientsData. Auch als Auslöser für Automationen.

v1.192.0 · 19. Oktober 2026

  • Neu: firstSessionIsOnboarding an GET /care-plans/{id} (und den Antworten der übrigen Vorlagen-Endpunkte) und an copy der Betreuungen. true heisst: Sitzung 1 ist das Onboarding und heisst in der Oberfläche Sitzung 0; Positionen, Serie und Zeitfenster zählen weiter ab 1. Schreibbar an POST/PUT /care-plans und im Probelauf POST /care-plans/validate, optional; ohne Angabe false, auch bei PUT, weil der Baum als Ganzes ersetzt wird.

v1.191.0 · 18. Oktober 2026

  • Neu: Bereich careplans (Betreuungspläne der Praxis), Rechte careplans:read/careplans:write, Gruppe „Kontakte und Klienten“. Vorlagen: GET/POST /care-plans, GET/PUT/DELETE /care-plans/{id}, GET /care-plans/options, Probelauf POST /care-plans/validate, POST /care-plans/{id}/release, …/retire, …/versions. Ein Plan wird als ganzer Baum geschrieben (Kopf, Phasen, Sitzungen), nur ein eigener Entwurf ist änderbar (409 plan-not-draft), Lücken zur Freigabe stehen in gaps. Betreuungen (Klientendaten, zusätzlich clients:read/clients:write und Klientendaten-Freigabe, Zugriffsprotokoll): GET/POST /care-enrollments, GET /care-enrollments/{id}, GET /clients/{id}/care-enrollments, POST /care-enrollments/{id}/events, …/status, Termine über GET …/appointment-proposal und POST …/appointments (dazu appointments:read/appointments:write). Überall das Lizenzrecht Praxisbetrieb und eine handelnde Person mit Aktenzugriff; Freigeben und Zurückziehen nur mit dem Freigabe-Recht. Ereignisse careplans.enrollment.started, .paused, .ended (nur an Endpunkte mit clientsData, nur Kennungen und Zustände).

v1.190.0 · 18. Oktober 2026

  • Neu im Bereich biomarkers: Biomarker-Regelwerke. GET/POST /biomarker-rule-sets, GET/DELETE /biomarker-rule-sets/{id}, PUT …/{id}/rules (Regeln als Ganzes), POST /biomarker-rule-sets/validate (Probelauf ohne Speichern), POST …/{id}/confirm und …/{id}/unconfirm. Bedingungen englisch (value, unit, present/missing), Marker als Schlüssel der Hausliste. Bestätigen nur durch eine Person mit Freigabe-Recht, nie aus einer Automation (403 confirm-needs-person); ein bestätigtes Regelwerk ist nicht änderbar (409 rule-set-confirmed).

v1.189.1 · 18. Oktober 2026

  • Verhalten: Eine Fristverlängerung (POST /dunning/open-items/{openItemId}/extension, dueDate) gilt jetzt bis zum Ende des gewährten Tages (UTC), nicht nur bis 00:00 Uhr. Am gewährten Tag selbst antwortet ein zweites Gewähren daher 409 extension-exists, und der Mahnlauf mahnt erst ab dem Folgetag weiter. Gespeichertes und gedrucktes Datum unverändert.
  • Verhalten: DELETE /articles/{id} antwortet 409 in-use jetzt auch, wenn der Artikel auf Angebots- oder Auftragszeilen (jeder Status), in Abo-Verträgen, auf Provisionsgutschriften, in Einstellungen der Organisation, als Provisionsartikel einer Kampagne oder an einem Zugangs-Hook steht. usage hat dafür die Felder quoteLines, orderLines, subscriptionLines, commissionCreditLines, accessHooks, organizationSettings, campaignCommissions. Statt Löschen: archivieren.

v1.189.0 · 18. Oktober 2026

  • Neu: Bereich biomarkers (Biomarker der Praxis, nur mit dem Recht Praxisbetrieb der Organisation). GET /biomarker-profiles listet die Biomarker-Profile mit Zustand, Fassung, Markerzahl und deletable/deleteBlockedBy; DELETE /biomarker-profiles/{id} löscht ein Profil, solange es nie benutzt wurde (nie freigegeben, keine Laboranforderung, nie weitergegeben, keine Folgefassung), sonst 409 conflict mit reason. Lesen und Schreiben verlangen eine handelnde Person mit Aktenzugriff; Profile sind keine Klientendaten.

v1.188.0 · 18. Oktober 2026

  • Neu an mailboxes.*: attachmentHandling (receipt, receiptStack, document oder null) legt fest, wie Anhänge an ein gemeinsames Postfach behandelt werden, wie die Adressen je Art auf inbox.claritos.io. Je Art höchstens ein gemeinsames Postfach je Organisation; sonst 409 mit reason: handling-taken. Persönliche Postfächer liefern immer null.

v1.187.0 · 18. Oktober 2026

  • Neue Rechte biomarkers:read/biomarkers:write für die Biomarker der Praxis (Profile mit Referenzwerten). Sie sind vorbereitet für die Endpunkte, die folgen; bis dahin geben sie keinen Zugriff. Bestehende Schlüssel und OAuth-Zugänge bekommen sie nicht von selbst.

v1.186.0 · 18. Oktober 2026

  • Neu im Bereich credits: Abrechnungsläufe (/credits/runs: Vorschau, Liste, Lesen, Starten, Festschreiben, Verwerfen, Stornieren, Kontoauszüge versenden und neu erzeugen; Start, Festschreiben und Storno laufen im Hintergrund, Antwort 202), Import (/credits/import-profiles: Profile, Prüfen, Laden, Kennungen, Saldenvortrag, Stammdaten; POST /credits/import-files/header; Liste als Base64, höchstens 600 KB), Käufe aus dem Portal (/credits/portal-purchases, Rechnungen dazu mit invoices:write), Provisionen (/credits/commissions, Abgleich) und Betreuungen (PUT /credits/accounts/{id}/supervision, DELETE /credits/supervisions/{id}).

v1.185.0 · 18. Oktober 2026

  • Neu: Bereich credits (Credits-Programm, nur mit dem Recht CREDITS der Organisation): Programme GET/POST /credits/programs, GET/PATCH /credits/programs/{id}, PUT/DELETE …/{id}/logo; Konten GET/POST /credits/accounts (Liste mit from/to), GET/PATCH /credits/accounts/{id}, POST …/{id}/entries (Gutschrift oder Korrektur von Hand), PUT …/{id}/bonus-rules. Schreiben verlangt eine handelnde Person mit ORG_ADMIN oder ORG_ACCOUNTANT. Werte englisch (WEEKLY, PREPAID, USAGE, GRANT …).

v1.184.0 · 18. Oktober 2026

  • Neu: Zeiterfassungsdokumente im Bereich time: GET /time-reports (Filter nach Projekt und Status), GET /time-reports/preview, POST /time-reports (Zeiten eines Projekts im Zeitraum einfrieren), GET /time-reports/{id} (mit den Zeiten), POST …/{id}/discard, POST …/{id}/pdf und POST …/{id}/bill (Rechnungsentwurf; verlangt time:write und invoices:write und eine handelnde Person, meldet invoices.invoice.created). Abrechnen weist Zeiten ab, die inzwischen ein anderer Nachweis abgerechnet hat (entries-already-billed).

v1.183.0 · 18. Oktober 2026

  • Neu: Faktura-Vorlagen im Bereich templates: Zahlungsbedingungen (/payment-terms) und Kopf- und Schlusstexte (/text-blocks), je mit Lesen, Anlegen, Ändern, Löschen und POST …/{id}/default; Du-Fassungen unter informal. Löschen archiviert eine Vorlage, die noch an Belegen, Kontakten oder Gutschrift-Vorgaben benutzt wird (mode: archived). Dazu GET/PATCH /contacts/{id}/billing-defaults (Bereich contacts).

v1.182.0 · 18. Oktober 2026

  • Neu: GET /payments/events (Zahlungsereignisse der Stripe-Anbindung, Filter nach Schwere und Art, onlyProblems), Schadensersatz-Abrechnungen GET/POST /settlements und GET /settlements/{id} (Bereich invoices; Anlegen verlangt eine handelnde Person und confirmGenuineDamage: true) sowie POST /files/rich-images (signierte Upload-Adresse für Bilder in Rich-Text-Beschreibungen; erster Endpunkt im Bereich files).

v1.181.0 · 18. Oktober 2026

  • Artikel vollständig: DELETE /articles/{id} (nur unbenutzte; sonst 409 conflict mit in-use und usage, dann archivieren), Icon über POST /articles/{id}/icon-upload, POST /articles/{id}/icon und DELETE /articles/{id}/icon, GET /articles/catalog-range (Preisrahmen einer Katalog-Ziffer). Beim Anlegen und Ändern neu groupName, isSelectable und catalog; beim Lesen zusätzlich usageCount. Neues Ereignis articles.article.deleted.

v1.180.0 · 18. Oktober 2026

  • Rechnungen vollständig: POST/DELETE /invoices/{id}/service-rendered (Leistung erbracht samt Auflösungsbuchung, genau einmal), Berichtigungen nach § 31 Abs. 5 UStDV (GET/POST /invoices/{id}/correction-notes, GET …/correction-notes/{correctionId}/email, POST …/send), Ratenplan (GET /invoices/{id}/installment-plan, POST …/installment-plan/collect, POST …/installment-plan/accelerate), GET /invoices/{id}/fee-schedule-check (GebüH), Versandfreigabe (POST /invoices/release-dispatch) und Plan-Läufe (GET /invoices/plan-runs, POST /invoices/plan-runs/release, POST /invoices/plan-runs/direct-debit; Freigabe und Umstellung nur ORG_ADMIN) sowie Rechnung zu Stripe-Zahlungen (GET /invoices/stripe-payments, POST /invoices/stripe-payments/prepare, POST /invoices/stripe-payments/invoice; nur ORG_ADMIN und ORG_ACCOUNTANT).

v1.179.0 · 18. Oktober 2026

  • Rechnungen: DELETE /invoices/{id} (nur Entwürfe; sonst 409 conflict mit not-draft, Entwürfe eines Credits-Laufs mit credits-run), POST /invoices/{id}/duplicate, GET /invoices/{id}/email (Vorschlag), POST /invoices/{id}/send (stellt nicht selbst fest: 409 conflict mit not-issued; nachgereichte Rechnungen awaiting-release), POST /invoices/{id}/mark-sent (Versand ausserhalb von claritos, immer jetzt), GET /invoices/{id}/refund-preview, POST /invoices/{id}/pdf (Vorschau rendern und warten) und POST /invoices/{id}/pdf/regenerate (offizielles PDF neu erzeugen). Im Storno über POST /invoices/{id}/correct neu refundDays (Frist der Erstattung).
  • Verhaltensänderung: POST /invoices, POST /invoices/{id}/issue und POST /invoices/{id}/correct verlangen eine handelnde Person (no-acting-user), bisher 500 internal bei einem Schlüssel ohne Anleger. GET /invoices/{id}/pdf und POST /quotes/{id}/convert brauchen sie nur, wenn gerendert bzw. das Angebot erst ausgestellt werden muss; die Mail-Vorschläge (GET …/email bei Rechnungen, Aufträgen und Angeboten) gehen ohne Person mit Signatur und Absender der Organisation. Die Kopie einer Rechnung meldet jetzt invoices.invoice.created.

v1.178.2 · 18. Oktober 2026

  • Verhalten, Spezifikation gleich: POST /open-items/{id}/payments verlangt jetzt eine handelnde Person, sobald eine Buchung entsteht, und antwortet ohne sie mit 403 no-acting-user. Bisher scheiterte ein Schlüssel ohne Anleger dort mit 500 internal. markOnly: true (ohne Buchung) geht weiter ohne Person.

v1.178.1 · 18. Oktober 2026

  • Verhalten, Spezifikation gleich: POST /tasks, POST /tasks/{id}/comments und POST /time-entries (ohne userId) antworten bei einem API-Schlüssel ohne hinterlegten Anleger jetzt mit 403 no-acting-user statt mit 500. Vorher kam ein leerer Nutzer im Kern an. Mit OAuth-Zugang und bei Schlüsseln mit Anleger ändert sich nichts; bei POST /time-entries bleibt eine ausdrücklich übergebene userId gültig.

v1.178.0 · 18. Oktober 2026

  • Aufträge vollständig: POST /orders (Entwurf mit den Vorgaben des Kontakts, Positionen und Abschnitte gleich mit), PATCH /orders/{id} (bis zur ersten Abrechnung, sonst 409 conflict mit locked), DELETE /orders/{id} (nur Entwürfe ohne Nummer, sonst not-draft), POST /orders/{id}/issue (AB-Nummer und PDF), POST /orders/{id}/send (Auftragsbestätigung per E-Mail), GET /orders/{id}/email (Vorschlag), POST /orders/{id}/duplicate, POST /orders/{id}/pdf (Vorschau oder ausgestellte Fassung rendern und darauf warten), POST /orders/{id}/invoices (Teil-, Schluss- oder Abschlagsrechnung als Entwurf; braucht zusätzlich invoices:write), POST /orders/{id}/lines/{lineId}/drop und …/restore (Position entfallen lassen und zurücknehmen; haben sich die Mengen inzwischen geändert, 409 conflict mit line-changed). Anlegen, Kopie, Ausstellen, Senden und PDF verlangen eine handelnde Person.
  • Neues Ereignis orders.order.sent: die Auftragsbestätigung ging per E-Mail hinaus, aus der Oberfläche oder über die API, mit sentTo.
  • Verhaltensänderung bei Angeboten: POST /quotes, POST /quotes/{id}/issue, POST /quotes/{id}/send und GET /quotes/{id}/pdf (wenn eine Vorschau gerendert wird) verlangen jetzt eine handelnde Person und antworten ohne sie mit no-acting-user. Bisher scheiterte ein Schlüssel ohne Anleger dort mit 500 internal.

v1.177.0 · 18. Oktober 2026

  • Angebote vollständig: GET /quotes/{id}/email (Vorschlag für die Angebots-E-Mail mit Absender und ob versendbar), POST /quotes/{id}/remind (jetzt erinnern, nur SENT), POST /quotes/{id}/duplicate (tiefe Kopie als Entwurf; verlangt eine handelnde Person), DELETE /quotes/{id} (nur Entwürfe ohne Nummer, sonst 409 conflict mit not-draft) und Anhänge: GET und POST /quotes/{id}/attachments, DELETE /quotes/{id}/attachments/{documentId}, PUT /quotes/{id}/attachment-order.

v1.176.0 · 18. Oktober 2026

  • Neu: Inkasso-Fälle. GET /dunning/collection-cases (Filter status: pending, released, withdrawn, all), GET /dunning/collection-cases/{id}, POST …/release (recipientEmail, coverLetterHtml; claritos stellt die Fallakte aus Rechnung, Leistungsnachweis und Mahn-PDFs zusammen und schickt sie an das Inkassobüro; verlangt eine handelnde Person) und POST …/withdraw (solange nicht übergeben). Freigeben und Zurückziehen sind gegen gleichzeitige Aufrufe geschützt (409 conflict mit wrong-status).

v1.175.0 · 18. Oktober 2026

  • Neu: Mahnungen schreiben. POST /dunning/reminders/{id}/finalize (Nummer, Buchung, PDF), …/regenerate, …/discard (nur Entwürfe), GET …/email (Vorschlag für die Mahn-E-Mail) und POST …/send (fehlende Felder aus dem Vorschlag; 409 conflict mit sender-reconnect-required, wenn das Postfach neu verbunden werden muss), POST /dunning/reminders/regenerate-unsent, POST /dunning/open-items/{openItemId}/extension (Fristverlängerung mit dueDate und reason) und POST /dunning/run (Mahnlauf, 202). Festschreiben, neu erzeugen, E-Mail und Versand verlangen eine handelnde Person (no-acting-user). Neues Ereignis dunning.reminder.finalized, auch als Auslöser der Automationen.

v1.174.0 · 18. Oktober 2026

  • Neu: Mahnstufen-Sets und Stufen, die ersten schreibenden Endpunkte im Bereich Mahnwesen. GET und POST /dunning/profiles (seedPreset legt die Standardstufen an), GET, PATCH (isDefault: true macht ein Set zum Standard) und DELETE /dunning/profiles/{id} (archiviert), POST /dunning/profiles/{id}/duplicate; Stufen POST /dunning/profiles/{id}/levels, PATCH und DELETE /dunning/levels/{id}, PUT /dunning/profiles/{id}/level-order, PUT …/sepa-return-level und PUT …/extension-levels/{variant} (pre-final, post-final; ohne Felder die Vorlage). Set eines Kontakts: GET und PUT /dunning/contacts/{contactId}/profile. Texte der Stufen mit Du-Fassungen (…Informal). Rechte dunning:read und dunning:write.

v1.173.0 · 18. Oktober 2026

  • Neu: Ereignis subscriptions.subscription.ended, wenn ein Abo tatsächlich zu Ende ist: am Tag nach dem letzten bezahlten Tag, auf jedem Weg (Kündigung, vorgemerktes Ende, Abo-Wechsel, erschöpfte Laufzeit), einmal je Ende. Nutzlast subscription, endedAt (Beginn des Tages nach dem letzten bezahlten Tag) und reason (cancelled oder completed). Gedacht für „Zugang wegnehmen“; es hängt am Ende, nicht an der Kündigung. Ausserdem meldet subscriptions.subscription.cancelled jetzt auch ein vorgemerktes Vertragsende (Marktplatz zum Laufzeitende); dort bleibt status bis zum Ende ACTIVE, es zählt cancelEffectiveDate.

v1.172.0 · 18. Oktober 2026

  • Neu: Abonnements. GET /subscriptions (Filter status, contactId, due), GET und PATCH /subscriptions/{id} (autoSend, ownDirectDebitOffered), POST /subscriptions/{id}/pause, /resume und /cancel (zum Ende der zuletzt abgerechneten Periode, ohne Erstattung), PUT /subscriptions/{id}/payment-method (Stripe-Zahlungsmittel pinnen oder mit null auf Überweisung; bei MOLLIE endet damit das Mandat, mandateOutcome) und POST /subscriptions/generate-due (fällige Folgerechnungen jetzt erzeugen). Neue Ereignisse subscriptions.subscription.paused, .resumed und .cancelled (gekündigt auch im Kundenportal), auch als Auslöser der Automationen. Rechte subscriptions:read und subscriptions:write.

v1.171.1 · 18. Oktober 2026

  • Zugangs-Hooks nehmen nur noch öffentliche https-Adressen an: keine Zugangsdaten in der Adresse, kein interner Rechnername, keine private IP-Adresse, auch nicht nach der DNS-Auflösung. POST /checkout/hooks, PATCH /checkout/hooks/{id} und POST /checkout/hooks/{id}/test antworten sonst mit 422 validation-failed und url-not-allowed (oder dns-failed, wenn der Name nicht auflöst). Zugestellt wird ohne Weiterleitung und nur an eine beim Verbinden geprüfte Adresse.

v1.171.0 · 18. Oktober 2026

  • Neu: Zugangs-Hooks der Faktura. Ein Hook benachrichtigt ein fremdes System bei Zahlungen (onIntentSucceeded, onPaymentCompleted, onPaymentFailed), etwa um einen Kurs freizuschalten oder zu sperren. GET und POST /checkout/hooks, GET, PATCH und DELETE /checkout/hooks/{id}, POST /checkout/hooks/{id}/rotate-secret, DELETE /checkout/hooks/{id}/secret, POST /checkout/hooks/{id}/reactivate und POST /checkout/hooks/{id}/test (202). Das Geheimnis kommt nur heraus, wenn claritos es erzeugt (generateSecret beim Anlegen, rotate-secret ohne eigenes), und nur in dieser Antwort; sonst steht hasSecret. Zuweisen je Ziel: GET und PUT /checkout/hook-assignments/{targetType}/{targetId} mit checkout-link, article, quote oder order. Verwalten verlangt eine Person mit ORG_ADMIN (no-acting-user bzw. forbidden), Lesen und Zuweisen nicht.

v1.170.0 · 18. Oktober 2026

  • Neu: Rabattcodes des Checkouts. GET und POST /checkout/discount-codes, GET, PATCH und DELETE /checkout/discount-codes/{id}: Abzug in Prozent (PERCENT, percent) oder fest in Cents (FIXED, amountCents), wahlweise Zeitraum, Höchstzahl der Einlösungen, Partner und Bindung an einzelne Checkout-Links (checkoutLinkIds, leer = alle). Ohne code erzeugt claritos einen lesbaren Code, auf Wunsch mit codePrefix. Filter code zeigt, ob ein Code vergeben ist, checkoutLinkId die Codes, die für einen Link gelten. Ein eingelöster Code lässt sich nicht löschen (409 conflict mit redeemed; dann active: false). Rechte checkout:read und checkout:write.

v1.169.0 · 18. Oktober 2026

  • Neu: Checkout-Links. GET und POST /checkout-links, GET, PATCH und DELETE /checkout-links/{id}: Links mit Artikel, Preis in Cents, Zielpublikum, abgefragten Angaben, Zahlungsanbieter (STRIPE oder MOLLIE), eigener Lastschrift, Zusatzangeboten (bumps), Zahlungsplänen (plans) und Angeboten nach dem Kauf (upsells); Listen ersetzen beim Schreiben die vorhandenen. Löschen geht nur ohne Rechnungen (sonst 409 conflict mit has-invoices; dann active: false). POST /checkout-links/{id}/personal-links erzeugt einen persönlichen Link für einen Kontakt, sieben Tage gültig. GET und PATCH /checkout/settings: Standard-Rechnungsersteller der Organisation. Rechte checkout:read und checkout:write; nur BUSINESS- und HOLDING-Organisationen.

v1.168.0 · 18. Oktober 2026

  • Neue Rechte für die Faktura: checkout:read/checkout:write (Checkout-Links, Rabattcodes, persönliche Links, Zugangs-Hooks), subscriptions:read/subscriptions:write (Abonnements), credits:read/credits:write (Credits-Programm) und dunning:write (Mahnwesen). Sie sind vorbereitet für die Endpunkte, die folgen; bis dahin geben sie keinen Zugriff. Bestehende Schlüssel und OAuth-Zugänge bekommen sie nicht von selbst.

v1.167.0 · 17. Oktober 2026

  • Neu: Vorgaben für den claritos Live-Raum. An der Terminart liveRoom mit classId (Klasse für Breakouts „Nach Untergruppen“) und summarizeBreakouts, in POST /appointment-types und PATCH /appointment-types/{id} und in jeder Antwort einer Terminart. Am Termin GET und PUT /appointments/{id}/live-room: Klasse, Aufzeichnen und Zusammenfassung der Breakouts überschreiben oder mit TYPE auf die Terminart zurücksetzen, dazu was gilt (effective).

v1.166.1 · 16. Oktober 2026

  • API-MCP (/api/mcp/v1, /api/mcp/v1/compact, je auch /o/{orgId}): GET antwortet jetzt mit 405 Method Not Allowed und Allow: POST, OPTIONS. Der Server arbeitet zustandslos und sendet nichts von sich aus; bisher öffnete GET einen Stream, der bis zum Zeitlimit offen blieb. MCP-Clients behandeln 405 wie vorgesehen als „kein Stream“ und arbeiten mit POST weiter. Ohne Zugang bleibt es bei 401 mit WWW-Authenticate.

v1.166.0 · 15. Oktober 2026

  • Neu: check.overallScore, der Gesamt-Spam-Score einer Kampagne in Prozent (0 bis 100, null ohne Prüfung): Technik aus Rspamds Punkten an seinen Schwellen (4 Punkte 25 %, 6 Punkte 50 %, 15 Punkte 100 %, dazwischen linear) und Inhalt aus der KI-Prüfung, verbunden als 1 − (1 − Technik)(1 − Inhalt), bei zwei Fassungen die schlechtere. Neu in spamReports[].report.symbols[].origin: testSend für Regeln, die nur der Messversand an claritos erzeugt; sie zählen im Gesamtwert nicht. Verhalten: Rote Befunde sperren den Start nicht mehr. POST /email-campaigns/{id}/start verlangt bei roten wie bei gelben Befunden confirmWarnings: true (sonst 422 precondition-failed mit campaign-check-warnings); campaign-check-red entsteht nicht mehr. Eine geplante Kampagne hält vor dem Termin nur noch an, wenn sich der Inhalt seit der Prüfung geändert hat und die neue Prüfung Hinweise bringt.

v1.165.1 · 15. Oktober 2026

  • Text: In GET /email-campaigns/setup heisst eine Untergruppe einer Klasse in smartLists[].name jetzt „Klasse › Gruppe“, damit gleichnamige Gruppen verschiedener Klassen zu unterscheiden sind. Die Kennung und die Empfänger bleiben gleich.

v1.165.0 · 15. Oktober 2026

  • Neu: zusammengestellte Listen (etwa Klassen) unter /contact-lists. Eine Liste besteht aus einzeln gewählten Personenkontakten und lässt sich in benannte Untergruppen gliedern; jede Person steht in höchstens einer Untergruppe. GET /contact-lists (seitenweise, mit memberCount und Untergruppen), GET /contact-lists/{id} (Untergruppen mit contactIds, dazu withoutSubgroup), POST, PATCH, DELETE /contact-lists/{id}; Untergruppen über POST /contact-lists/{id}/subgroups, PATCH/DELETE /contact-lists/{id}/subgroups/{subgroupId} und PUT /contact-lists/{id}/subgroups/order; Mitglieder über POST /contact-lists/{id}/members (mit subgroupId), POST /contact-lists/{id}/members/from-selection (tags, smartListIds), PUT /contact-lists/{id}/members/subgroup und POST /contact-lists/{id}/members/remove. Lesen mit contacts:read; ändern die Person, die die Liste angelegt hat, oder ORG_ADMIN (sonst forbidden, ohne handelnde Person no-acting-user). Gründe: 409 conflict mit subgroup-name-taken, 422 precondition-failed mit too-many (über 2000 Mitglieder oder 100 Untergruppen). Unternehmen werden nicht Mitglied (notPerson).

v1.164.0 · 15. Oktober 2026

  • Neu: check.contentReports je Fassung, der Bericht der Inhaltsprüfung mit KI: score (0 bis 100, keine Prozentangabe), zone (none, low, elevated, high) und findings mit category, strength (slight, clear, strong) und quote (wörtlich aus Betreff oder Text). Den Score rechnet claritos aus den Funden nach festem Raster. In check.findings[].rule neu kiRisiko (yellow, ab elevated, value = Score) und kiGering (info, value = Score); die Regeln kiGewinn bis kiUnserioes aus 1.162.0 entstehen nicht mehr, ältere Prüfungen tragen sie weiter. Ausserdem neu in der Schnellprüfung betreffAntwort (yellow, Betreff beginnt mit „Re:“ oder „Fwd:“) und linkTextTaeuscht (yellow, Linktext nennt eine andere Domain als das Ziel).

v1.163.0 · 15. Oktober 2026

  • Neu: GET und PUT /organization/security-txt lesen und setzen die Adresse für Meldungen zu Sicherheitslücken (email). Ist sie gesetzt, liefern die eigenen Domains der Organisation /.well-known/security.txt nach RFC 9116; null entfernt sie. Setzen nur mit einer Person mit ORG_ADMIN, eine ungültige Adresse ergibt 422.

v1.162.0 · 14. Oktober 2026

  • Neu: sieben Werte für check.findings[].rule der Kampagnen. kiGewinn, kiGesundheit, kiDruck, kiUebertreibung und kiUnserioes (immer level yellow, value ist das Zitat aus dem Text) melden Gewinn- und Heilversprechen, Druck, Übertreibung und unseriöse Sprache, die eine Inhaltsprüfung mit KI im Betreff oder Text der Vorlage fand; kiOk und kiFehler (info) sagen, dass sie nichts fand oder nicht lief. Auf Production erst, sobald die Datenschutzerklärung es nennt; bis dahin kommen diese Werte dort nicht vor.

v1.161.0 · 14. Oktober 2026

  • Neu: „Meine Postfächer“. GET /mailboxes/mine nennt die Postfächer, die die handelnde Person öffnen darf (personal und gemeinsame mit Zugriff). GET /mailboxes/{key}/messages listet einen Ordner (inbox, sent, archive, spam, trash), GET /mailboxes/{key}/messages/{folder}/{uid} liest eine Nachricht, POST /mailboxes/{key}/messages/update setzt Merker, verschiebt oder entfernt aus dem Postfach. POST /mailboxes/attachments gibt eine signierte Adresse für einen Anhang, POST /mailboxes/{key}/send sendet von diesem Postfach (persönlich oder gemeinsam) über das SendGrid-Konto der Organisation, mit Beleg im Postausgang. Gründe bei 422 precondition-failed: invalid-recipients, attachment-not-uploaded, send-failed.

v1.160.0 · 14. Oktober 2026

  • Verhalten, Spec gleich: Post aus Postfächern, die der Nutzer hinter dem Zugang nicht sehen darf (Regel aus GET /mailboxes), fehlt jetzt in GET /inbox/threads und den übrigen Posteingangs-Endpunkten, im Gespräch am Kontakt (/contacts/{id}/conversation, auch Marken, Karte und Antwort) und im Postausgang (GET /outbound-emails, GET /outbound-emails/{id}, POST /outbound-emails/{id}/resend). Ein Faden ohne sichtbare Nachricht und ein solcher Beleg gelten als nicht vorhanden (404). Ein Schlüssel ohne handelnde Person sieht nur Postfächer, die alle Rollen sehen. Ohne eingeschränkte Postfächer ändert sich nichts.

v1.159.0 · 14. Oktober 2026

  • Neu: Postfächer. GET /mailboxes listet persönliche und gemeinsame Postfächer auf der Domain für persönliche E-Mails mit Adresse und Zugriffsregel (access.roles, access.rolesWithRecordAccess, access.users); POST /mailboxes, PATCH /mailboxes/{id} und DELETE /mailboxes/{id} legen gemeinsame Postfächer wie info@ an, ändern und entfernen sie (nur ORG_ADMIN). GET /mailboxes/personal/me zeigt das eigene persönliche Postfach, PUT /mailboxes/personal/{userId}/access legt fest, wer seine Post sieht (das eigene jede Person, ein fremdes nur ORG_ADMIN). Gründe bei 422 precondition-failed: no-personal-domain, invalid-local-part, display-name-required, not-a-member; eine vergebene Adresse ist 409 conflict mit address-taken. Die Regel wirkt auf Posteingang, Postausgang und Gespräch erst mit einer der nächsten Versionen; bis dahin sieht jeder alles wie bisher.
  • Text: mood an den Fäden des Posteingangs beschreibt jetzt die Stimmung der zuletzt eingestuften eingegangenen Mail, nicht nur einer Antwort. Eingestuft wird künftig jede echte Zuschrift, ausser Spam und Rundmails (auf Production erst, sobald die Datenschutzerklärung es nennt).

v1.158.0 · 13. Oktober 2026

  • POST /organization/invitations nimmt deliverTo: Liegt email auf der Domain für persönliche E-Mails der Organisation, gibt es das Postfach erst nach der Annahme; die Einladung geht dann an deliverTo (Pflicht, sonst 422 am Feld), und der Name vor dem @ muss frei sein (409 conflict, reason: mailbox-taken). Einladungen führen deliveredTo (sonst null).

v1.157.0 · 13. Oktober 2026

  • Verhalten, Spec gleich: Einträge, die jemand in einem Kalender-Gerät (Thunderbird, iPhone, CalDAV) anlegt, sind jetzt eigene Termine der Person, keine Abwesenheiten mehr, ausser ihre Kategorie lautet Urlaub, Krank, Fortbildung oder Abwesend. Die Abwesenheiten einer Ressource (GET /appointment-resources/{id}) zeigen eigene Termine deshalb nicht mehr; sie sperren die Zeit weiter (ausser „Frei“). Wer einen eigenen Termin über PUT /appointment-resources/{id}/absences/{absenceId} ändert, macht ihn zur Abwesenheit.

v1.156.0 · 13. Oktober 2026

  • Neu: projectId an POST /appointments. Terminarten mit Abrechnung QUOTA lassen sich jetzt aus dem Haus vergeben (Owner-Vorgabe: von aussen bucht sie weiter nur der Kunde im Portal). Pflicht ist dann das Projekt des Kunden, dessen freies Zeitbudget die Dauer trägt; die Dauer wird beim Anlegen reserviert. Fehlt das Projekt, gehört es nicht dem Kunden oder reicht das Budget nicht, 400 an body.projectId. Als Reihe, Gruppentermin oder Serie antwortet die API 422 mit precondition-failed und Grund quota-single-only (bisher quota-portal-only, das bleibt für Buchungslinks).

v1.155.0 · 13. Oktober 2026

  • GET/PATCH /organization/letterhead führen cancellationRefundDays: die Frist in Tagen (0 bis 365), die eine Stornorechnung für die Erstattung einer schon bezahlten Rechnung nennt. Vorgabe des Storno-Dialogs; ausserhalb des Bereichs 422 am Feld.

v1.154.0 · 13. Oktober 2026

  • Stornorechnungen (kind: CANCELLATION), auch über POST /invoices/{id}/cancel: Nur das Verhalten ändert sich, die Felder bleiben. Eine neue Stornorechnung hat bankTransferEnabled: false statt des Werts der Originalrechnung. paymentTermsText trägt einen festen Satz in Sprache und Anrede der Rechnung: War die Rechnung noch nicht bezahlt, dass nichts zu tun ist; sonst bis zu welchem Tag der gezahlte Betrag erstattet wird. Der offene Posten der Erstattung an den Kunden wird zu diesem Tag fällig statt sofort. Die Frist kommt aus der Vorgabe der Organisation (14 Tage, wenn nichts eingestellt ist); einen Parameter am Endpunkt gibt es dafür nicht. Ältere Stornorechnungen bleiben unverändert.

v1.153.0 · 13. Oktober 2026

  • finAPI: PUT /finapi/accounts/{externalAccountId}/connection meldet precondition-failed mit reason: finapi-terms-consent, solange die Organisation § 11 Abs. 5 der Nutzungsbedingungen (Bankanbindung über finAPI) noch nicht zugestimmt hat. Das betrifft nur Kunden, die vor dem 13.10.2026 abgeschlossen haben, bis zum Wirksamwerden der Änderung bei ihnen (FI.134). Zugestimmt wird in claritos beim Verbinden der Bank (setupUrl von GET /finapi); die API nimmt keine Zustimmung entgegen.

v1.152.0 · 13. Oktober 2026

  • Neu GET /documents/{id}/related (Recht documents:read): die verbundenen Dokumente eines Dokuments, wie im Betrachter unter „Verbundene Dokumente“. Je Eintrag id, title, mimeType, createdAt und relation: session (Sitzungsdokument), recording (Aufzeichnung der Sitzung), split-original/split-part (Original und Teil einer Trennung), signed (signierte Fassung), signing-original (Original vor der Signatur), same-email (Anhang derselben E-Mail), same-appointment (Dokument desselben Termins). Jedes Dokument einmal; was der Schlüssel nicht sehen darf, fehlt (wie bei GET /documents).

v1.151.0 · 13. Oktober 2026

  • SendGrid: Die Domain der Terminkonten darf die der persönlichen Mails sein (SV.147). Dann müssen Namen der Personen und Marken der Ressourcen zusammen eindeutig sein; sonst conflict mit reason: address-taken (an PUT /sendgrid/domains/{id}/calendar und PUT /sendgrid/domains/{id}/personal mit localParts, an PUT /sendgrid/my-sender-name ohne). Die Gründe sendgrid-domain-is-personal und sendgrid-domain-is-calendar entfallen.
  • SendGrid: Feld automaticSecurity an jeder Domain, receiveOnDomain beim Anlegen (POST /sendgrid/domains) und neuer Endpunkt POST /sendgrid/domains/{id}/recreate (SV.148). Die Domain der persönlichen Mails und der Terminkonten empfängt auf sich selbst; Antworten gehen an dieselbe Adresse, von der geschrieben wurde. Das geht bei SendGrid nur ohne „Automatic Security“ (Einträge MX und TXT statt CNAME; MX-Einträge tragen priority), sonst precondition-failed mit reason: sendgrid-domain-automatic-security.
  • SendGrid: POST /sendgrid/domains/{id}/replies an jeder Domain (SV.149). An einer Domain, die weder persönliche Mails noch Terminkonten trägt, liegt der Host unterhalb der Domain, und Antworten etwa auf Kampagnen landen im Posteingang der Organisation; Kampagnen nennen dann diese Adresse als Antwortadresse. In Production erst, wenn die Datenschutzerklärung es nennt (precondition-failed, reason: sendgrid-replies-not-released).

v1.150.0 · 12. Oktober 2026

  • Neu: guests beim Anlegen eines Einzeltermins (POST /appointments, POST /appointment-recurrences): Name und E-Mail je Gast, höchstens maxGuests der Terminart. Die Gäste entstehen im selben Vorgang und bekommen eine eigene Einladung mit dem Kunden als Einladendem; bei einer Terminreihe auch an den Folgeterminen. Ohne Gäste an der Terminart oder beim Gruppentermin 400.

v1.149.0 · 12. Oktober 2026

  • Neu: accountEmail im Kalender-Abo einer Ressource (/appointment-resources/{id}/calendar-feed): die E-Mail-Adresse ihres Terminkontos (Mitarbeiter, Raum, Gerät), sonst null. Räume und Geräte beantworten Einladungen an diese Adresse selbst; Terminpost geht, wo es ein Terminkonto gibt, von ihr hinaus.

v1.148.0 · 12. Oktober 2026

  • SendGrid: Kalender-Domain für die Terminkonten. Feld calendar an jeder Domain, calendarAvailable am Stand (GET /sendgrid) und PUT /sendgrid/domains/{id}/calendar (enabled): höchstens eine Domain je Organisation, nie die der persönlichen Mails, nur bestätigt und ohne MX, der woanders hinzeigt. POST /sendgrid/domains/{id}/replies richtet an dieser Domain den Empfang auf der Domain selbst ein (host wird dann nicht gelesen). Neue Gründe für precondition-failed: sendgrid-calendar-not-released, sendgrid-domain-is-personal, sendgrid-domain-is-calendar, sendgrid-domain-foreign-mx, dns-unavailable. Schaltbar nur mit den Rechten für Terminkonten und E-Mail-Kampagnen, in Production noch nicht (calendarAvailable: false).

v1.147.0 · 12. Oktober 2026

  • Neu: Abo-Feed je Ressource. GET/POST/PATCH/DELETE /appointment-resources/{id}/calendar-feed: Stand, eine neue geheime ICS-Adresse (nur in der Antwort von POST, eine bisherige gilt danach nicht mehr), Kundennamen ein oder aus, beenden. Ohne Freischaltung 412 mit calendar-feed-not-enabled.

v1.146.0 · 12. Oktober 2026

  • GET /organization/entitlements kennt das neue Recht TERMINKONTEN (Abo-Feed, CalDAV und eigene Adressen für Ressourcen). Es wirkt nur zusammen mit E_MAIL_KAMPAGNEN; fehlt das, ist effective falsch.

v1.145.0 · 12. Oktober 2026

  • Neu: Termine einer Serie verschieben, ohne die Kette zu brechen. POST /appointments/{id}/series-proposal sagt, ob eine neue Zeit passt, sonst den erlaubten Zeitraum und die gebuchten Folgeschritte neu gelegt; POST /appointments/{id}/reschedule-with-series verschiebt alle nach dem Vorschlag. Geändert: POST /appointments/{id}/reschedule lehnt eine Zeit, die die Kette bricht, mit 412 und series-chain-broken ab (vorher verschob es ohne Prüfung).

v1.144.0 · 12. Oktober 2026

  • Neu: GET /appointment-series listet laufende Serien mit Stand (offene Schritte zuerst, openStep.passed, nächster Termin) und POST /appointment-series/{id}/cancel-from sagt einen Termin und alle folgenden Schritte ab; die Serie endet, der Kunde bekommt eine Absage, die die übrigen Termine nennt.

v1.143.0 · 12. Oktober 2026

  • Neu: Kunden starten eine Terminserie selbst. POST /appointment-series-templates/{id}/start-links mit contactId liefert den persönlichen Link (/t/serie/…), einen je Kunde und Vorlage; dort sieht der Kunde einen Vorschlag (bei STEPWISE nur Schritt 1) und bucht mit einem Klick. Geändert: clientBookable wirkt jetzt auch bei ADVANCE und wird so gespeichert, wie es kommt (vorher bei ADVANCE als false). Ohne clientBookable 412 mit series-not-client-bookable.

v1.142.0 · 12. Oktober 2026

  • Neu: Klienten buchen die Folgeschritte einer Serie selbst. Vorlagen nehmen und liefern clientBookable (nur zusammen mit bookingMode STEPWISE wirksam, bei ADVANCE als false gespeichert), Serien liefern es mit. Öffnet sich ein Schritt, bekommt der Kunde eine E-Mail mit einem Buchungslink, der nur Zeiten im Zeitraum des Schritts zeigt, und vor dessen Ende eine Erinnerung.

v1.141.0 · 12. Oktober 2026

  • Neu: Terminserien Schritt für Schritt. Vorlagen und Serien tragen bookingMode (ADVANCE wie bisher, STEPWISE: zuerst nur Schritt 1, jeder weitere öffnet sich, wenn der vorige stattgefunden hat). POST /appointment-series nimmt bei STEPWISE genau einen Eintrag (vorher mindestens zwei); POST /appointment-series/proposal schlägt dann nur Schritt 1 vor. GET /appointment-series/{id} liefert zusätzlich contactId, progress und openStep (Zeitraum des offenen Schritts). Neu POST /appointment-series/{id}/steps/{step}/proposal (freie Zeiten im Zeitraum) und POST /appointment-series/{id}/steps/{step} (bucht den offenen Schritt; nicht offen 412 mit series-step-not-open, ausserhalb des Zeitraums 422 an body.startsAt).

v1.140.0 · 12. Oktober 2026

  • Neu: Terminserien (Folge verschiedener Terminarten mit Korridoren). GET/POST /appointment-series-templates, PATCH /appointment-series-templates/{id} (Schritte mit appointmentTypeId, durationMinutes, fromDay/toDay nach dem vorigen Schritt, samePersonAsStep), POST /appointment-series/proposal (früheste vollständige Folge ab from, bucht nichts; ohne Platz 412 mit series-no-slots), POST /appointment-series (im Voraus, alles oder nichts) und GET /appointment-series/{id}.

v1.139.0 · 12. Oktober 2026

  • Neu: GET /appointments/{id}/waitlist (Warteliste eines Events: state WAITING, OFFERED, ACCEPTED, EXPIRED, DECLINED, REMOVED, dazu position und offerExpiresAt). Verhalten: Ist bei einem Event mit Warteliste ein Platz frei geworden, bekommt der Erste auf der Liste ein Angebot mit Frist; solange es offen ist, hält es den Platz, auch gegenüber Buchungen über den Link.

v1.138.0 · 12. Oktober 2026

  • Terminreihen: POST /appointment-recurrences/{id}/change-from (appointmentId, startsAt, rule, end, optional Dauer, Ort, Leistung, Nummer, Person, Auslassen): neue Reihe ab einer neuen ersten Zeit mit den Kunden des genannten Termins, der und die folgenden alten Termine werden abgesagt; Antwort die neue Reihe. Verhalten: Bei cancel-from und change-from gehen Termine nur noch dann ohne eigene Absage, wenn jeder ihrer Kunden die Sammel-Mail bekommt; bei Events bekommt jeder Termin seine eigene Absage.

v1.137.0 · 12. Oktober 2026

  • Terminreihen: POST /appointment-recurrences/{id}/end (beenden, die angelegten Termine bleiben), POST /appointment-recurrences/{id}/cancel-from (appointmentId, optional reason: diesen und alle folgenden absagen; der Kunde bekommt EINE Absage, die die übrigen aufzählt) und PATCH /appointment-recurrences/{id} (end ändern, etwa verlängern; nicht vor Angelegtem, sonst 422 mit too_small). Verhalten: Die Bestätigung des ersten Termins einer Reihe nennt die Regel in Worten.

v1.136.0 · 12. Oktober 2026

  • Neu: Terminreihen (wiederkehrende Termine, jede Terminart). POST /appointment-recurrences legt eine an: Felder des ersten Termins wie POST /appointments, dazu rule (weekly mit Abstand 1 bis 4 und Tagen mit Uhrzeit, monthlyWeekday mit n-tem oder letztem Wochentag, monthlyDay), end (count 2 bis 200, until bis zwei Jahre, open) und skipHolidays/skipClosures (Vorgabe an). Gerechnet in der Zeitzone der Terminart; die weiteren Termine entstehen im Hintergrund ohne eigene Bestätigung. GET /appointment-recurrences/{id} liefert Regel, Zustand, anstehende Termine und ausgelassene mit Grund. Termine tragen neu recurrenceId. Ungültige Regel oder Ende: 422 an body.rule bzw. body.end.

v1.135.0 · 12. Oktober 2026

  • Events (Gruppentermine mit internalOnly: false, kein Unterricht): POST /appointments darf bei einem Event ohne participants gerufen werden, der Termin entsteht dann mit freien Plätzen; eine Auswahl, die niemanden ergibt, antwortet weiter 422 mit too_small. DELETE /appointments/{id}/participants/{contactId} trägt beim Event auch den letzten Teilnehmer aus (kein last-participant). Kunden buchen über den Buchungslink einen Platz in einem angelegten Termin; /appointment-types/{id}/slots zeigt unverändert, wann das Haus einen Termin anlegen kann.

v1.134.0 · 12. Oktober 2026

  • Terminarten: neue Felder minParticipants, minParticipantsHours, minParticipantsAction (NOTIFY, CANCEL), waitlistEnabled, waitlistOfferHours (lesen und schreiben; Mindestzahl und Warteliste für Gruppentermine, Warteliste nur bei Events). internalOnly gibt bei Gruppen jetzt den gespeicherten Wert: false heisst Event (Kunden buchen einen Platz), Unterricht bleibt intern. Kontingent nur beim Einzeltermin (422 mit quota_group). Ungültige Werte: 422 mit minimum_invalid, minimum_hours_invalid, waitlist_hours_invalid.

v1.133.0 · 12. Oktober 2026

  • Kontingent-Termine: neues Feld quota am Termin (projectId, minutes, state: HELD, CONSUMED, RELEASED; null ohne Kontingent) und POST /appointments/{id}/quota/release (Grund 3 bis 500 Zeichen) gibt reservierte Zeit mit Protokoll frei; ohne offene Reservierung 422 mit quota-not-held. Nach dem Meeting kommt die tatsächliche Zoom-Zeit als Zeiteintrag ins Projekt, die Reservierung geht auf CONSUMED.

v1.132.0 · 12. Oktober 2026

  • Kontingent-Termine bucht nur der Kunde im Portal (Owner-Vorgabe): POST /appointments mit einer Terminart im Modus QUOTA antwortet jetzt 422 mit precondition-failed und Grund quota-portal-only, statt einen Termin ohne Projekt anzulegen. Eine Absage (POST /appointments/{id}/cancel) gibt die reservierte Zeit des Projekts frei; eine Verschiebung mit anderer Dauer passt die Reservierung an.

v1.131.0 · 12. Oktober 2026

  • Terminarten im Modus QUOTA (Kontingent): Beim Schreiben (POST/PATCH /appointment-types) gelten jetzt Ort nur online (places: ["ONLINE"]) und beide Zoom-Schalter an (recording.autoRecord, recording.fetchZoomRecordings), unabhängig von der Eingabe. Die Besetzung (PUT /appointment-types/{id}/staffing) einer solchen Terminart verlangt bei jeder Person meetingProvider: "ZOOM" und keine Partner-Rolle; sonst 422 mit Code quota_zoom_required bzw. quota_partner. Buchbar wird das Kontingent mit der Portal-Strecke in einer späteren Version.

v1.130.0 · 12. Oktober 2026

  • Rechnungen und Angebote: neues Feld contactEmail (Text oder null), die E-Mail-Adresse des verknüpften Kontakts; null ohne Kontakt oder ohne Adresse. In GET /invoices, GET /quotes, den Einzelabrufen und Antworten und in den Ereignissen invoices.invoice.* und quotes.quote.*.
  • Ereignisse payments.checkout.*: neue Felder im Objekt checkout: checkoutLinkName (Titel des Checkout-Links, also das Produkt; null ohne Titel), customerName (Kontakt der Rechnung, sonst die Angabe im Checkout), orderId und orderNumber (Auftrag der Rechnung, sonst null) und nur bei payments.checkout.failed failureReason: direct_debit_failed (Lastschrift geplatzt), chargeback (zurückgebucht), no_mandate (kein Mandat) oder payment_failed (anderer Grund). Bestehende Felder bleiben.

v1.129.0 · 12. Oktober 2026

  • Aufgaben: neues Feld contactEmail (Text oder null), die E-Mail-Adresse des verknüpften Kontakts; null ohne Kontakt oder ohne Adresse. In GET /tasks, GET /tasks/{id}, den Antworten auf Anlegen und Ändern und in den Ereignissen tasks.task.*. Damit finden Abläufe ohne Kontakt-Kennung den Kontakt über seine Adresse.

v1.128.0 · 12. Oktober 2026

  • API-MCP für Sprachmodelle: Beim Verbinden schickt der Server einen Überblick über claritos mit (instructions: Bereiche in Gruppen mit je einem Satz und der Zahl der Endpunkte, die der Zugang nutzen darf, Regeln, typische Abläufe). Neues Werkzeug guide (Überblick, ein Bereich mit seinen Endpunkten oder ein Leitfaden von /developers). Die Feldbeschreibungen der Werkzeuge kommen jetzt als Text; vorher standen dort Übersetzungsschlüssel wie apiDocs.fields.common.limit. Neue Adresse /api/mcp/v1/compact (je Organisation /api/mcp/v1/compact/o/{orgId}) mit vier Werkzeugen statt eines je Endpunkt: guide, search_endpoints, describe_endpoint, call_endpoint; gleiche Anmeldung, Rechte, Limits und dasselbe Protokoll. /api/mcp/v1 und /api/v1 bleiben unverändert.

v1.127.0 · 12. Oktober 2026

  • Neu: GET /call-guides/options (callguides.options, nur ORG_ADMIN) liefert in einem Aufruf alles, was der Leitfaden-Editor für Aktionen und Felder anbietet: Vorlagen (sms, promotional), Mitglieder, persönliche Checkout-Links, Formulare, Werbemittel, Terminarten mit holders und Kontaktfelder (fixed, standard, custom) samt Optionen. Die Kennungen und Schlüssel gehen in den Inhalt von POST /call-guides und PATCH /call-guides/{id}.

v1.126.0 · 12. Oktober 2026

  • Neu: Telefonate lesen (Bereich calls, nur lesen, jedes Mitglied). GET /calls listet die Telefonate neu nach alt (Filter missed, messages, withoutContact, contactId für Inhaber der Nummer oder Gesprächspartner, Suche q, updatedSince), GET /calls/{id} liest eines. Die Felder decken sich mit dem Ereignis calls.call.ended, dazu Anrufbeantworter und Stand der Gesprächsnotiz. Notiz (note) und automatische Gesprächsnotiz (callNote) sind Klientendaten: ihr Text nur mit Freigabe der Organisation und clients:-Recht, sonst null mit hasNote/hasCallNote.

v1.125.0 · 12. Oktober 2026

  • Briefe: POST /letters/{id}/finalize (festschreiben ohne Versand), POST /letters/{id}/duplicate (Kopie als Entwurf), DELETE /letters/{id} (nicht bei vergebener Nummer, 409 numbered-no-delete), POST /letters/{id}/cancel-signature (laufende Signatur abbrechen, 409 signature-completed bei abgeschlossener) und POST /letters/{id}/number (laufende Nummer vergeben, 202, das PDF wird neu erzeugt). Postausgang: POST /outbound-emails/{id}/resend sendet eine Mail erneut, wahlweise an eine andere Adresse oder mit geändertem Text, mit eigenem Beleg; nicht bei Code-Belegen, geschwärzten Stellen, Kampagnen und anonymisierten Belegen (409 not-resendable).
  • Ausgestellte Dokumente aus PDF-Vorlagen (Zertifikate): GET /issued-documents, GET /issued-documents/{id}, POST /issued-documents, DELETE /issued-documents/{id} (nur Entwürfe), POST /issued-documents/{id}/finalize, POST /issued-documents/{id}/retry-file, POST /issued-documents/{id}/cancel (nur ORG_ADMIN) und POST /issued-documents/{id}/letter (Brief mit dem Dokument als Anlage vorbereiten). Ausstellen darf, wer Briefe schreibt (ORG_ADMIN, ORG_USER), wie in der Oberfläche.
  • Posteingang: GET /inbox/threads, GET /inbox/threads/{id}, PATCH /inbox/threads/{id} (gelesen, archiviert, zuständige Person, Kontakt, Tags), GET /inbox/tags, GET /inbox/counts und POST /inbox/threads/{id}/task (Aufgabe aus dem Faden, braucht zusätzlich tasks:write). Anhänge als Dokument-Kennung (documents.downloadUrl). Fäden eines Kontakts mit Klientenakte nur bei Freigabe der Klientendaten und clients:read.
  • Gespräch am Kontakt: GET /contacts/{id}/conversation (Verlauf über E-Mail, SMS, Portal- und Akte-Post, Telefonate), GET /contacts/{id}/conversation/{source}/{entryId} und …/reply-basis, GET /contacts/{id}/conversation/compose (Absender, Vorlagen, Erlaubnis), GET /contacts/{id}/conversation/permission, POST /contacts/{id}/conversation/email, POST /contacts/{id}/conversation/portal-post (clients:write), POST /contacts/{id}/conversation/sms und POST /contacts/{id}/conversation/sms-preview. Lesen markiert nichts als gelesen; werblich nur mit Einwilligung. Neuer Grund für precondition-failed: client-record-missing.

v1.124.0 · 12. Oktober 2026

  • Terminarten: neues Feld startWindows (lesen und in POST/PATCH /appointment-types schreiben): wann ein Termin dieser Art beginnen darf, je Eintrag days (1 = Montag bis 7 = Sonntag), earliest und latest (HH:MM in der Zeitzone der Terminart, beide eingeschlossen), höchstens 14; null oder [] hebt sie auf. /appointment-types/{id}/slots bietet danach nur noch Zeiten darin an, Buchung und Umbuchung durch den Kunden halten sich daran. Ungültig: 422 mit Pfad body.startWindows.

v1.123.0 · 12. Oktober 2026

  • Logos und Art der Organisation: GET /organization/logos, POST /organization/logos/{kind}/upload (Format und Grösse prüfen, signierte Adresse für den direkten Upload), POST /organization/logos/{kind}/confirm und DELETE /organization/logos/{kind}, je für logo und invoice-logo; für SVG und WebP entsteht wie in der Oberfläche eine PNG-Fassung für Mails. PATCH /organization nimmt zusätzlich type (BUSINESS, HOUSEHOLD, HOLDING); eine private Organisation behält ihre Art (409 conflict, reason: private-organization). Ändern mit organization:write und einer Person, die ORG_ADMIN ist.

v1.122.0 · 12. Oktober 2026

  • Gäste eines Einzeltermins: POST /appointments/{id}/guests (Name, E-Mail) lädt einen Gast im Namen des Buchers ein, DELETE /appointments/{id}/guests/{contactId} lädt ihn aus (er bekommt „Einladung zurückgenommen“, der Termin bleibt). Recht appointments:write und eine Person mit „Terminplanung verwalten“. Neues Feld isGuest an participants. Neue Gründe für precondition-failed: group-appointment-has-no-guests, guest-limit-reached.

v1.121.0 · 12. Oktober 2026

  • Freischaltungen, Integrationen und eigene Domains der Organisation: GET /organization/entitlements (jedes Recht mit Lizenz, Freigabe, Wirkung), GET /organization/integrations (Stand jeder Anbindung mit der Seite zum Verbinden; LeadConnector heisst dort leadconnector), GET/POST /organization/domains, POST /organization/domains/{purpose}/verify und DELETE /organization/domains/{purpose} (Zweck app, finder, marketplace; Antwort nennt die fehlenden DNS-Einträge). Alles mit einer Person, die ORG_ADMIN ist; eigene Domains brauchen die Freigabe durch claritos, eine fremde Domain antwortet 409 conflict mit reason: taken.

v1.120.0 · 12. Oktober 2026

  • Dokumente: Jedes Dokument trägt extracted.counterpartyDetails (Anschrift mit street, postalCode, city, country als ISO-Code, dazu email, phone, website und contactPerson mit name, email, phone, position), wie die KI sie aus dem Dokument liest; null, wenn nichts erkannt wurde. Neu POST /documents/{id}/counterparty-contact (Rechte documents:write und contacts:write): verknüpft das Dokument mit dem Kontakt seiner Gegenpartei, wie „Als Kontakt anlegen“ in der App. Ein schon verknüpfter bleibt; sonst ein Kontakt mit genau diesem Namen, eine passende Firma (USt-IdNr., Register, Domain, Name) oder ein neuer mit der Anschrift. Antwort { contactId, created }; ohne Gegenpartei 409 conflict mit reason: no-counterparty.

v1.119.0 · 12. Oktober 2026

  • Neu: empfangene SMS lesen. GET /inbound-sms listet die SMS, die an die Nummer der Organisation geschickt wurden (neu nach alt, Seiten wie GET /sms, Filter contactId, updatedSince heisst hier empfangen seit), mit Kontakt, Art der Zuordnung (number, personBeforeCompany, ambiguous, unknown, manual) und Twilios Abmeldewort; GET /inbound-sms/{id} liest eine. Bereich sms, Recht sms:read.

v1.118.0 · 12. Oktober 2026

  • Anrede und Rechtstexte der Organisation: GET/PATCH /organization/salutation (Sie oder Du als Vorgabe, Du für einzelne Kontakte, Sie-Pflicht je Belegart, Grussform), GET/PATCH /organization/legal-texts (alle Rechtstexte samt Standard, Datenschutzbeauftragte Stelle und Aufsichtsbehörde), PUT/DELETE /organization/legal-texts/{kind} (eigenen Text setzen, Version steigt; zurück auf den Standard). Lesen mit organization:read, ändern mit organization:write und einer Person, die ORG_ADMIN ist. Eine private Organisation hat keine Rechtstexte (403 feature-not-available).

v1.117.0 · 12. Oktober 2026

  • Kontakt, Öffnungszeiten und Briefkopf der Organisation: GET/PATCH /organization/contact (Besuchsanschrift, Telefon, E-Mail für Website und Portal), GET/PUT /organization/opening-hours (je Wochentag bis zu zwei Spannen) und GET/PATCH /organization/letterhead (Geschäftspapier: Rechtsname, Rechtsform, Anschrift, Steuer- und Registerdaten, Geschäftsführung, Bank, Briefbogen-Form, Artikel für Zeitabrechnung und Rücklastschrift). Lesen mit organization:read, ändern mit organization:write und einer Person, die ORG_ADMIN ist; PATCH ändert nur Mitgesendetes, geprüft wird wie in den Einstellungen (422 mit Feld).

v1.116.0 · 12. Oktober 2026

  • Nur die Darstellung, kein Endpunkt geändert: Die Spec ordnet die Bereiche in Gruppen (x-tagGroups, etwa „Kontakte und Klienten“, „Verkauf und Rechnungen“). Jeder Tag trägt einen Anzeigenamen (x-displayName) und als Beschreibung einen Satz, wofür der Bereich da ist. Die Tag-Namen selbst (contacts, invoices …) bleiben, wie sie sind.

v1.115.0 · 12. Oktober 2026

  • Terminarten: neues Feld maxGuests (lesen und in POST/PATCH /appointment-types schreiben): wie viele weitere Personen der Bucher zu seinem Termin einladen darf, 0 bis 20, nur bei einem Platz (sonst immer 0). Ungültig: 422 mit Code guests_invalid.

v1.114.0 · 12. Oktober 2026

  • Mitglieder und Einladungen schreiben (Recht members:write, Person mit ORG_ADMIN wie im Reiter „Mitglieder“): PATCH /organization/members/{userId} (Rolle ORG_ADMIN/ORG_USER, Sichtbarkeit, Aktenzugriff, Übersetzer-Sprachen), DELETE /organization/members/{userId}, POST /organization/invitations (Einladung per E-Mail, Link sieben Tage gültig) und DELETE /organization/invitations/{id}. Die handelnde Person ändert und entfernt sich nie selbst (403 forbidden, reason: self), der letzte ORG_ADMIN bleibt (409 conflict, reason: last-admin); schon Mitglied oder offen eingeladen antwortet 409 conflict mit reason: already-member bzw. already-invited.

v1.113.0 · 12. Oktober 2026

  • Postkonten über die API (Bereich letters): GET /postal-account (über welchen Anbieter die Warteschlange versendet, sein Guthaben, Pause, wartende Briefe; ORG_ADMIN sieht in accounts zusätzlich LetterXpress und Pingen im Einzelnen) und POST /postal-account/resume-queue (Pause aufheben, wartende Briefe versenden, 202). Verbunden und getrennt werden LetterXpress und Pingen nur in der Oberfläche; ihre Zugangsdaten nimmt die API nicht an.

v1.112.0 · 12. Oktober 2026

  • Meta-Datensätze lesen: GET /organization/meta-datasets (Pixel und Conversions API: Name, Pixel-Kennung, Testcode, hasToken), mit organization:read und einer Person, die ORG_ADMIN ist. Den Token gibt die API nie heraus; Anlegen und Ändern bleibt der Oberfläche vorbehalten, wie bei SendGrid.

v1.111.0 · 12. Oktober 2026

  • Das Marken-Board über die API (Bereich sites): Boards mit GET/POST /sites/brands, GET/PATCH/DELETE /sites/brands/{id}, POST /sites/brands/{id}/default und POST /sites/brands/{id}/publish; Schriften mit GET/POST /sites/brands/{id}/fonts (eigene Schrift, Adresse zum Hochladen), POST /sites/brands/{id}/fonts/google (Google-Schrift importieren, Suche über GET /sites/google-fonts) und DELETE /sites/brands/{id}/fonts/{fontId}; Logos mit GET /sites/brands/{id}/logos, POST/DELETE /sites/brands/{id}/logos/{slot}. PATCH ändert nur, was mitkommt (Objekte werden zusammengeführt). Lesen mit sites:read, schreiben mit sites:write und einer Person, die ORG_ADMIN ist (wie im Marken-Board). Das letzte Board lässt sich nicht löschen (409, last-board), eine schon importierte Schrift antwortet 409 mit font-already-imported. Die KI-Berater des Marken-Boards bleiben in der Oberfläche.

v1.110.0 · 12. Oktober 2026

  • Bankverbindungen (Bereich banking): GET /bank-connections und GET /bank-connections/{id} (bei WISE mit öffentlichem Schlüssel), POST /bank-connections/{id}/sync (Kontoauszüge abrufen), GET /revolut (Stand der Einrichtung samt Adresse in claritos), GET /revolut/accounts und PUT /revolut/accounts/{externalAccountId}/connection (Konto eines freigegebenen Zugangs anbinden), GET /finapi, PUT /finapi/accounts/{externalAccountId}/connection und POST /finapi/banks/{bankConnection}/refresh. Verbinden mit einem Schlüssel, die Anmeldung bei Revolut oder finAPI und das Trennen bleiben in claritos; kein Schlüssel und keine Bankanmeldung geht über die API.

v1.109.0 · 12. Oktober 2026

  • Neu: Telefonie und SMS-Absender einrichten (Bereich telephony, nur ORG_ADMIN). GET /telephony zeigt Konto, Sprachweg, alle Nummern und die Einstellungen der aktiven; POST /telephony/setup richtet den Sprachweg ein; POST /telephony/numbers aktiviert eine Nummer (mit Rückfrage activated: false, wenn dort schon ein anderes System steht, bestätigt mit overwrite: true); GET/PATCH/DELETE /telephony/numbers/{id} lesen, ändern (streng, Gesprächsnotiz nur mit callNotesNoticeConfirmed: true) und deaktivieren; Ansage über POST /telephony/numbers/{id}/greeting/upload, PUT und DELETE /telephony/numbers/{id}/greeting. Twilio: GET /telephony/twilio, GET /telephony/twilio/numbers, PUT /telephony/twilio/sender, POST /telephony/twilio/inbound. Das Twilio-Konto verbindet und trennt nur die Oberfläche (settingsUrl); fremde Adressen an einer Nummer nennt die API nur als Host.

v1.108.0 · 12. Oktober 2026

  • Affiliate-Einstellungen der Organisation über die API (Bereich affiliates): Gutschein-Codes mit GET/POST /affiliate-coupons, GET/PATCH/DELETE /affiliate-coupons/{id} (an- und ausschalten über active), Attributions-Tracking mit GET /affiliate-tracking (Adresse des Conversion-Webhooks, Zugangsdaten nur maskiert) und DELETE /affiliate-tracking/webhook (abschalten), Klimabeitrag mit GET/PUT /affiliate-climate-contribution (0, 50, 100 oder 150 Basispunkte). Lesen mit affiliates:read, schreiben mit affiliates:write und einer Person, die ORG_ADMIN ist (wie im Reiter). Zugangsdaten des Conversion-Webhooks erzeugt und zeigt die API nicht: Das geht nur in der Oberfläche. Ein schon vergebener Gutschein-Code antwortet 409 mit dem Grund coupon-code-taken.

v1.107.0 · 12. Oktober 2026

  • Datensicherung und Einwilligungs-Protokoll der Organisation: GET /backups (Einstellungen und die letzten 20 Läufe), PATCH /backups/settings (Intervall, Umfang, Empfänger), POST /backups/runs (Sicherung anstossen, 202 mit dem Lauf), GET /backups/runs/{id} und PUT /backups/password (Archiv-Passwort setzen oder mit null entfernen; es wird nie ausgegeben). Dazu GET /consent-log, GET /consent-log/summary und GET /consent-log/export (CSV), nur lesend. Rechte backups:read/backups:write und consentlog:read, alles nur für eine Person mit ORG_ADMIN, wie im Reiter. Neue Gründe für precondition-failed: backup-running und backup-recipients-required.

v1.106.0 · 12. Oktober 2026

  • Organisation ändern: PATCH /organization (Recht organization:write, Person mit ORG_ADMIN wie in den Einstellungen) für Name, Hauptwährung, Land, Preismodus, Praxis-Zuschnitt, Branche, Eingangsadresse (inboxSlug), Antwort-Alias (replyAlias) und E-Mail-Signatur; alles oder nichts, dieselben Prüfungen wie in der Oberfläche. Ungültiges antwortet 422 mit Feld und Code, eine vergebene Eingangsadresse oder ein vergebener Antwort-Alias 409 conflict mit reason: taken, ein Praxis-Zuschnitt ohne das Modul Praxisbetrieb 403 feature-not-available. GET /organization nennt dazu neu inboxSlug, replyAlias, replyAddress, industryCode, defaultPriceMode und emailSignatureHtml.

v1.105.0 · 12. Oktober 2026

  • Postfach der Terminpost: GET /appointment-mailbox (verbundenes Gmail-Postfach, Zustand, Antwortadresse; jedes Mitglied) und DELETE /appointment-mailbox (trennen, mit dem Recht „Terminplanung verwalten“; die Terminpost geht danach mit der Adresse aus dem Geschäftspapier weiter). Verbunden wird nur in claritos (Zustimmung bei Google).

v1.104.0 · 12. Oktober 2026

  • Neue Rechte für die Einstellungen der Organisation (Endpunkte folgen in den nächsten Versionen): members:write (Mitglieder, Rollen, Einladungen; bisher war members nur lesbar), backups:read/backups:write (Datensicherung), consentlog:read (Einwilligungs-Protokoll der Website, nur lesen) telephony:read/telephony:write (Telefonie und SMS-Absender einrichten) und banking:read/banking:write (Bankverbindungen). Über OAuth bekommt die ersten vier nur, wer in der Organisation ORG_ADMIN ist, wie bei webhooks:manage; banking:read steht wie in der Oberfläche jedem Mitglied offen.
  • LeadConnector-App: drei neue Auslöser für Zahlungen, checkout_pending (Zahlung eingeleitet, bei SEPA noch kein Geld), checkout_completed (Zahlung eingegangen) und checkout_failed (gescheitert, zurückgebucht oder Rate ausgefallen), auf den Ereignissen payments.checkout.*; und die Aktion invoice-issue (Rechnung festschreiben, invoices:write), deren Antwort documents mit PDF-Status und -Adresse und der Adresse des ZUGFeRD-XML trägt, solange es erzeugt wird mit pending: xml-not-ready. Die Schnittstelle unter /api/v1 ändert sich dadurch nicht.

v1.103.0 · 12. Oktober 2026

  • Termingruppen, Partnerfreigabe und Kalender: GET/POST /appointment-groups, GET/PATCH/DELETE /appointment-groups/{id} (mehrere Terminarten auf einer Seite; wie im Reiter auch lesend nur mit dem Recht „Terminplanung verwalten“), GET/PUT /appointment-types/{id}/partner-release (Sichtbarkeit im Partnerprogramm) und GET /appointment-resources/{id}/calendars (die gewählten Google-Kalender einer Ressource, nur lesend; die Kalenderlisten der Google-Konten gibt die API nicht heraus). Damit ist der Terminbereich über API und MCP vollständig einzurichten.

v1.102.0 · 12. Oktober 2026

  • Erinnerungspläne einrichten: GET/POST /appointment-reminder-plans, GET/DELETE /appointment-reminder-plans/{id} (entfernen archiviert), POST /appointment-reminder-plans/{id}/steps, PATCH/DELETE /appointment-reminder-steps/{id}, POST /appointment-reminder-steps/{id}/move und POST /appointment-reminder-preview (Beispielwerte eingesetzt, unbekannte Variablen genannt). Die Liste nennt die Sprache der Texte und den Katalog der Variablen. Lesen mit appointments:read, einrichten mit appointments:write und einer Person, die ORG_ADMIN ist (wie im Reiter). Ein Text mit unbekannter Variable antwortet 422 mit dem Code unknown_variable.

v1.101.0 · 12. Oktober 2026

  • Schliesszeiten und Orte einrichten: GET/POST /appointment-closures, PATCH/DELETE /appointment-closures/{id} (Feiertag, Brückentag, Betriebsferien, Sonstiges; ganztägig oder mit Zeitfenster; affectedAppointments zählt bestehende Termine im Zeitraum, die bleiben), PUT /appointment-bridge-day-rule (an allen Brückentagen geschlossen), POST /appointment-closures/{id}/keep-open und DELETE /appointment-bridge-day-rule/kept-open/{date} (einen Brückentag offen halten oder wieder schliessen), GET /appointment-places, POST/PATCH/DELETE /appointment-phones[/{id}], POST/PATCH/DELETE /appointment-venues[/{id}] und PUT /appointment-venues/{id}/groups (Räume und Geräte, die an einer Adresse frei sein müssen). Lesen mit appointments:read, schreiben mit appointments:write und dem Recht „Terminplanung verwalten“. Eine noch gewählte Nummer oder Adresse antwortet beim Löschen 409 mit in-use. Neuer Grund für precondition-failed: closure-automatic.

v1.100.0 · 12. Oktober 2026

  • SendGrid einrichten über die API (Bereich campaigns): GET /sendgrid (Recht, Verbindung, fehlende Rechte des Schlüssels, Rückmeldungen und je Absender-Domain die DNS-Einträge, DMARC, persönliche Mails, Antworten), POST /sendgrid/events, POST /sendgrid/domains (gibt die zu setzenden DNS-Einträge zurück), POST /sendgrid/domains/{id}/verify, DELETE /sendgrid/domains/{id}, PUT /sendgrid/domains/{id}/personal, POST/DELETE /sendgrid/domains/{id}/replies und POST /sendgrid/domains/{id}/replies/verify (Antworten über Inbound Parse, mit dem MX-Eintrag in replies.mxRecord) sowie GET/PUT /sendgrid/my-sender-name (der eigene Name vor dem @, für jedes Mitglied). Den SendGrid-Schlüssel nimmt die API nicht an: Verbunden und getrennt wird nur in der Oberfläche. Alles an der Organisation verlangt ORG_ADMIN; einrichten zusätzlich das Recht „E-Mail-Kampagnen“, Nachsehen und Entfernen gehen auch ohne. Neue Gründe in 422 precondition-failed: sendgrid-domain-not-in-account, sendgrid-key-invalid, sendgrid-unreachable, sendgrid-rejected, sendgrid-events-failed, sendgrid-personal-not-released, sendgrid-domain-not-confirmed, sendgrid-domain-not-personal, sendgrid-parse-scopes-missing (mit missingScopes), replies-not-configured, sendgrid-policy-forbidden, sendgrid-parse-failed, sendgrid-replies-not-set-up.

v1.99.0 · 12. Oktober 2026

  • Automationen schreiben (Recht automations:write, handelnde Person ORG_ADMIN): POST /automations (ausgeschaltet angelegt), PATCH /automations/{id} (fehlende Teile bleiben, neue Fassung), DELETE /automations/{id}, POST …/activate und POST …/deactivate sowie POST /automation-runs/{id}/resume für gescheiterte Läufe. Fehler im Ablauf kommen als 422 validation-failed mit Ort (body.flow.nodes.‹knoten›.fields.‹feld›) und Code. Neu zum Lesen: GET /automation-catalog mit Auslösern (Filter, Platzhalter), Datumsquellen und den Aktionen samt Feldern.

v1.98.0 · 12. Oktober 2026

  • Ressourcen einrichten: POST /appointment-resources und PATCH /appointment-resources/{id} (dieselbe Prüfung wie der Ressourcen-Dialog), GET …/availability, PUT …/schedule (Musterplan im Zyklus von 1 bis 4 Wochen), POST …/absences sowie PUT und DELETE …/absences/{absenceId} (Urlaub, Fortbildung, Krankheit, Sondersprechstunde), GET und POST …/closure-overrides sowie DELETE …/closure-overrides/{overrideId} (an einem geschlossenen Tag doch arbeiten), GET …/working-hours (Vorschau der nächsten Wochen), GET und PUT …/meeting-defaults (Zoom-Nutzer, eigene Nummer) und GET …/zoom-users. Rechte wie in der Oberfläche: wer die Termine verwaltet, an jeder Ressource; die Person an ihrer eigenen (nur Zeitzone, nicht Name, Marke und Aktiv; als Zoom-Nutzer nur den mit der eigenen Adresse); ihre eigene Verfügbarkeit legt jedes Mitglied an. Ein Mensch, der schon Ressource ist, antwortet 409 mit already-resource. Neuer Grund für precondition-failed: zoom-unavailable.

v1.97.0 · 12. Oktober 2026

  • Neu: Automationen lesen (Bereich automations, Recht automations:read): GET /automations, GET /automations/{id} mit Ablauf (flow: Knoten mit kind und next, Bedingungen, Wartezeiten; eine Aktion heisst wie ihr Endpunkt, etwa tasks.create), GET /automations/{id}/runs (letzte 100 Läufe mit Schritten, failedOnly) und GET /automations/{id}/stats (90 Tage, je Knoten erreicht, gescheitert, Ausgänge, wartend). Anlegen und Ändern folgen.

v1.96.0 · 12. Oktober 2026

  • Terminarten einrichten: POST /appointment-types und PATCH /appointment-types/{id} (dieselbe Prüfung wie der Terminart-Dialog; PATCH ändert nur die genannten Felder), GET und PUT /appointment-types/{id}/staffing (Besetzung: Rollen, Bewerber, Verteilung, Anwesenheit, Video-Werkzeug je Person), GET und POST /appointment-types/{id}/links sowie POST /appointment-links/{id}/revoke (Buchungslinks). Lesen mit appointments:read, Schreiben mit appointments:write und einer Person mit dem Recht „Terminplanung verwalten“. Ein vergebener Kurzname antwortet 409 mit slug-taken. Neue Gründe für precondition-failed: appointment-type-not-public, quota-portal-only.

v1.95.0 · 12. Oktober 2026

  • E-Mail-Kampagnen über die API (Bereich campaigns, Pfad /email-campaigns, weil /campaigns die Affiliate-Kampagnen sind): GET /email-campaigns/setup (SendGrid verbunden, Rückmeldungen, bestätigte Domains, werbliche Vorlagen, Smart-Listen, Tags, eigene Adressen für die Testmail), GET/POST /email-campaigns, GET/PATCH/DELETE /email-campaigns/{id}, POST /email-campaigns/recipient-count, POST /email-campaigns/{id}/check (Prüfung mit Rspamd und Messversand im Hintergrund, 202), POST /email-campaigns/{id}/test-email (nur an eigene Adressen der handelnden Person, höchstens zehn je Stunde, sonst 429), POST /email-campaigns/{id}/start (sofort oder mit scheduledAt; Gelb nur mit confirmWarnings) sowie /pause, /resume, /cancel. Jeder Endpunkt, auch zum Lesen, verlangt ORG_ADMIN (403 forbidden, ohne Anleger 403 no-acting-user) und das Recht „E-Mail-Kampagnen“ der Organisation (403 feature-not-available). Neue Gründe in 422 precondition-failed: campaign-check-missing, campaign-check-outdated, campaign-check-red, campaign-check-warnings, sendgrid-not-connected, sendgrid-events-missing, sendgrid-not-ready, campaign-template-missing, campaign-template-not-marketing, campaign-selection-empty, campaign-smart-list-unknown; ein Wechsel, den der Stand nicht erlaubt, antwortet 409 mit wrong-status.

v1.94.0 · 12. Oktober 2026

  • Webhook-Ziele vollständig über die API (Recht webhooks:manage): POST /webhook-targets (mit Geheimnis in der Antwort), PATCH und DELETE /webhook-targets/{id}, POST …/rotate-secret, GET …/secret, POST …/test (synchron, mit Beispieldaten oder einem Kontakt; mit Kontakt auch contacts:read), GET …/deliveries/{deliveryId}/body (auch contacts:read) und POST …/deliveries/{deliveryId}/retry.
  • Neu: Eingangs-Hooks über die API (/inbound-hooks, Recht webhooks:manage): auflisten, anlegen (Zustand LEARNING, wahlweise mit verlangtem Authorization-Kopf), lesen, ändern (Name, recordTypes, mapping, state), löschen, Adresse erneuern, verlangten Kopf lesen, Muster mit Pfadliste (GET …/sample, auch contacts:read), Zustellungen, Rumpf einer Zustellung (auch contacts:read) und erneut verarbeiten.

v1.93.0 · 12. Oktober 2026

  • Termine schreiben (Recht appointments:write): POST /appointments (vergeben, Einzeltermin mit contactId, Gruppentermin mit participants aus Smart-Listen, Tags und Kontakten), POST /appointments/{id}/cancel, /reschedule, /host, /type, /no-show, /participants, DELETE /appointments/{id}/participants/{contactId} und POST /appointments/{id}/meeting (Video-Link erneuern). Dieselben Prüfungen und dieselbe Terminpost wie im Haus. Jeder dieser Aufrufe verlangt eine Person mit dem Recht „Terminplanung verwalten“ (Eigentümer, ORG_ADMIN oder Einzelrecht): ohne Person no-acting-user, ohne Recht forbidden. Belegte Zeit antwortet 409 mit slot-taken. Neue Gründe für precondition-failed: contact-without-phone, appointment-not-open, appointment-not-started, not-a-group-appointment, last-participant.

v1.92.0 · 12. Oktober 2026

  • Nummernkreise und PDF-Vorlagen im Bereich templates: GET/POST /number-circles, GET/PATCH /number-circles/{id} (Präfix, 6 bis 12 Stellen, Jahres-Neubeginn, dazu issued und die nächste Nummer; hat ein Kreis Nummern vergeben, sind Präfix, Stellen und Jahres-Neubeginn fest, 409 mit format-locked), GET/POST /pdf-templates, GET/PATCH /pdf-templates/{id} (Name, Nummernkreis, Gültigkeit in Monaten, bis zu vier Unterzeichner-Plätze) und PUT /pdf-templates/{id}/fields (die vollständige Feldliste, geprüft wie in der Oberfläche; der erste Fehler kommt als 422 validation-failed mit dem Grund im Code, z. B. bindingUnknown oder numberWithoutCircle). Eine PDF-Vorlage entsteht auf einem PDF, das vorher über documents hochgeladen und bestätigt wurde. Schreiben nur, wenn die Person hinter dem Zugang ORG_ADMIN ist. Gelöscht wird weder ein Kreis noch eine Vorlage: active: false legt still.

v1.91.0 · 12. Oktober 2026

  • OAuth: Das Recht webhooks:manage bekommt ein OAuth-Zugang nur noch, wenn sein Nutzer in der gebundenen Organisation ORG_ADMIN ist, wie in der Oberfläche. Geprüft wird bei der Zustimmung und bei jedem Aufruf; verliert der Nutzer die Rolle, fehlt das Recht ab dem nächsten Aufruf (403 insufficient-scope). Die Zustimmungsseite zeigt es für Nicht-Admins gesperrt. API-Schlüssel sind nicht betroffen, sie legt nur ein ORG_ADMIN an. Die Beschreibung der Endpunkte ist unverändert.

v1.90.0 · 12. Oktober 2026

  • Termine lesen (Recht appointments:read): GET /appointments (Liste nach Beginn, Filter nach Zeitraum, Status, Terminart, Ressource und Kontakt), GET /appointments/{id} (in derselben Form wie die Webhooks appointments.appointment.*, dazu Plätze, Teilnehmer und Halter), GET /appointment-types und GET /appointment-types/{id} (alle Einstellungen samt Art Einzeltermin, Gruppentermin oder Unterricht und Leistungen), GET /appointment-resources und GET /appointment-resources/{id}, GET /appointment-types/{id}/slots (freie Zeiten wie bei der Vergabe aus dem Haus, höchstens 62 Tage je Abfrage). Termine mit Laboranforderung erscheinen nur mit Freigabe für Klientendaten, sonst fehlen sie und der Einzelabruf antwortet 404. Schreiben und Einrichten folgen in den nächsten Versionen.

v1.89.0 · 12. Oktober 2026

  • Vorlagen über die API (Bereich templates): GET/POST /message-templates, GET/PATCH /message-templates/{id} für E-Mail- und SMS-Vorlagen (Sie- und Du-Fassung, Einsatz contacts oder partnerPortal, purpose transactional oder marketing), dazu GET/POST /letter-templates, GET/PATCH /letter-templates/{id} für Brief-Vorlagen (mit Nummernkreis für {{brief.nummer}}). Lesen mit templates:read, schreiben mit templates:write, und nur wenn die Person hinter dem Zugang ORG_ADMIN ist (sonst 403 forbidden, ein Schlüssel ohne Anleger 403 no-acting-user). Es gibt kein Löschen: active: false legt still. Unbekannte Platzhalter in Vorlagen für Kontakte lehnt das Speichern mit 422 ab.

v1.88.0 · 12. Oktober 2026

  • Video-Räume (/rooms, Rechte rooms:read/rooms:write): GET /rooms und GET /rooms/{id} (mit Gastgeber- und Gast-Link, solange der Raum offen ist), POST /rooms/instant (Sofort-Meeting am Kontakt, Gastgeber ist der Anleger des Schlüssels), POST /rooms/{id}/participant-links (persönlicher Link für den eingeladenen Kontakt bzw. einen Teilnehmer des Termins), POST /rooms/{id}/close (nur Sofort-Meetings; Räume an Terminen schliessen mit der Absage, sonst 409 mit appointment-room), GET /rooms/{id}/recordings (Videoaufzeichnungen und Gespräche mit documentId) sowie GET/PATCH /rooms/settings (Schalter „Zusammenfassung“, ändern nur ORG_ADMIN). Sicht wie bei den Konferenz-Dokumenten (1.85.0): ORG_ADMIN sieht alle Räume, andere nur die, deren Gastgeber sie sind; ein Schlüssel ohne Anleger sieht keine. Neuer Grund room-not-configured in 422 precondition-failed; ohne das Recht „Live-Raum“ der Organisation 403 feature-not-available.

v1.87.0 · 12. Oktober 2026

  • Drei neue Bereiche mit Lese- und Schreibrecht: rooms (Video-Räume), templates (Brief-, E-Mail-, SMS- und PDF-Vorlagen samt Nummernkreisen) und campaigns (E-Mail-Kampagnen). Die Endpunkte folgen in den nächsten Versionen; bis dahin geben die Rechte noch keinen Zugriff. Vorlagen und Kampagnen haben eigene Rechte, weil email:write nur das Senden erlaubt, nicht das Einrichten oder den Massenversand.
  • Zwei neue Fehlerarten, beide 403: no-acting-user, wenn eine Aktion eine handelnde Person verlangt (Rolle, Einzelrecht, Autor) und der Zugang keine hat (API-Schlüssel ohne Anleger), und forbidden, wenn die Person des Zugangs in der Organisation nicht das Recht hat, das die Oberfläche verlangt. Beim Schlüssel ist die Person, wer ihn angelegt hat, beim OAuth-Zugang der angemeldete Nutzer. Bestehende Endpunkte ändern ihre Antworten nicht.

v1.86.0 · 12. Oktober 2026

  • Neuer Bereich appointments (Termine) mit den Rechten appointments:read und appointments:write. Die Endpunkte folgen in den nächsten Versionen; bis dahin gibt das Recht noch keinen Zugriff. Termine, an denen eine Laboranforderung hängt, gelten wie in den Webhooks als Klientendaten: Sie erscheinen nur, wenn die Organisation Klientendaten für die API freigegeben hat und der Zugang ein clients:-Recht trägt.

v1.85.0 · 12. Oktober 2026

  • Dokumente: Konferenz-Dokumente (Aufzeichnungen und Zusammenfassungen des Live-Raums) sieht nur, wer in der Organisation ORG_ADMIN ist oder beim Gespräch Gastgeber war. Für einen API-Schlüssel zählt der Nutzer, der ihn angelegt hat; ein Schlüssel ohne Anleger sieht keine. Unter GET /documents fehlen diese Dokumente dann, GET /documents/{id} antwortet 404. Die Beschreibung der Endpunkte ist unverändert, deshalb steht es hier. Die Ereignisse documents.* gehen weiter an die Webhooks der Organisation, die nur ein ORG_ADMIN einrichtet.

v1.84.0 · 11. Oktober 2026

  • Neues Ereignis letters.email.received: Eine E-Mail ist über die SendGrid-Antwortadresse der Organisation eingegangen und wurde eingestuft. email trägt id, conversationId, from, subject, receivedAt, sentiment (positive, neutral, negative, null, wenn die Einstufung scheiterte), contactId (oder null) und campaignId, wenn die Mail auf eine Kampagne antwortet (sonst null). Ohne Mailtext. Gemeldet erst nach der Einstufung; Mails über den Resend-Posteingang (Belege, Weiterleitungen) melden es nicht. In den Automationen ist es der Auslöser „E-Mail eingegangen“ mit Filtern nach Stufe und Kampagne.

v1.83.0 · 11. Oktober 2026

  • Gesprächsleitfäden (/call-guides): content.results legt Ergebnisse an, benannte Enden mit id, name und optional color (höchstens 20, Name höchstens 80 Zeichen), und result an einem Schritt (type: point) oder an einer Antwort verweist auf eines. Es gilt nur an einem Ende; an anderer Stelle bleibt es stehen und wird ignoriert, eine unbekannte Kennung fällt beim Lesen weg. Ein Ergebnis ohne Namen lehnt das Speichern mit 422 und dem Code ergebnis-ohne-name ab. Bisher gingen Ergebnisse, die im Editor angelegt waren, bei einem Update über die API verloren.

v1.82.0 · 11. Oktober 2026

  • callguides.run.completed trägt jetzt guideRun.resultId und guideRun.resultName: das benannte Ergebnis des Endes, an dem der Lauf ankam (etwa „Termin vereinbart“). Ergebnisse legt die Organisation im Leitfaden an und ordnet sie einem Punkt ohne Nachfolger oder einer Antwort zu, die ins Ende führt. Kennung und Name stammen aus der Fassung, mit der das Gespräch lief. Ohne Ergebnis an diesem Ende sind beide null; outcome (der letzte Schritt) bleibt unverändert.

v1.81.0 · 11. Oktober 2026

  • leads.lead.created trägt neben consent (Element → angehakt) jetzt consentPurposes: den Zweck je Einwilligung wie in den Formularen (1.79.0). INQUIRY ist das Pflicht-Häkchen „Kontakt zu meiner Anfrage“ und erlaubt keine Werbung, MARKETING das freiwillige Häkchen „Werbung“, null ein eigenes Häkchen oder ein älteres, das Anfrage und Werbung zusammenfasst. Wer aus dem Ereignis eine Werbe-Einwilligung ableitet, nimmt nur MARKETING (oder null) mit consent = true. Leads ohne Formular (Finder, von Hand) haben ein leeres Objekt.

v1.80.0 · 10. Oktober 2026

  • kind an SMS (GET /sms, GET /sms/{id}, Ereignisse sms.message.*) kennt den neuen Wert EINWILLIGUNG: die werbefreie Bitte, eine Einwilligung aus einem Formular per Link zu bestätigen. Sie geht über das Twilio-Konto der Organisation an den Kontakt, mit dem Namen der Organisation als Fussnote.

v1.79.0 · 10. Oktober 2026

  • Formulare: Jede Einwilligung trägt jetzt purpose, in der Formular-Definition (GET /forms/{id}) und in den Einsendungen (GET /forms/{id}/responses). INQUIRY ist das Pflicht-Häkchen „Kontakt zu meiner Anfrage“, MARKETING das freiwillige Häkchen „Werbung“, null ein eigenes Häkchen oder ein älteres, das Anfrage und Werbung zusammenfasst. Einsendungen von vor dieser Version haben null. Eine Einwilligung in Werbung ist nur MARKETING (oder ein älteres Häkchen); INQUIRY erlaubt keine Werbung.

v1.78.0 · 10. Oktober 2026

  • Neues Ereignis contacts.webhook.received: Ein Eingangs-Hook der Organisation hat einen Datensatz eines anderen Systems angenommen und verarbeitet. hook nennt Kennung und Bezeichnung, company das Unternehmen (vorhanden oder neu angelegt, sonst null), contact die Person, ohne Person das Unternehmen selbst; contactStatus und companyStatus sind new oder existing. Eingangs-Hooks entstehen in den Einstellungen unter Integrationen → Schnittstellen: eine eigene Adresse POST /api/hooks/‹kennung› (ausserhalb von /api/v1, wahlweise mit verlangtem Authorization: Bearer …), die JSON oder Formulare bis 256 KB sofort mit 202 annimmt und je Hook in einer Warteschlange verarbeitet (höchstens 60 je Minute; über 600 je Minute antwortet sie 429). Im Lernmodus wird die nächste Zustellung nur als Muster aufgefangen, an dem die Felder zugeordnet werden.

v1.77.0 · 10. Oktober 2026

  • Übergaben an andere Organisationen: neuer Bereich handovers mit den Rechten handovers:read und handovers:write (vorhandene Schlüssel haben sie nicht). GET /handover-connections listet die aktiven Verbindungen, über die diese Organisation abgeben darf (id, name, recipientName). POST /handovers mit connectionId und contactId (dazu contacts:read) kopiert den Kontakt samt Unternehmen in die empfangende Organisation und antwortet 201 mit handoverId, nie mit neu oder zusammengeführt. Fehler: 404 (connection-unknown, not-your-connection, contact-unknown), 422 precondition-failed (connection-revoked, connection-not-active), 500 (copy-failed). Bei der Empfängerin löst die Übergabe contacts.handover.received aus (seit 1.75.0); in den Automationen gibt es dafür den Filter nach Verbindung und die Aktion „An Organisation übergeben“.

v1.76.0 · 10. Oktober 2026

  • Webhook-Ziele: benannte Adressen anderer Systeme, an die ein Kontakt samt Unternehmen geschickt wird, etwa von der neuen Aktion „Webhook senden“ in den Automationen. Anders als /webhooks abonnieren Ziele keine Ereignisse. Neu: GET /webhook-targets, GET /webhook-targets/{id}, GET /webhook-targets/{id}/deliveries (Protokoll, 30 Tage, mit Anfang der Antwort) und POST /webhook-targets/{id}/send mit contactId (202, Recht webhooks:manage und contacts:read; 409 conflict mit reason: target-inactive, wenn das Ziel aus ist). Gesendet wird im Umschlag der Ereignisse mit type: contacts.contact.sent und data = { contact, company, automation, test }, signiert nach Standard Webhooks mit dem Geheimnis des Ziels, wiederholt nach 1 min, 5 min, 30 min, 2 h und 12 h, nach fünf toten Sendungen in Folge abgeschaltet. Anlegen, Ändern, Geheimnis und Test in den Einstellungen unter Integrationen → Schnittstellen.

v1.75.0 · 10. Oktober 2026

  • Neues Ereignis contacts.handover.received: Eine andere Organisation hat dieser über eine Übergabe-Verbindung einen Kontakt übergeben. contact ist der Kontakt in dieser Organisation (neu angelegt oder mit einem vorhandenen zusammengeführt), company sein Unternehmen oder null, handover nennt Übergabe, Verbindung (connectionId, connectionName) und outcome (created oder merged). Abonnierbar wie jedes Ereignis und Auslöser in den Automationen. Die Übergabe-Verbindungen selbst folgen in einer späteren Version.

v1.74.0 · 9. Oktober 2026

  • Schriftverkehr: POST /outbound-emails und POST /sms nehmen wahlweise vorlageId, die Kennung einer Vorlage aus dem Vorrat (Einsatz Kontakte). Dann kommen Betreff, Text, Du-Fassung und Sendeart aus der Vorlage, gelesen beim Versand, mit deren Platzhaltern (etwa {{person.firstName}}, {{anrede}}); wer die Vorlage ändert, ändert den nächsten Versand. Entweder vorlageId oder freier Text: Bei der E-Mail sind subject und bodyHtml nur noch ohne vorlageId Pflicht, bei der SMS body und art; mit vorlageId dürfen sie nicht mitkommen, bei der SMS ist dann contactId Pflicht. Eine E-Mail aus einer Vorlage geht wie aus dem Gespräch am Kontakt (kind: gespraech, Fuss mit Gesprächskennung, bei werblichen Vorlagen nur mit E-Mail-Einwilligung und mit Widerrufslink). Neue Gründe in 422 precondition-failed: message-template-not-found, message-template-archived (behebbar), message-template-without-sms (behebbar, nur SMS), email-ohne-einwilligung.

v1.73.0 · 8. Oktober 2026

  • Formulare: Eine Einwilligung für E-Mail oder Telefon gilt nur noch als gefragt, wenn ein Feld ihres Kanals ausgefüllt ist. Ist es leer, steht sie in consents einer Einsendung (GET /forms/{id}/responses, forms.response.submitted) und in consent von leads.lead.created nicht mehr, auch nicht als abgelehnt; ein mitgeschicktes true in POST /forms/{id}/responses wird dann nicht gespeichert. Bisher stand sie dort immer, mit accepted: false oder sogar true für eine Adresse, die es nicht gab. Freie Einwilligungen (Kanal CUSTOM) unverändert.

v1.72.0 · 8. Oktober 2026

  • Kontakte: neues Feld dateOfBirth („YYYY-MM-DD“, nur PERSON, zwischen 1900 und heute) in allen Antworten und Ereignissen der Kontakte, setzbar über POST /contacts und PATCH /contacts/{id} (null löscht). Dasselbe Format wie clients.dateOfBirth, aber am Kontakt; ein ungültiges Datum oder ein Datum an einer Firma ergibt 422 validation-failed (body.dateOfBirth).

v1.71.0 · 8. Oktober 2026

  • Neue Ereignisse für Termine: appointments.appointment.booked (bestätigt, bei Zahlungspflicht nach der Zahlung), appointments.appointment.rescheduled (mit previousStartsAt, previousEndsAt und by: customer oder provider), appointments.appointment.cancelled (mit by und reason) und appointments.appointment.noShow (vom Team markiert, mit markedByUserId). Die Nutzlast trägt den Termin unter appointment, den Kontakt unter appointment.contactId; Automationen können diese Ereignisse als Auslöser nutzen. Gemeldet werden nur bestätigte Termine. Ein Termin mit Laboranforderung geht nur an Endpunkte mit Klientendaten-Freigabe.

v1.70.0 · 8. Oktober 2026

  • Neues Ereignis calls.call.ended: ein Telefonat ist beendet, genau einmal je Telefonat. call trägt Richtung (inbound, outbound), Ergebnis (answered, missed, voicemail für unseren Anrufbeantworter, failed), Kontakt (contactId, null bei unbekannter Nummer), Gesprächspartner, Nummern, Zeiten und durationSeconds. Gesprächsnotiz, Aufnahme und Abschrift sind nie enthalten.
  • Neues Ereignis callguides.run.completed: ein Gesprächsleitfaden ist im Gespräch abgeschlossen (Hauptweg am Ende, kein Pflichtschritt offen), genau einmal je Lauf; spätere Änderungen lösen es nicht erneut aus. guideRun trägt Leitfaden (guideId), Kontakt (contactId, der Gesprächspartner oder sonst der Kontakt des Telefonats), outcome (Kennung des letzten Schritts), answers (Frage → Antwort als Kennungen), benutzte Einwände und den Weg. Notizen sind nie enthalten.

v1.69.0 · 8. Oktober 2026

  • Kontakte, neue Endpunkte für einzelne Änderungen (Aktionen der Automationen): POST /contacts/{id}/tags (tagId aus dem Vorrat oder tag als Text) und DELETE /contacts/{id}/tags/{tag} (Kennung oder Text) fügen ein Tag hinzu oder entfernen es, ohne die übrige Liste zu senden; ein vorhandenes bzw. fehlendes Tag ändert nichts und löst kein zweites Ereignis aus. POST /contacts/{id}/notes legt eine Notiz an (Klartext, gespeichert als escaptes HTML). PUT /contacts/{id}/custom-fields/{slug} setzt ein eigenes Feld (value: Text, Liste der Optionsschlüssel oder null; Felder nur in der Akte und Einwilligungen nicht). PUT /contacts/{id}/owner setzt den Zuständigen (userId eines Mitglieds oder null). Du/Sie und Standardfelder weiter über PATCH /contacts/{id}.

v1.68.0 · 8. Oktober 2026

  • Neues Ereignis funnels.funnelLead.created: ein Lead aus dem Formular eines Funnels oder einer Website, mit der Einsendung (lead.id), dem Auftritt (lead.funnelId, lead.funnelName, lead.funnelKind), der Seite des Formulars (lead.stepId, lead.stepName, lead.stepPath), dem Formular und dem Kontakt (lead.contactId). Nur Kennungen und Namen, keine Angaben der Person. Es kommt zusätzlich zu leads.lead.created und steht in Automationen als Auslöser „Lead aus einem Funnel oder einer Website“ bereit.
  • leads.lead.created aus einem Funnel trägt contactId jetzt auch dann, wenn die Einsendung einen Interessenten angelegt hat (der Kontakt des Interessenten); bisher stand dort null.

v1.67.0 · 8. Oktober 2026

  • Verträge aus Vorlage (POST /contracts): neues Feld send (Standard false, wie bisher nur Entwurf). Mit true wird der Vertrag versendet, sobald sein PDF gerendert ist; die Antwort zeigt noch den Entwurf, den Versand meldet das Ereignis esign.request.sent. Dazu optional reminderPolicy und locale wie an POST /signature-requests/{id}/send. Scheitert das Rendern oder dauert es länger als zehn Minuten, bleibt der Entwurf liegen.

v1.66.0 · 8. Oktober 2026

  • Formular-Antworten (GET /forms/{id}/responses, GET /forms/responses/{id}, Ereignis forms.response.submitted): neues Feld contactId, der Kontakt, an dem die Einsendung hängt; null, solange es keinen gibt, und bei Bögen der Klientenakte immer. Damit stehen in Automationen mit dem Auslöser „Formular abgeschickt“ die Aktionen an den Kontakt zur Verfügung.
  • Formular-Antworten: neuer Wert booking für source, eingereicht über die Buchungsstrecke eines Termins. Bisher erschienen diese Antworten als api.

v1.65.0 · 5. Oktober 2026

  • Gesprächsleitfäden: neuer Aktions-Typ consent ({ type: "consent", channel: "EMAIL" }), die Einwilligung zur E-Mail am Telefon festhalten; der Wortlaut kommt zur Laufzeit aus den Kontakten. channel ist heute nur EMAIL, jeder andere Wert ergibt 422 validation-failed.

v1.64.0 · 5. Oktober 2026

  • Gesprächsleitfäden (/call-guides) mit Aktionen und Eingaben, alles freiwillig: ein Punkt kann eine action sein (email, sms, callback, handover, checkout, appointment, form) oder mit field eine Eingabe in ein Feld des Gesprächspartners schreiben; eine Frage schreibt mit field die gewählte Antwort, bei gesetztem value an der Antwort diesen Wert (etwa den Schlüssel einer Auswahl); mandatory: true macht einen Schritt zur Pflicht; actions stellt Aktionen an den Rand des Gesprächs. Neue Prüfgründe an body.content: aktion-unvollstaendig (Vorlage oder Link fehlt, Rand-Aktion ohne Name) und action-and-field (ein Punkt mit beidem). Wer einen Leitfaden liest und zurückschreibt, behält diese Teile.

v1.63.1 · 5. Oktober 2026

  • Präzisierung zu 1.63.0 (noch nicht ausgeliefert): contactFields an Gesprächsleitfäden nimmt nur noch die Schlüssel, die das Mini-Fenster am Rand des Gesprächs zeigen kann: title, website, addressStreet, addressPostalCode, addressCity oder cf:<slug> (Kleinbuchstaben, Ziffern, _). Ein anderer Schlüssel ergibt 422 validation-failed, statt still wegzufallen.

v1.63.0 · 5. Oktober 2026

  • Gesprächsleitfäden (/call-guides) können mehr, alles freiwillig: je Schritt hint (Hinweis nur für die Person am Telefon) und cards (Hinweiskarten mit title, text, color); je Leitfaden cards (immer sichtbar), objections (Einwände mit name und start, dem ersten Schritt ihres eigenen Wegs) und contactFields (Zusatzfelder für das Mini-Fenster am Rand des Gesprächs). Platzhalter wirken auch in Hinweisen und Karten. Neue Prüfgründe an body.content: karte-leer und einwand-unvollstaendig.

v1.62.0 · 5. Oktober 2026

  • Neu: Gesprächsleitfäden der Telefonie (Checklisten mit Verzweigung fürs Telefonat). GET /call-guides, GET /call-guides/{id}, POST /call-guides und PATCH /call-guides/{id}, neue Rechte callguides:read und callguides:write; im API-MCP als Werkzeuge callguides_list, callguides_get, callguides_create und callguides_update. Ein Leitfaden hat einen start und nodes: point zum Abhaken oder question mit answers; next führt weiter (fehlt: nächster Knoten der Liste, null: Ende, Kennung: dorthin). Gespeichert wird nur ein fehlerfreier Inhalt, sonst 422 mit den Gründen an body.content. Jede Änderung an Name, Beschreibung oder Inhalt ist eine neue Fassung (version); active schaltet ohne neue Fassung.

v1.61.0 · 4. Oktober 2026

  • Pflichtfeld art an POST /sms (auch MCP letters_sendSms und die LeadConnector-Aktion sms-send): notwendig oder werblich, ohne Vorgabe; ein Aufruf ohne art antwortet 422 validation-failed an body.art. Das ist strenger als bisher, trifft aber niemanden: In Production gab es keinen einzigen Aufruf von POST /sms. Die Sendeart bestimmt den Fuss der SMS (notwendig: Name der Organisation; werblich: Name und „Keine SMS mehr? STOP antworten“), der an body angehängt wird und in der Segmentzahl mitzählt, und eine werbliche SMS geht nur an einen Kontakt (contactId) mit SMS-Einwilligung: ohne Kontakt 422 precondition-failed mit reason = sms-werblich-ohne-kontakt, ohne Einwilligung für die Nummer reason = sms-ohne-einwilligung (beide fixable: false).

v1.60.2 · 4. Oktober 2026

  • Behoben: POST /documents mit contactId verknüpft das Dokument mit diesem Kontakt, und die Verknüpfung bleibt nach der Auswertung des Dokuments erhalten. Bisher konnte die automatische Zuordnung sie überschreiben, mit dem Treffer einer Namenssuche oder mit nichts, sodass GET /documents/{id} einen anderen oder keinen Kontakt zeigte. Die automatische Zuordnung füllt jetzt nur noch, was leer ist; dasselbe gilt für PATCH /documents/{id} mit contactId und eine erneute Auswertung.

v1.60.1 · 4. Oktober 2026

  • Präzisierung zu 1.60.0, die noch nicht ausgeliefert war: Die SMS an ein Mitglied (channel: sms) fällt auf die Standard-Nummer seines Profils zurück, wenn es in dieser Organisation keine Nummer für die SMS-Bestätigung eingetragen hat, wie beim Signieren und bei Termin-Erinnerungen. member-without-phone kommt nur noch, wenn beide fehlen.

v1.60.0 · 4. Oktober 2026

  • POST /organization/members/{userId}/notifications kann auch eine SMS schicken: channel: sms geht an die Handynummer, die das Mitglied in dieser Organisation für die SMS-Bestätigung eingetragen hat, sonst an die Standard-Nummer seines Profils (dieselbe Reihenfolge wie beim Signieren und bei Termin-Erinnerungen), über das Twilio-Konto der Organisation; Text sind title und body. Fehlen beide: 422 precondition-failed, reason = member-without-phone, fixable: true; ist sie ungültig: member-phone-invalid. Die Gründe des SMS-Versands (twilio-*) gelten wie bei POST /sms (1.58.0), Netzfehler 500. Die SMS erscheint in GET /sms mit kind: API.

v1.59.0 · 4. Oktober 2026

  • kind an SMS (GET /sms, GET /sms/{id}, Ereignisse sms.message.*) kennt den neuen Wert GESPRAECH: eine SMS, die ein Mitarbeiter im Gespräch eines Kontakts von Hand geschrieben hat. Wer kind auswertet, sollte unbekannte Werte zulassen.

v1.58.0 · 4. Oktober 2026

  • POST /sms sendet nur noch über das eigene Twilio-Konto der Organisation (Organisation → Integrationen); das gilt auch für Automationen und die LeadConnector-Aktion sms-send. Ohne verbundenes Konto, ohne Absendernummer oder mit ungültigem Zugang antwortet der Aufruf 422 precondition-failed mit reason = twilio-nicht-verbunden, twilio-keine-nummer bzw. twilio-zugang-ungueltig und fixable: true; es entsteht dabei keine SMS mehr (bisher eine Zeile mit FAILED und 403 feature-not-available). Hat der Empfänger STOP gesendet: 422 precondition-failed, reason = twilio-empfaenger-gesperrt, fixable: false (oft erst im Rückruf, dann FAILED mit errorCode an der SMS). Ungültige Nummer laut Twilio: 422 validation-failed an body.to. Andere Ablehnung: 409 conflict, reason = twilio-abgelehnt. Netzfehler: 500, wiederholbar.
  • Das SMS-Kontingent von 300 je Organisation und Monat entfällt, weil jede Organisation ihre SMS seit dieser Version selbst bezahlt. 429 sms-limit-reached kommt nicht mehr vor; der Code bleibt bis v2 im Katalog.

v1.57.0 · 4. Oktober 2026

  • POST /organization/members/{userId}/notifications kann auch E-Mails schicken: channel: email geht an die Adresse des Mitglieds, mit title als Betreff, body als Text und link als Adresse in der Anwendung. Scheitert der Versand, antwortet der Aufruf 500 und darf wiederholt werden. Die Antwort trägt den verwendeten Kanal.
  • Zu den Dokumenten der Klientenakte gehören jetzt auch die Anhänge der Akte-Post (Portal-Nachrichten im Bereich Akte). Für sie gelten dieselben Regeln wie für Laborblätter und Klientenverträge (1.54.0): ohne Klientendaten-Freigabe und clients:-Recht fehlen sie in GET /documents, ein Abruf über die Kennung (auch …/download-url und PATCH) antwortet 404, und documents.document.*-Ereignisse zu ihnen gehen nur an Endpunkte mit clientsData: true.

v1.56.0 · 4. Oktober 2026

  • Neu: POST /organization/members/{userId}/notifications schickt einem Mitglied der Organisation eine Nachricht in die Glocke (mit Browser-Push, falls eingeschaltet): title, optional body und link (ein Pfad in der Anwendung). Neues Recht members:notify; Mitglieder bleiben sonst nur lesbar. Ein Nutzer, der nicht Mitglied ist, ergibt 404. Kanal ist vorerst nur channel: notification; E-Mail und SMS kommen als weitere Werte dazu.

v1.55.0 · 4. Oktober 2026

  • POST /outbound-emails nimmt eine Du-Fassung an: subjectDu und bodyHtmlDu, beide freiwillig und nur zusammen wirksam. Dann wählt claritos je Empfänger nach der Anrede-Regel (Sie-Pflicht für Briefe, persönliches Du bei OAuth, Einstellung am Kontakt, sonst Standard der Organisation), Platzhalter wie {{ansprechpartner.anrede}} folgen derselben Wahl. Fehlt eine der beiden, geht die Mail ganz in der Sie-Fassung hinaus, wie bisher. Die Wahl je Empfänger ist vorbereitet und wird für alle Organisationen zugleich eingeschaltet; bis dahin geht jede Mail in der Sie-Fassung hinaus, die Du-Fassung kann aber schon mitgeschickt werden.
  • Die Beschreibung nennt jetzt alle Fehlerantworten, die der Rahmen geben kann: 409 bei schreibenden Aufrufen (Konflikt, noch laufender Aufruf mit demselben Idempotency-Key), 413 bei Aufrufen mit Rumpf (über 1 MB) und 500 überall. Das Verhalten ist unverändert; bisher fehlten diese Codes nur in der Beschreibung.

v1.54.0 · 3. Oktober 2026

  • Webhooks mit Klientendaten gehen nur noch an freigegebene Endpunkte. Neues Feld clientsData an GET/POST/PATCH /webhooks: Nur ein Endpunkt mit clientsData: true bekommt Ereignisse mit Klientendaten, also clients.record.created, clients.record.updated, clients.message.received und die esign.request.*-Ereignisse eines Vertrags mit einem Klienten, und nur, solange die Organisation Klientendaten für die API freigegeben hat. Setzen lässt sich clientsData: true nur mit clients:read oder clients:write (sonst 403 insufficient-scope) und nur bei Freigabe (sonst 403 clients-data-not-enabled). Geprüft wird bei jedem Zustellversuch; wird die Freigabe zurückgenommen, endet eine wartende Zustellung mit FAILED und lastError = clients-data-not-allowed. Ein Replay lässt solche Ereignisse für einen nicht freigegebenen Endpunkt aus, und GET /webhooks/events/{type}/recent zeigt sie nur einem Schlüssel mit clients:-Recht. Bisher gingen clients.*-Ereignisse an jeden Endpunkt der Organisation.
  • Dokumente der Klientenakte (Laborblätter, Verträge mit Klienten) liefert /documents nur noch, wenn die Organisation Klientendaten für die API freigegeben hat und der Schlüssel ein clients:-Recht trägt; sonst fehlen sie in GET /documents, und ein Abruf über die Kennung (auch …/download-url und PATCH) antwortet 404. Bei einem Vertrag gilt dieselbe Ausnahme wie in 1.53.0: Ersteller oder Absender ist der Benutzer hinter dem Schlüssel.
  • Die Ereignisse documents.document.ready, documents.document.analyzed und documents.document.updated zu Dokumenten der Klientenakte (Laborblätter, Dokumente eines Vertrags mit einem Klienten) gelten als Klientendaten: Sie gehen nur an Endpunkte mit clientsData: true und nur bei Klientendaten-Freigabe der Organisation. Anders als beim Abruf gibt es hier keine Ausnahme für Ersteller oder Absender, weil ein Webhook keinem Benutzer gehört.

v1.53.0 · 3. Oktober 2026

  • Verträge mit Klienten nur mit Klientendaten-Freigabe: Ist an einem Vertrag oder einer Signatur-Anfrage ein Kontakt mit Klientenakte beteiligt (oder sein Vertreter), liefern GET /contracts, GET /signature-requests, die Einzelabrufe, …/events, …/pdf, …/send und …/cancel ihn nur, wenn die Organisation Klientendaten für die API freigegeben hat und der Schlüssel ein clients:-Recht trägt; sonst fehlt er in Listen, und ein Abruf über die Kennung antwortet 404. Ausnahme: Verträge, die der Benutzer hinter dem Schlüssel angelegt hat oder deren Absender er ist. Listen bleiben voll und hasMore stimmt.

v1.52.0 · 3. Oktober 2026

  • Aktenfelder in Vertragsvorlagen: Führt die Organisation die Praxis, kennen Vorlagen zusätzlich Felder der Klientenakte als <partei>.akte.<feld> (Geburtsdatum dateOfBirth, Aktennummer recordNumber, Betreuungsbeginn careStartedAt und -ende careEndedAt, eigene Felder an der Akte und Felder „nur Praxis“ als <partei>.akte.custom.<slug>). variables nennt sie. POST /contracts füllt sie nur, wenn die Organisation Klientendaten für die API freigegeben hat und der Schlüssel ein clients:-Recht trägt; sonst steht dort •••, und die Akte wird nicht gelesen.

v1.51.0 · 3. Oktober 2026

  • Vertragsvorlagen kennen mehr Variablen: Je Unternehmen, Ansprechpartner und Person stehen alle Felder des Kontakts bereit (etwa company.1.email, company.1.legalFormName, company.1.contact.1.firstName, person.1.customerNumber) und die eigenen Felder der Organisation als <partei>.custom.<slug> (etwa company.1.contact.1.custom.jahrgang). variables in GET /contract-templates nennt sie, und warnings meldet sie nicht mehr als unknown-variable. POST /contracts füllt sie aus den Kontakten. Neu ist auch countryName (Land ausgeschrieben, in der Sprache der Vorlage) neben country (Ländercode wie DE, unverändert). Bestehende Variablen bleiben alle.

v1.50.1 · 2. Oktober 2026

  • POST /contract-templates/{id}/archive antwortet mit 200 statt 201: Archivieren legt nichts an. So antworten auch die übrigen Aktionen, die nichts anlegen, etwa an Angeboten und Dokumenten.

v1.50.0 · 2. Oktober 2026

  • Vertragsvorlagen lassen sich anlegen, ändern und archivieren: POST /contract-templates, PATCH /contract-templates/{id} und POST /contract-templates/{id}/archive, Recht contracts:write, mit denselben Feldern und derselben Prüfung wie der Vorlagen-Editor. bodyHtml wird beim Speichern bereinigt: Es bleibt die Auszeichnung des Editors, Skripte, Ereignis-Attribute, Links ausser http, https, mailto und tel sowie Bilder ausserhalb der eigenen Ablage fallen weg. Die Antwort trägt warnings mit dem, was wegfiel, und mit Platzhaltern, die weder der Beteiligten-Plan noch die festen Variablen kennen (unknown-variable). Ein ungültiger Beteiligten-Plan ergibt 422, das Ändern einer archivierten Vorlage 409 (archived), eine nicht geschäftliche Organisation feature-not-available. Neu beim Lesen jeder Vorlage: anrede (AUTO, SIE, DU) und isFeeAgreement; formal bleibt.

v1.49.0 · 2. Oktober 2026

  • Ein Kontakt vom Typ PERSON mit USt-IdNr. wird abgelehnt (422 validation-failed, Pfad body.vatId, Code invalid_combination): Wer eine USt-IdNr. hat, ist ein Unternehmen. Das gilt für POST /contacts und für PATCH /contacts/{id}, wenn die Änderung einer Person eine USt-IdNr. gibt. Lege stattdessen ein Unternehmen (type: COMPANY, Rechtsform Einzelunternehmen) mit der USt-IdNr. an und die Person mit worksAtId als Ansprechpartner daran. Änderungen an Bestandskontakten, die noch als Person mit USt-IdNr. gespeichert sind, bleiben möglich, solange sie die USt-IdNr. nicht setzen.

v1.48.0 · 1. Oktober 2026

  • Mahnungen (GET /dunning/reminders, GET /dunning/reminders/{id}) können den neuen Status SUPERSEDED haben: Sie sind durch eine spätere Mahnung derselben Forderung ersetzt und nehmen kein Geld mehr an. Das geschieht, sobald die nächste Stufe festgeschrieben wird; bisher blieb die frühere auf SENT. Ausserdem lassen sich Mahnungen, die vor claritos ausserhalb verschickt wurden, nachträglich als Glied der Kette erfassen. Sie erscheinen mit status: SENT, number: null und feeCents/interestCents 0. Der portalUrl einer ersetzten oder erfassten Mahnung führt zur gültigen Mahnung oder zur Rechnung. Wer den Status auswertet, sollte SUPERSEDED wie eine erledigte Stufe behandeln, nicht als offene Zahlungsaufforderung.

v1.47.0 · 27. September 2026

  • Dokumente haben das neue Feld access mit public oder protected (GET /documents, GET /documents/{id}, PATCH /documents/{id} sowie die Webhooks documents.document.ready, .analyzed und .updated). Geschützte Dokumente liegen nicht öffentlich: Bei ihnen sind url und previewUrl immer null, auch wenn das Dokument fertig ist. Die Datei holt man über den signierten Link aus GET /documents/{id}/download-url. Heute betrifft das nur Zoom-Aufzeichnungen, die neu dazukommen. url ist ab dieser Version als veraltet markiert: Es wird später für alle Dokumente null, und GET /documents/{id}/download-url ist dann der einzige Weg zur Datei. Wer url speichert, sollte jetzt auf download-url umstellen.

v1.46.0 · 26. September 2026

  • addressForm an Formularen (GET /forms, GET /forms/{id}) kann jetzt auch AUTO liefern, neben DU und SIE. AUTO heisst: Das Formular hat keine feste Anrede, es spricht so an, wie die Organisation oder der Kontakt es festlegt. Welche Anrede eine Person tatsächlich sieht, entscheidet claritos beim Anzeigen. Neue Formulare stehen standardmässig auf AUTO, und bestehende Formulare auf DU wurden auf AUTO umgestellt, ausgenommen die Anamnese-Vorlagen, deren Fragen selbst duzen. Wer bisher alles ausser SIE als Du gelesen hat, sollte AUTO nicht als Du behandeln.

v1.45.0 · 26. September 2026

  • Geändertes Verhalten bei POST /signature-requests mit send: true und bei POST /signature-requests/{id}/send: Die Einladungen gehen jetzt immer hinaus. Ist die Gmail-Verbindung des Absenders abgelaufen, gehen sie über die claritos-Adresse, Antworten erreichen weiter den Absender. Bisher blieben sie in diesem Fall liegen, und senderInvalid war true. Deshalb ist senderInvalid seit 1.45.0 immer false, als veraltet markiert und entfällt in v2. Wer darauf etwa mit „Postfach neu verbinden“ reagiert hat, bekommt dieses Signal nicht mehr; die Verbindung wird in claritos als ungültig markiert, und ihr Inhaber wird dort zum Neuverbinden aufgefordert.

v1.44.0 · 26. September 2026

  • Kontakte tragen das neue Feld anrede: STANDARD (wie in der Organisation eingestellt), DU oder SIE. Lesbar an allen Kontakt-Endpunkten und in den Webhooks contacts.contact.created und contacts.contact.updated, schreibbar beim Anlegen und Ändern. Es wirkt nur bei Personen: Bei Firmen zählt der Ansprechpartner, geliefert wird dort immer STANDARD, und DU oder SIE an einer Firma wird mit 422 (validation-failed, Pfad body.anrede) abgelehnt.

v1.43.0 · 25. September 2026

  • Neues Feld paymentProvider an Rechnungen, Angeboten und Aufträgen sowie an deren Abschnitten: MOLLIE, wenn online über die Zahlungs-Schicht gezahlt wird, sonst null. Lesbar überall, schreibbar an Rechnung und Angebot (Kopf und Abschnitte). Es schliesst stripeEnabled aus (ein Online-Anbieter); wer von Stripe auf Mollie wechselt, setzt im selben Aufruf stripeEnabled: false. Setzen lässt es sich nur, wenn die Organisation Mollie verbunden hat, sonst validation-failed. Beim Schreiben von Abschnitten gilt: ohne Angabe kein Anbieter. Auch die Ereignisse invoices.invoice.* tragen das Feld.

v1.42.0 · 25. September 2026

  • Neues Ereignis letters.certificate.expired für Dokumente aus PDF-Vorlagen mit Gültigkeitsende (etwa ein Zertifikat, das drei Jahre gilt). Es kommt einmal, am Tag nach dem letzten Gültigkeitstag; ist ein Tages-Lauf ausgefallen, wird bis zu drei Tage nachgemeldet. Es trägt certificate (Kennung, Vorlage, Nummer, Kontakt, validUntil, signed, Prüfcode) und contact. Widerrufene Dokumente und solche mit offener Unterschrift melden nichts. Eine Erinnerung vor dem Ablauf ist kein Ereignis, sondern ein Datums-Auslöser der Automationen.

v1.41.0 · 24. September 2026

  • POST /letters/{id}/send verweigert den Versand jetzt mit 409 conflict und reason = certificate-attachment-invalid, wenn eine Anlage ein ausgestelltes Dokument (Zertifikat aus einer PDF-Vorlage) in einer Fassung ist, die nicht gilt: storniert, noch nicht unterschrieben oder durch die unterschriebene Fassung abgelöst. Bisher ging eine solche Anlage hinaus. Dieselbe Prüfung gilt für Briefe aus der Aktion „Brief aus Vorlage“.

v1.40.0 · 24. September 2026

  • Neue Endpunkte für Automationen und Integrationen. POST /letters/from-template legt einen Brief aus einer Brief-Vorlage für einen Kontakt an und stellt ihn zu, sobald sein PDF fertig ist (channel: EMAIL, POSTAL oder BOTH; Antwort 202 mit dem Brief als DRAFT). POST /outbound-emails sendet eine freie E-Mail an einen Kontakt; Betreff und Text dürfen dieselben Platzhalter tragen wie Brief-Vorlagen, der Beleg steht danach unter GET /outbound-emails mit kind = message. Fehlt am Kontakt die nötige Angabe, antworten beide mit precondition-failed und einem reason, etwa contact-without-email, contact-without-address, postal-not-connected, template-archived oder sender-invalid. Auf einen anderen Zustellweg wird nicht ausgewichen.
  • Aus einer Automation aufgerufen, erkennen beide Endpunkte ein Fortsetzen desselben Laufs: Derselbe Schritt findet denselben Brief bzw. dieselbe E-Mail wieder, statt einen zweiten anzulegen. Scheitert die Zustellung eines Briefs erst nach der Annahme (202), bekommt der handelnde Nutzer eine Benachrichtigung; eine Rückmeldung an den Aufrufer gibt es dafür noch nicht.

v1.39.0 · 24. September 2026

  • Neuer Fehler-Code precondition-failed (422): Eine Voraussetzung am Objekt fehlt, etwa eine E-Mail-Adresse am Kontakt. Die Antwort trägt reason (stabiler Code, z.B. contact-without-email) und fixable (ob sich der Fehler durch eine Änderung der Daten beheben lässt). Wer Anfragen wiederholt, nachdem er die Daten ergänzt hat, braucht einen neuen Idempotency-Key: Die Ablage merkt sich auch diese Fehlerantwort.

v1.38.0 · 24. September 2026

  • Neue Ereignisse contacts.tag.added und contacts.tag.removed: je Tag, der einem Kontakt gesetzt oder entzogen wird, ein Ereignis mit contactId und tag in derselben Form wie tagDetails (Kennung, Text, Bezeichnung, Quelle, Gruppe). Gemeldet wird erst, wenn die Änderung gespeichert ist. Eine andere Schreibweise desselben Tags ist keine Änderung. Umbenennen, Zusammenführen und Löschen in der Tag-Verwaltung lösen keine Ereignisse aus, ebenso wenig das Zusammenführen von Kontakten.

v1.37.0 · 24. September 2026

  • kind an SMS (GET /sms, GET /sms/{id}, Ereignisse sms.message.*) kennt den neuen Wert APPOINTMENT_REMINDER für Terminerinnerungen. Bisher trugen Terminerinnerungen API, obwohl sie nicht über die API gesendet wurden; ältere Erinnerungen behalten API. Terminerinnerungen zählen nicht in das SMS-Kontingent (sms-limit-reached).
  • Nachgetragen: Zwei Werte kamen ohne eigenen Eintrag in den Vertrag. (1) Seit dem 13.09. kennt der Typ eines Formularfelds (GET /forms/{id}) den Wert UPLOAD; die Antwort auf ein solches Feld ist die Kennung eines Dokuments. (2) Seit dem 24.09. kennt taxCategory an Artikeln und an den Positionen von Angeboten, Aufträgen und Rechnungen den Wert OUTSIDE_SCOPE (im Inland nicht steuerbar, § 3a UStG). Wer diese Felder vollständig auswertet, sollte beide Werte kennen.

v1.36.0 · 24. September 2026

  • Signatur-Anfragen kennen die Herkunft PDF_TEMPLATE: ein Dokument aus einer PDF-Vorlage, etwa ein Zertifikat mit laufender Nummer. Der Wert erscheint im Feld sourceKind der Anfragen unter /esign, als Filter ?sourceKind=PDF_TEMPLATE und in der Nutzlast der Ereignisse esign.request.*. Wer sourceKind vollständig auswertet, etwa in einem switch, sollte den neuen Wert aufnehmen.

v1.35.0 · 24. September 2026

  • Neuer Fehler-Code sms-limit-reached (429) an POST /sms: Über die API, die LeadConnector-Aktion und Automationen sendet eine Organisation je Kalendermonat (deutsche Zeit) höchstens 300 SMS; der Wert ist je Organisation einstellbar. Die Antwort nennt limit, used und resetsAt und trägt Retry-After bis zum Monatsanfang. Terminerinnerungen zählen nicht mit.

v1.34.0 · 24. September 2026

  • Geändertes Verhalten bei tags von Dokumenten: PATCH /documents/{id} speichert Tags nicht mehr kleingeschrieben und mit - statt Leerzeichen. Jeder Tag kommt in der Schreibweise zurück, die im Tag-Vorrat der Organisation steht; wer VIP schickt, während vip schon existiert, bekommt vip. Tags, die sich nur in Groß- und Kleinschreibung, Leerzeichen oder Bindestrichen unterscheiden, gelten als derselbe Tag. Ein unbekannter Tag wird so angelegt, wie er geschickt wurde; Leerzeichen und Sonderzeichen bleiben erhalten, bisher wurden Leerzeichen zu - und Sonderzeichen entfernt.
  • Der Filter GET /documents?tag= findet jetzt unabhängig von Groß- und Kleinschreibung, Leerzeichen oder Bindestrichen; vorher verglich er exakt.

v1.33.0 · 24. September 2026

  • Kontakte tragen neben tags jetzt tagDetails: je Tag die feste Kennung (id), der Text (tag), die erklärende Bezeichnung (label), die Quelle (source) und die Gruppe (group, oder null). Dieselbe Form bekommen die geplanten Ereignisse „Tag gesetzt“ und „Tag entzogen“. Auch die Webhooks contacts.contact.created und contacts.contact.updated liefern das Feld mit. Die Kennung bleibt beim Umbenennen eines Tags gleich; wer Tags zuordnet, sollte sie statt des Textes verwenden.
  • Geändertes Verhalten bei tags: Kontakt-Tags werden nicht mehr kleingeschrieben. Sie kommen in der Schreibweise zurück, die im Tag-Vorrat der Organisation steht; wer VIP schickt, während vip schon existiert, bekommt vip. Tags, die sich nur in Groß- und Kleinschreibung unterscheiden, gelten als derselbe Tag. Leerzeichen und Sonderzeichen bleiben erhalten; bisher wurden Leerzeichen zu - und Sonderzeichen entfernt. Der Filter ?tag= findet jetzt unabhängig von der Schreibweise; vorher fand er großgeschriebene Tags nicht.

v1.32.1 · 15. September 2026

  • Offene Posten (/open-items) sind jetzt für jede Organisationsart abrufbar, auch für persönliche Sphären und Haushalte. Bisher antwortete die API dort mit feature-not-available, obwohl die Anwendung die Posten führt. Unverändert: Mahnungen (/dunning/reminders) bleiben Geschäfts-Organisationen vorbehalten.

v1.32.0 · 7. September 2026

  • OAuth-Unterbau auf Better-Auth 1.7 gehoben (neues oauth-provider-Plugin). Neu: Token-Rücknahme und Token-Prüfung als eigene Endpunkte, ressourcengebundene Token, öffentliche Clients ohne Geheimnis, stärkere Client-Anmeldung. Zwei Sicherheitslücken der alten Fassung sind damit geschlossen. Bestehende OAuth-Verbindungen müssen einmalig neu hergestellt werden — Clients, Zustimmungen und Token aus der alten Fassung sind nicht überführbar. API-Schlüssel (capi_) sind nicht betroffen.

v1.31.0 · 7. September 2026

  • Website-Builder-MCP: die Werkzeugliste ist jetzt nach Berechtigung gefiltert — ein Zugang mit sites:read sieht die schreibenden Werkzeuge gar nicht mehr. Der direkte Aufruf eines nicht erlaubten Werkzeugs antwortet weiterhin mit 403 insufficient_scope.

v1.30.0 · 7. September 2026

  • Verbundene Apps im Profil: Nutzer sehen jede OAuth-Freigabe (Anwendung, Organisation, Berechtigungen im Klartext, gültige Zugänge, letzte Anmeldung) und können sie selbst widerrufen. Der Widerruf entfernt Org-Bindung, ausgestellte Tokens und den Consent — die Anwendung verliert den Zugriff sofort und fragt beim nächsten Verbinden neu.

v1.29.0 · 7. September 2026

  • LeadConnector-Menüpunkt: claritos kann als Custom Menu Link in LeadConnector erscheinen (/embed/leadconnector im iframe). Der verschlüsselte Location-Kontext von LeadConnector wird mit dem SSO-Schlüssel der App gelesen und zeigt die verknüpfte Organisation, aktive Auslöser und verfügbare Aktionen. Der Kontext belegt die Location, nicht eine claritos-Identität — er erzeugt keine Anmeldung, die Seite zeigt keine Geschäftsdaten.

v1.28.0 · 7. September 2026

  • Zapier-App: Anmeldung jetzt über OAuth 2.1 (Authorization Code + PKCE, automatische Token-Erneuerung) statt API-Schlüssel — Voraussetzung für die öffentliche Listung. Nutzer wählen beim Verbinden Organisation und Berechtigungen im claritos-Consent; die angefragte Scope-Liste wird aus der Spec erzeugt und lässt Klientendaten aus. Fehlende Berechtigungen melden sich als 403 an der betroffenen Aktion.

v1.27.0 · 7. September 2026

  • Checkout-Ereignisse im Standard-Format: payments.checkout.pending / .completed / .failed (Zahlungslink-Verkäufe) laufen jetzt auch über den API-Webhook-Dienst — mit Standard-Signatur, Wiederholung, Zustellprotokoll, Replay und Alarmen. Die bestehenden Zahlungslink-Webhooks am Link bleiben unverändert; wer umzieht, abonniert die neuen Typen und schaltet das alte Ziel ab.

v1.26.0 · 7. September 2026

  • OAuth-Consent: Berechtigungen sind einzeln abwählbar (Least Privilege). Der Client erhält nur die gewählten Scopes — auch wenn er alle angefragt hat; Klientendaten-Rechte sind standardmäßig abgewählt. Ein Consent ohne gewählte Berechtigung ist nicht mehr möglich, ein leerer Grant bedeutet „keine API-Rechte“.

v1.25.0 · 6. September 2026

  • Website-Builder-MCP (POST /api/mcp) akzeptiert jetzt auch OAuth-2.1-Access-Tokens (Login + Consent, Scopes sites:read/sites:write) — Chat-Connectoren (claude.ai, ChatGPT) brauchen keinen cmcp_-Token mehr; cmcp_-Tokens bleiben gültig. Scopes werden je Werkzeug durchgesetzt (get_/list_/verify_/suggest_ = lesen, alles andere = schreiben; 403 insufficient_scope). Protected-Resource-Metadaten je MCP-Server: /.well-known/oauth-protected-resource/api/mcp und …/api/mcp/v1.

v1.24.0 · 6. September 2026

  • Make-Custom-App (integrations/make): App-Baum vollständig aus der Spec generiert — Verbindung API-Schlüssel + Umgebung, Webhook (attach/detach über /webhooks), ein Instant-Trigger je Ereignistyp, Action-/Search-/Get-/Delete-Module je Endpunkt (Suche mit Cursor-Pagination, Actions mit Idempotency-Key), Problem-Details-Fehlerabbildung; Upload-Skript für die Make-Apps-SDK-API. Leitfaden „Make“. Damit sind alle vier Plattform-Apps (LeadConnector, Zapier, n8n, Make) im Repo.

v1.23.0 · 6. September 2026

  • n8n-Community-Node (integrations/n8n, npm n8n-nodes-claritos): Regular-Node mit Resource = Domäne und Operation = Endpunkt (deklarativ, aus der Spec generiert; Listen auf data entpackt), Trigger-Node mit Abo über POST /webhooks, Signaturprüfung und Abräumen beim Deaktivieren, Credential API-Schlüssel + Umgebung. Leitfaden „n8n“.

v1.22.0 · 6. September 2026

  • Zapier-App (integrations/zapier): ein REST-Hook-Trigger je Ereignistyp (Abo über POST /webhooks, Signaturprüfung, „Load sample“ aus /webhooks/events/{type}/recent), Actions für alle Schreib-Endpunkte, Searches für alle Listen — vollständig aus der Spec generiert. Neuer Snapshot docs/api/events.v1.json (Ereigniskatalog mit Beispielen). Leitfaden „Zapier“.

v1.21.0 · 6. September 2026

  • LeadConnector-Marketplace-App (Weg C): Installation je Location (OAuth aus den Org-Einstellungen oder External Authentication mit API-Schlüssel), Custom Workflow Actions (contact-create, task-create, sms-send, quote-create, invoice-create, form-response — laufen über den API-Rahmen mit dem Schlüssel des Nutzers), Custom Workflow Triggers (lead_created, contact_created, invoice_paid, invoice_issued, quote_accepted, esign_completed, form_submitted, task_done — intern Webhook-Endpunkte). Leitfaden „LeadConnector“.

v1.20.0 · 6. September 2026

  • MCP über die API: POST /api/mcp/v1 (Streamable HTTP) — ein Werkzeug je Endpunkt (Name <domain>_<action>, Eingabe params/query/body wie in der Referenz, optional idempotencyKey bei Schreibaufrufen). Gleiche Auth (API-Schlüssel oder OAuth 2.1), gleiche Scopes, Klientendaten-Gate, Ratenlimits und Protokoll wie HTTP; die Werkzeugliste zeigt nur, was der Zugang darf. Leitfaden „MCP“.

v1.19.0 · 6. September 2026

  • OAuth 2.1: Die API akzeptiert neben API-Schlüsseln jetzt OAuth-Access-Tokens (Authorization-Code + PKCE, Refresh-Tokens, Dynamic Client Registration). Der Nutzer gibt im Consent genau eine Organisation frei; die Scopes sind dieselben wie bei Schlüsseln. Discovery unter /.well-known/oauth-authorization-server und /.well-known/oauth-protected-resource. Leitfaden „OAuth“ (Flows, Consent, Zapier/n8n).

v1.18.0 · 6. September 2026

  • Finder + Lebensmittel (nur lesen): GET /finder/practitioners (Umkreis-, Orts-, Sprach-, Qualifikations- und Themen-Filter; dieselbe Suche wie die öffentliche Finder-Seite der Organisation), GET /finder/practitioners/{slug} (Profil mit Standorten, Schwerpunkten, Qualifikationen; alte Slugs werden aufgelöst), GET /finder/places (Orts-Vorschläge). GET /foods/search (nach Kategorien gruppierte Treffer), GET /foods (Liste je Kategorie), GET /foods/{id} (per ID oder Slug) — global, Nährwerte je 100 g, Portionsangaben, Quelle und Quellenangabe (Attribution) in jeder Antwort.

v1.17.0 · 6. September 2026

  • Organisation (nur lesen): GET /organization (Stammdaten, Adresse, Steuer-/Registerdaten, Bank, Logo, Inbox-Adresse, Branding-Domain, E-Sign-Stufe, API-Einstellungen), GET /organization/members (Mitglieder mit Rolle, Sichtbarkeit, Klientenzugang), GET /organization/invitations (Einladungen; abgelaufene werden als EXPIRED gemeldet), GET /organization/api-keys (eigene Schlüssel — nur Metadaten, nie Hash/Klartext; isCurrent markiert den aufrufenden Schlüssel). Ereignis organization.member.joined (Einladung angenommen, Organisation angelegt).

v1.16.0 · 6. September 2026

  • Finanzen (nur lesen): GET /accounts, GET /accounts/{id} (Kontenrahmen mit Art, Untertyp, Hierarchie, Bebuchbarkeit, Bankdaten und Saldo — kanonisch Soll − Haben plus Anzeige-Saldo), GET /bookings, GET /bookings/{id} (Journal mit Zeilen je Konto/Kontakt/Kostenkategorie, Belegen, OP-Verknüpfungen, Storno-Bezug; Filter nach Zeitraum, Status, Konto, Kontakt, Beleg), GET /statements, GET /statements/{id}, GET /statements/{id}/lines (Kontoauszüge mit Zeilenständen, zugeordnetem Bankkonto und Kreditkarten-Zusammenfassung). Ereignisse finance.booking.created (alle Erzeugungswege) und finance.booking.reversed. Keine Schreibpfade in v1.

v1.15.0 · 6. September 2026

  • Post/SMS/E-Mail: GET/POST /letters (Brief anlegen, optional PDF sofort erzeugen), GET/PATCH /letters/{id}, POST /letters/{id}/generate (PDF asynchron, pdfState), POST /letters/{id}/send (Kanal EMAIL, POSTAL oder BOTH — Postversand über den angebundenen Provider ist kostenpflichtig), GET /letters/{id}/pdf, GET /postal-letters, GET /postal-letters/{id} (Warteschlange mit Status, Seiten, Kosten, Tracking), GET/POST /sms, GET /sms/{id} (SMS senden — kostenpflichtig — und Zustellstatus lesen), GET /outbound-emails, GET /outbound-emails/{id} (E-Mail-Ausgang aller Bereiche; Klientenakten-Mails ausgenommen). Ereignisse letters.letter.sent, letters.postal.submitted/sent/delivered/failed, sms.message.sent/delivered/failed.

v1.14.0 · 6. September 2026

  • Verträge/E-Sign: GET /contract-templates, GET /contract-templates/{id} (Vorlage mit Beteiligten-Plan, Variablen-Slugs und HTML), GET/POST /contracts (Vertrag aus Vorlage: Beteiligte je Slot, Titel/Ort/Datum, Zusatz-Variablen; der Worker rendert das PDF asynchron — renderState), GET /contracts/{id}, GET/POST /signature-requests (Signatur-Anfrage aus einem PDF-Dokument mit Parteien, optional Feldplatzierung, Signatur-Stufe, Einwilligung; standardmäßig sofort versendet), GET /signature-requests/{id}, POST …/send (versendet bzw. sendet erneut; Verträge erst nach dem Render), POST …/cancel, GET …/events (Hash-Kette), GET …/pdf (versiegeltes Exemplar oder Original, kurzlebige URL). Ereignisse esign.request.sent/completed/sealed/expired/declined/cancelled. Signier-Links werden nie ausgegeben.

v1.13.0 · 6. September 2026

  • Affiliates: GET /affiliates, GET /affiliates/{id} (Partner mit Status, Vertragsart, Werbe-Code, Ansprechpartner; keine Bank-/Steuerdaten), GET /campaigns, GET /campaigns/{id} (Kampagne mit Tiefe, Modell, Attributionsfenster, Artikeln, Landingpages, Ref-Parameter), GET /affiliate-links (Einschreibungen Partner × Kampagne mit Klicks und fertig komponierten Share-Links je Landingpage), GET /conversions, GET /conversions/{id} (Konversion mit Brutto/Gebühr/Klimabeitrag/Basis, Status, Zahlungsstand, Auszahlungs-Termine und Provisionseinträgen je Ebene/Rolle), POST /conversions (externe Konversion melden — per Werbe-Code oder Gutschein-Code, idempotent über externalRef; gleiche Semantik wie der Conversion-Webhook), GET /commissions (Provisionseinträge, nur lesen). Ereignisse affiliates.conversion.registered (aus allen Aufnahme-Pfaden: Stripe, Coupon, Webhook, manuell, API) und affiliates.conversion.settled. Keine Auszahlungen, keine Gutschriften.

v1.12.0 · 6. September 2026

  • Klienten (Praxisverwaltung, Gesundheitsdaten): GET/POST /clients, GET/PATCH /clients/{id} (Akte mit Aktennummer, Status, Kanal-Overrides, Betreuungszeitraum, Aufbewahrung), GET/PATCH /clients/{id}/fields (alle Aktenfelder mit aktuellem Wert; Schreiben mehrerer Felder mit Messzeitpunkt/Messender/Grund), GET/POST /clients/{id}/measurements (Werteverlauf mit Korrekturkette; einzelne Messung erfassen), GET/POST /clients/{id}/messages (Konversation mit dem Klienten, Praxis-Seite), GET /clients/{id}/files. Alles nur mit Klientendaten-Freischaltung (AV-Vertrag) + clients:read/clients:write; jeder Zugriff wird je Akte protokolliert (nur IDs). Ereignisse clients.record.created, clients.record.updated, clients.message.received (nur Referenzen, keine Gesundheitsdaten im Webhook).

v1.11.0 · 6. September 2026

  • Formulare: GET /forms, GET /forms/{id} (Definition: Seiten, Felder mit Schlüssel/Typ/Optionen/Pflicht/Bedingungen, Matrix-/Wiederhol-Blöcke, Einwilligungen), GET /forms/{id}/responses, GET /responses/{id}, POST /forms/{id}/responses (serverseitiger Submit ohne OTP; gleiche Validierung wie der öffentliche Bogen; optional affiliateId für die Zuordnung; erzeugt Interessent + Lead-Ereignis). Antworten von Klientenakten-Bögen nur mit Klientendaten-Freischaltung + clients:read. Ereignis forms.response.submitted (auch für öffentliche Bögen und Funnel-Formulare; Klientenakten-Bögen nur als Referenz).

v1.10.0 · 6. September 2026

  • Dokumente: GET /documents (status, type, taskId/none, contactId, tag, financeRelevant, q, updatedSince), GET /documents/{id}, POST /documents (presigned PUT-URL für den direkten Upload nach R2, 5 min) + POST /documents/{id}/confirm (READY, startet OCR/KI bzw. Kontoauszug-Parser), GET /documents/{id}/download-url (kurzlebige URL mit Dateinamen), PATCH /documents/{id} (Titel, Typ, Aufgabe, Kontakt, Tags). KI-extrahierte Felder unter extracted. Ereignisse documents.document.ready/analyzed/updated.

v1.9.0 · 6. September 2026

  • Zeiterfassung: GET/POST /time-entries, GET/PATCH/DELETE /time-entries/{id}, POST /time-entries/{id}/stop. POST ohne endTime startet einen laufenden Timer (ein Timer je Nutzer; stoppt andere, setzt die Aufgabe auf IN_PROGRESS). Abgerechnete Einträge sind unveränderlich (409 billed). Filter taskId, userId, projectId, from/to, isBillable, isBilled, running, updatedSince. Ereignisse time.timeEntry.created/updated/deleted.

v1.8.0 · 6. September 2026

  • Projekte: GET/POST /projects, GET/PATCH/DELETE /projects/{id} — mehrsprachiger Name wie bei Aufgaben, Kunde + Ansprechpartner, Hauptprojekt (zyklusfrei), Zeit-Budget (Minuten, vorausbezahlt), Laufzeit; Kennzahlen offene Aufgaben, gebuchte und abrechenbare Minuten. Filter q, customerContactId, parentId (none = Top-Level), activeOn, updatedSince. Ereignisse projects.project.created/updated/deleted.

v1.7.0 · 6. September 2026

  • Aufgaben: GET/POST /tasks, GET/PATCH/DELETE /tasks/{id}, POST /tasks/{id}/status, GET/POST /tasks/{id}/comments. Titel/Beschreibung mehrsprachig: Lesen in der Anfrage-Sprache (?locale oder Accept-Language) plus vollständiges titleI18n; Schreiben als String oder Objekt {de,en,ru}, Mandantensprache wird automatisch nachübersetzt. Erledigen stoppt laufende Timer, schliesst Watcher und erzeugt die nächste Wiederholung wie in der App. Ereignisse tasks.task.created/updated/completed/deleted, tasks.comment.created.

v1.6.0 · 6. September 2026

  • Offene Posten: GET /open-items (direction, status inkl. open/overdue, contactId, invoiceId, q, updatedSince), GET /open-items/{id} (Beträge in Cents, Skonto, Mahnstand, Zahlungen = verknüpfte Buchungen), POST /open-items/{id}/payments (Zahlung als Buchung „Bank an Personenkonto“ inkl. § 367-Anrechnung offener Mahnkosten; Teilbetrag per amountCents; markOnly für reinen Status-Flip). Mahnwesen: GET /dunning/reminders und GET /dunning/reminders/{id} (Stufe, Forderung/Gebühr/Zinsen/Gesamt in Cents, PDF, Portal-Link). Ereignisse payments.payment.recorded (alle Zahlwege), dunning.reminder.sent, invoices.invoice.overdue (beim Erzeugen einer Mahnstufe).

v1.5.0 · 6. September 2026

  • Rechnungen: GET /invoices (Filter status inkl. open/overdue, kind, contactId, orderId, q, updatedSince), GET/POST /invoices, PATCH /invoices/{id} (nur Entwürfe — GoBD), POST …/issue (Nummer, Buchung, offener Posten, PDF + ZUGFeRD), POST …/correct (mode cancel = Storno-Beleg, mode value = wertmäßige Korrektur KOR-…), GET …/pdf (final oder Vorschau), GET …/xml (ZUGFeRD-XML als application/xml). Beträge als Cents + exakte Dezimal-Strings; Brutto-Modus (priceMode GROSS) mit Brutto-Einzelpreisen. Ereignisse invoices.invoice.created/issued/sent/paid/cancelled/corrected — auch bei Zahlungen über Stripe/Checkout/Raten/OP-Ausgleich.

v1.4.0 · 6. September 2026

  • Aufträge: GET /orders (Filter status/draft, contactId, sourceQuoteId, q, updatedSince), GET /orders/{id} (Positionen mit abgerechneter/entfallener/offener Menge, Abschnitte, verknüpfte Rechnungen, AB-PDF), GET /orders/{id}/pdf. POST /quotes/{id}/convert: Angebot ausstellen, annehmen und über den Annahme-Router in einen Auftrag überführen (AB-Nummer, PDF, automatischer Versand, ggf. Vorausrechnung/Abschlag); wartet bis 25 s, sonst routing-pending. Ereignis orders.order.created (Quelle quote|manual|duplicate).

v1.3.0 · 6. September 2026

  • Angebote: GET/POST /quotes, GET/PATCH /quotes/{id} (Kopf, Positionen, Abschnitte; Artikel-Referenz füllt Name/Einheit/Preis/Steuer), POST …/issue (Nummer + Portal-Link + PDF), POST …/send (E-Mail mit PDF; wartet bis 25 s auf das Rendering, sonst pdf-pending), POST …/accept und …/decline (im Namen des Kunden; Annahme stösst Auftrag/Vorausrechnung an), GET …/pdf (Status + URL). Beträge als Cents + exakter Dezimal-String. Ereignisse quotes.quote.created/updated/sent/accepted/declined — auch bei Annahme im Kunden-Portal.

v1.2.0 · 6. September 2026

  • Artikel: GET/POST /articles, GET/PATCH /articles/{id} — Suche q, Filter kind/archived, updatedSince; Preise als unitPriceCents + unitPriceExact (vier Nachkommastellen), Währung = Basiswährung der Organisation; Archivieren per PATCH archived (kein DELETE). Ereignisse articles.article.created/updated. Neuer Fehlercode feature-not-available (403), wenn eine Funktion für den Organisationstyp nicht verfügbar ist.

v1.1.0 · 6. September 2026

  • Webhooks: GET/POST /webhooks, GET/PATCH/DELETE /webhooks/{id}, POST …/rotate-secret, POST …/test, GET …/deliveries, POST …/replay; Katalog GET /webhooks/events mit …/{type}/sample und …/{type}/recent. Signatur nach Standard Webhooks (webhook-id, webhook-timestamp, webhook-signature), Wiederholung 1 min/5 min/30 min/2 h/12 h, Endpunkt nach fünf Fehlschlägen in Folge deaktiviert. Scope webhooks:manage.
  • Ereignisse: contacts.contact.created/updated/deleted, leads.lead.created, webhooks.test.

v1.0.0 · 6. September 2026

  • Erste Fassung der öffentlichen API: Schlüssel (capi_…), Scopes, Fehler nach RFC 9457, Cursor-Paginierung, Idempotency-Key, Rate-Limits, GET /me.
  • Kontakte: GET/POST /contacts, GET/PATCH/DELETE /contacts/{id} — Suche (q), Filter type/tag, updatedSince; Geschlecht per KI, wenn nicht angegeben.