GET/api/public/legal/:slug

Liefert einen einzelnen Rechtstext als HTML.

Die Seite „GET /api/public/legal/:slug — API-Referenz“ behandelt den in der URL bezeichneten Funktionsbereich. Der vorhandene Inhalt wird um den tatsächlichen Ablauf, die Voraussetzungen und die bekannten Grenzen ergänzt. Zentor besitzt kein Entwickler-API-Key-System. Für das Dashboard werden Session-JWTs mit zwölf Stunden Laufzeit und Refresh-Tokens mit sieben Tagen Laufzeit verwendet; TOTP und SSO sind optional. Widget-Embed-Tokens werden einmalig im Klartext angezeigt und sind an zugelassene Origins gebunden. Die Dokumentation zu `GET /api/public/legal/:slug` soll verbindlich als technische Beschreibung dieses konkreten Endpunkts gelesen werden. Entscheidend sind Methode, Pfad, Authentifizierung, Pflichtfelder, mögliche Fehler und die Frage, ob ein erneuter Aufruf denselben Effekt auslöst. Dieser Hilfeabschnitt https://zentor-app.de/hilfe/api-referenz/oeffentliche-inhalte/content.legal_by_slug darf deshalb keine allgemeinen Werbeaussagen enthalten, sondern nur im Anschluss anvollziehbare Integrationsschritte und belegte Antwortbeispiele. Für einen Aufruf von `/api/public/legal/:slug` wird die Anfrage entsprechend der Registry aufgebaut. Öffentliche Routen benötigen keinen allgemeinen Entwickler-API-Schlüssel, weil Zentor kein solches Schlüsselsystem anbietet. Geschützte Widget-Routen verwenden dagegen den einmalig angezeigten Embed-Token und eine Origin-Prüfung. Der HTTP-Status und der JSON-Inhalt müssen gemeinsam ausgewertet werden; ein `ok`-Feld allein ersetzt keine Fehlerbehandlung. Beim Test von `GET /api/public/legal/:slug` sind anonymisierte Werte zu verwenden. Reale Kundendaten, produktive UUIDs, Sitzungs-Tokens und konkrete Zeitstempel gehören nicht in öffentliche Beispiele. Der bekannte plattformweite Grenzwert liegt bei 2.000 Anfragen innerhalb von 15 Minuten; ein abweichendes Einzellimit ist nicht belegt. Nicht idempotente POST-Aufrufe dürfen nach einem unklaren Netzwerkabbruch nicht blind wiederholt werden. Typische Integrationsfehler für diese Route entstehen durch fehlende Pflichtparameter, falsche Datentypen, abgelaufene Einmalcodes, nicht erlaubte Origins oder einen nicht implementierten Datensatz. Die Anwendung sollte solche Fälle getrennt behandeln und die vom Endpunkt zurückgelieferte Fehlermeldung protokollieren, ohne geheime Inhalte mitzuschreiben. Ein erfolgreicher Request bestätigt nur diesen Verarbeitungsschritt, nicht automatisch einen im Anschluss angelagerten E-Mail-, Zahlungs- oder SSO-Erfolg. Dies ist für „GET /api/public/legal/:slug“ unmittelbar relevant. Die technische Prüfung dieser Seite ist zwingend zu sich auf die Registry unter `app/frontend/src/content/api-reference/` und die zugehörigen Backend-Routen stützen. Live-Test-Vermerke dürfen nur das behaupten, was tatsächlich geprüft wurde. Ein Negativtest oder eine Code-Analogie ist kein vollständiger Erfolgsnachweis. Für GET /api/public/legal/:slug — API-Referenz ist daher klar zwischen dokumentierter Struktur, automatisiertem Test und sicher beobachtetem Live-Verhalten zu unterscheiden.

{"ok":true,"data":{"body_html":"<h2>Angaben gemäß § 5 DDG</h2>...","updated_at":"2026-07-19T...","version":5}}