Content- und API-Vertrag

Die öffentliche App konsumiert zwei CMS-Ressourcen:


GET /api/cms/categories
GET /api/cms/stories

Der App-Proxy überträgt erlaubte Query-Parameter an Strapi, setzt den Publikationsstatus aber selbst. Andere Ressourcen liefern 404.

Kategorievertrag

Die App benötigt je Kategorie insbesondere:

documentId
lokalisierter label
rank
optionales Icon
Parent- und Child-Beziehungen
TTS-Jobs für den Titel

Storyvertrag

Die App benötigt je Story insbesondere:

documentId
lokalisierter label
rank
Kategoriebeziehung
optionales Icon
geordnete Text-, Link- oder Video-Slides
TTS-Jobs für Titel und Textfelder

Stabilitätsregeln

documentId ist die sprachübergreifende fachliche Identität.
Beziehungen werden in derselben Locale aufgelöst.
rank bestimmt die sichtbare Reihenfolge.
Medien-URLs können vom API-Origin abweichen.
Draft-Daten benötigen authentifizierten serverseitigen Zugriff.
Neue Slide-Typen erfordern abgestimmte Änderungen in CMS-Schema, App-Mapping, Rendering, Tests und Dokumentation.

Die TTS-Verwaltungsrouten sind technisch von der öffentlichen Content API getrennt und keine öffentliche Integrationsschnittstelle. Sie akzeptieren ausschließlich aktive Strapi-Admin-Sessions. Öffentliche Requests sowie Content-API-Tokens werden abgewiesen.

Innerhalb der Admin-Sitzung gelten die Content-Manager-Rechte des jeweiligen Content-Types: Statusabfragen benötigen read, verändernde Aktionen wie Enqueue, Cancel und Recover benötigen update. Das zentrale Audio-Dashboard setzt die passenden Rechte für Stories und Kategorien voraus, weil es Daten beider Typen zusammenführt. Verändernde Routen sind zusätzlich anwendungsseitig rate-limitiert.