Changelog

Die API ist über den URL-Pfad versioniert (aktuell /v1/). Innerhalb einer Version sind Änderungen abwärtskompatibel: Es kommen neue Endpunkte, Felder und Parameter hinzu, aber bestehende werden weder entfernt noch umbenannt, und ihre Bedeutung ändert sich nicht. Ihre Integration sollte unbekannte Felder in Antworten deshalb ignorieren. Brechende Änderungen kämen nur mit einer neuen API-Version und würden hier vorab angekündigt.

Die aktuelle Verfügbarkeit der API zeigt die Status-Seite.

• Ein Name für Ihr Konto: account. Die API nennt das Schulungstool-Konto jetzt überall account; Benutzer, Gruppen und Kurse gehören zu einem Konto, Personen heißen durchgehend users. GET /v1/me/ liefert account (mit id, name und domain) statt organization, der Webhook-Umschlag trägt account (die ID des Kontos) statt tenant und tenant_id, und Partner-Apps nennen das Konto am Token-Endpunkt mit dem Body-Parameter account (die ID) statt tenant. Ordnen Sie Konten über die ID zu: domain kann sich ändern. Die alten Namen entfallen ohne Übergangsfrist; sie waren erst in diesem Monat eingeführt worden. Siehe Authentifizierung und Webhooks.
• Limits je Schlüssel und für E-Mails. Zusätzlich zu den 1000 Anfragen pro Minute je Konto gilt jetzt je API-Schlüssel bzw. OAuth-Verbindung ein Limit von 600 Anfragen pro Minute, damit eine Integration nicht das ganze Kontingent des Kontos verbraucht; X-RateLimit-Limit nennt das engste geltende Limit. Einladungen und Einschreibungen mit E-Mail-Benachrichtigung sind auf 60 pro Stunde je Konto begrenzt. Drei neue Fehlertypen: TokenExpired (401, OAuth-Token erneuern), AccountFrozen (401) und AuthThrottled (429 nach zu vielen fehlgeschlagenen Authentifizierungsversuchen für einen Schlüssel; diese Versuche erscheinen jetzt auch im API-Protokoll). Siehe Fehler und Durchsatzbegrenzung.
• MCP-Server: sicherere Tools. Bei abgelaufenen oder widerrufenen Zugangsdaten antwortet der Server jetzt mit 401, sodass OAuth-Clients ihr Token selbst erneuern. create_user setzt immer ein Startpasswort, das der Benutzer bei der ersten Anmeldung ändern muss, die Notiz in enroll_user ist auf 500 Zeichen begrenzt, und schreibende Tools senden automatisch einen Idempotency-Key; ein nach einem Timeout wiederholter Aufruf erzeugt deshalb kein Duplikat. Siehe MCP-Guide.
• OAuth für MCP-Server und API. KI-Clients und eigene Apps können sich jetzt per OAuth-Anmeldung statt mit einem statischen Schlüssel verbinden: MCP-Server und API unterstützen OAuth 2.1 (Authorization Code mit PKCE, Discovery per RFC 9728). Ein Administrator gibt jede Verbindung frei und wählt ihre Zugriffsrechte; Verbindungen erscheinen im Administrationsbereich und lassen sich jederzeit trennen. Eigene OAuth-Apps registrieren Sie in den Entwickleroptionen, als Serveranwendung mit Client-Secret oder als Desktop-, Mobil- oder Browser-App, und richten eine Serveranwendung für das ganze Konto ein: Die App holt sich Tokens dann per Client-Credentials-Flow, unabhängig von einem Benutzer. API-Schlüssel bleiben unverändert. Siehe Authentifizierung und den MCP-Guide.
• Zuverlässig 400 bei doppelten Benutzern. Ist beim Erstellen oder Bearbeiten von Benutzern der Benutzername oder die E-Mail-Adresse bereits vergeben, antwortet die API jetzt immer mit 400 und dem Fehlertyp ValidationError, der das betroffene Feld in field_errors nennt; bisher konnten solche Konflikte in seltenen Fällen in einem 500 enden. Benutzername und E-Mail-Adresse sind jetzt außerdem unabhängig von Groß-/Kleinschreibung eindeutig: anna und Anna zählen als derselbe Wert. Siehe Fehler und Durchsatzbegrenzung und API-Referenz, Abschnitt Benutzer.
• expand verlangt jetzt das Lese-Zugriffsrecht der eingebetteten Ressource. Die Erweiterung eines Feldes über den Query-Parameter expand bettet das vollständige verknüpfte Objekt ein – der API-Schlüssel braucht deshalb jetzt auch das Zugriffsrecht Lesen dieser Ressource, zum Beispiel users:read für ?expand=user an Kursteilnahmen. Fehlt es dem Schlüssel, antwortet die API mit 403 und dem Fehlertyp MissingScope, der das benötigte Zugriffsrecht nennt. Siehe Ressourcen erweitern und Zugriffsrechte.
• Idempotente Requests. Alle POST-Endpunkte akzeptieren den neuen Idempotency-Key-Header, der Wiederholungen sicher macht: Derselbe Request mit demselben Key liefert die gespeicherte Antwort der ersten erfolgreichen Ausführung, statt erneut auszuführen. Siehe Idempotente Requests.
• Zugriffsrechte für API-Schlüssel. Jeder API-Schlüssel trägt jetzt Zugriffsrechte, die je Ressource bestimmen, was er aufrufen darf: Kein Zugriff, Lesen oder Lesen und Schreiben, plus ein bewusst separates Recht für Login-Links. Die API-Referenz nennt an jedem Endpunkt das benötigte Zugriffsrecht; fehlt es, antwortet die API mit 403 und dem neuen Fehlertyp MissingScope, und der neue Endpunkt GET /v1/me/ liefert die Zugriffsrechte des verwendeten Schlüssels. Bestehende Schlüssel behalten Vollzugriff. Die Schlüssel-Liste im Administrationsbereich zeigt außerdem, wann ein Schlüssel zuletzt verwendet wurde. Siehe Zugriffsrechte.
• MCP-Server. KI-Agents wie Claude verwalten Benutzer, Gruppen, Kurse und Teilnahmen Ihres Kontos über das Model Context Protocol: https://mcp.schulungstool.de/mcp, 15 Tools, authentifiziert mit Ihrem API-Schlüssel und begrenzt auf dessen Zugriffsrechte. Jeder Tool-Aufruf erscheint im API-Protokoll. Siehe MCP-Guide.
• Wählbare Seitengröße. Alle Listen-Endpunkte akzeptieren den neuen Query-Parameter page_size (1 bis 100; der Standard bleibt 25). Die URLs in next und previous behalten die gewählte Seitengröße bei. Siehe Paginierung und Sortierung.
• Webhooks. Schulungstool informiert Ihre Systeme jetzt aktiv über Events zu Benutzern und Kursteilnahmen: signierte POST-Requests mit Wiederholungen, 30-Tage-Zustellprotokoll und Testevents, konfiguriert im Administrationsbereich. Siehe Webhooks-Guide und API-Referenz, Abschnitt Webhooks.
• Rate-Limit-Header auf jeder Antwort. Jede API-Antwort meldet den aktuellen Stand der Durchsatzbegrenzung in den Headern X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset – so können Clients ihre Requests takten, bevor sie in einen 429 laufen. Siehe Fehler und Durchsatzbegrenzung.
• Request-IDs und API-Protokoll. Jede API-Antwort trägt den neuen Header X-Request-ID; Fehlerantworten wiederholen die ID als request_id im Fehlerbody. Geben Sie sie bei Support-Anfragen an: Damit können wir den betroffenen Request direkt in unseren Logs nachschlagen. Siehe Fehler und Durchsatzbegrenzung. Der Administrationsbereich führt zusätzlich ein 30-Tage-Protokoll der Requests Ihrer API-Schlüssel (nur Metadaten, keine Request- oder Response-Bodies), unter Einstellungen > Erweiterte Einstellungen > Entwickleroptionen > API-Protokoll.
• Neue Doku-Site. Englisch ist jetzt die Standardsprache, mit vollständiger deutscher Fassung. Die neue API-Referenz unterstützt das Ausprobieren von Anfragen direkt im Browser, und das Schema steht als OpenAPI-3.1-Dokument (englische Originalfassung) zum Download bereit, dazu eine llms.txt für KI-Assistenten. Die API selbst ist unverändert; alle bestehenden Links auf die bisherige Dokumentation funktionieren weiter.
• E-Mail-Benachrichtigung beim Erstellen von Kursteilnahmen. Kursteilnahme erstellen kann die Benachrichtigungs-E-Mail an den Benutzer jetzt direkt auslösen: send_email_notification setzen, optional geplant über email_scheduled_at.
• Passwortwechsel erzwingen. Das User-Objekt hat das neue Feld requires_password_change; es lässt sich beim Erstellen und Bearbeiten von Benutzern setzen und beim Auflisten filtern.
• Delta-Abfragen mit updated_after. Die Listen-Endpunkte unterstützen den neuen Filter updated_after: Rufen Sie nur noch die Objekte ab, die sich seit dem letzten Lauf geändert haben, statt der vollen Liste; siehe der neue Guide Daten synchron halten. Änderungen an Gruppenmitgliedschaften aktualisieren jetzt updated_at von Benutzer und Gruppe. Kursbewertungen sind die bewusste Ausnahme: Sie sind anonym und tragen deshalb weder Zeitstempel noch einen updated_after-Filter.