API Changelog

Was gibt's Neues in der API?

Alle Änderungen, neue Endpoints und Breaking Changes — chronologisch dokumentiert.

August 2026

Neu

TLC-Charge nachträglich korrigieren

Der Betrag einer bestehenden TLC-Charge lässt sich jetzt korrigieren, ohne sie löschen und neu anlegen zu müssen. Gültigkeitszeitraum und Historie bleiben erhalten.

  • Neue Mutation updateTimeLimitedCredit(id: ID!, amount: Int!): Boolean! — der Wert wird absolut gesetzt, nicht addiert
  • Gültiger Bereich 1–10.000; unveränderte Werte werden abgelehnt
  • validFrom und validUntil bleiben unveränderlich
  • Neuer Log-Typ tlcEdited mit altem und neuem Wert
Breaking Change

Argument kind bei uploadMandantPictureV2 ist Pflicht

Beim Bild-Upload muss die Bildart jetzt angegeben werden. Der bisherige Standardwert coursePicture entfällt.

  • uploadMandantPictureV2: kind: PictureKind = coursePicture → kind: PictureKind!
  • Der Standardwert am Query-Argument mandantPictures(kind:) bleibt unverändert
Neu

Freiplätze auf kostenpflichtigen Terminen

Admins können einen Teilnehmer auf einen kostenpflichtigen Termin buchen, ohne dass eine Rechnung entsteht — für Freiplätze, Gutscheine oder Sonderfälle.

  • Neues optionales Argument skipInvoice: Boolean bei createBookingForUserV2
  • Die Buchung entsteht wie eine kostenlose: keine Rechnung, keine Rechnungs-Mail, wasPurchased bleibt false
  • Nur auf dem Admin-Pfad wirksam; im Protokoll als invoice-skipped vermerkt
Breaking Change

Query getInvoicePdf entfernt

Die Query getInvoicePdf wurde entfernt. Ersatz ist getInvoicePdfV2, das das PDF direkt als Base64 zurückgibt statt als Link auf eine erzeugte Datei.

  • Entfernt: getInvoicePdf — Ersatz ist getInvoicePdfV2

Juli 2026

Neu

Bild-Varianten und Logo-Upload

Hochgeladene Bilder werden nicht mehr auf 200×200 verkleinert, sondern in mehreren Größen gespeichert. Neu ist außerdem die Bildart logo mit erhaltener Transparenz. Alle Schema-Änderungen sind additiv — bestehende Clients funktionieren unverändert.

  • Neues Enum PictureKind mit coursePicture und logo
  • Neue Felder bei Picture: kind: PictureKind!, mediumUrl: String, width: Int, height: Int — bei Logos bleiben die Medium-Felder leer
  • Neues optionales Argument kind bei mandantPictures und uploadMandantPictureV2 (Standard: coursePicture)
  • Upload-Fehler melden jetzt konkrete Ursachen (z. B. image-too-large) statt pauschal unsupported-image-format
  • Logos werden als Kurs-, Termin- und Produktbild serverseitig abgelehnt
Breaking Change

Vier veraltete V1-Endpunkte entfernt

Vier veraltete Endpunkte wurden entfernt. Alle vier haben einen V2-Nachfolger.

  • Entfernt: createMultiBooking — Ersatz ist createMultiBookingV2
  • Entfernt: addRemoveCreditsForAllUsers — Ersatz ist addRemoveCreditsForAllUsersV2 (deprecated seit 04/2026)
  • Entfernt: getLogsCsv — Ersatz ist getLogsCsvV2
  • Entfernt: pdfEventSummary — Ersatz ist pdfEventSummaryV2
  • Entfernt: Typen CreateMultiBookingResult und MultiBookingResult
Breaking Change

Teilnehmer-Kontaktdaten nur noch fuer Berechtigte

E-Mail-Adressen von Teilnehmern sehen jetzt nur noch Mandanten-Admins und globale Trainer. Kurs-Trainer erhalten in Buchungslisten null, die detaillierte Termin-PDF ist fuer sie nicht mehr abrufbar (die einfache Variante bleibt).

  • Feld User.email ist jetzt nullable: String! → String — Clients muessen mit null umgehen koennen
  • Event.bookings liefert email nur noch fuer Admins und globale Trainer
  • pdfEventSummaryV2 mit withDetails: true erfordert jetzt Admin- oder globale Trainer-Rechte
Neu

Neue Statistik-Query topUsersByBookings

Liefert die Nutzer mit den meisten Buchungen eines Mandanten in einem Zeitraum.

  • Neue Query topUsersByBookings(mandantId: ID!, from: Date!, to: Date!, limit: Int = 10, includeWaitlist: Boolean = false): [UserBookingStat!]!
  • Neuer Typ UserBookingStat mit userId, user, numBookings und numWaitlists
Neu

Anwesenheit in der Buchungshistorie

Die Buchungshistorie gibt jetzt den Anwesenheitsstatus zurueck.

  • Neues Feld attended: Boolean beim Typ BookingHistoryEntry
Neu

Persistierter Standard-Mandant

Der bevorzugte Mandant eines Nutzers kann jetzt serverseitig gespeichert und abgefragt werden.

  • Neue Mutation setDefaultMandant(mandantId: ID!): UserPreferences!
  • Neues Feld defaultMandant: Mandant bei UserPreferences

API-Änderungen per E-Mail erhalten

Wir informieren dich bei neuen Features, Breaking Changes und Deprecations.

Du erhältst eine Bestätigungsmail. Abmeldung jederzeit möglich.