GET/api/public/legal/:slug

Restituisce un singolo testo legale come HTML.

La pagina «GET /api/public/legal/:slug — Riferimento API» descrive l'area funzionale identificata dalla URL. Il contenuto esistente viene ampliato con workflow reale, prerequisiti e limiti noti. Zentor non dispone di un sistema Developer API Key. Per il dashboard vengono usati Session JWT con durata di dodici ore e Refresh Token di sette giorni; TOTP e SSO sono opzionali. I Widget Embed Token vengono mostrati in chiaro una sola volta e sono legati alle Origin autorizzate. La documentazione di `GET /api/public/legal/:slug` va letta come descrizione tecnica vincolante di questo endpoint specifico. Sono decisivi metodo, percorso, autenticazione, campi obbligatori, possibili errori e la questione se una nuova chiamata produca lo stesso effetto. Questa sezione https://zentor-app.de/hilfe/api-referenz/oeffentliche-inhalte/content.legal_by_slug non deve contenere affermazioni pubblicitarie generiche ma soltanto passaggi di integrazione tracciabili ed esempi di risposta comprovati. Per una chiamata a `/api/public/legal/:slug`, la richiesta viene costruita secondo la Registry. Le route pubbliche non richiedono una Developer API Key generale; le route Widget protette usano l'Embed Token mostrato una sola volta e una verifica Origin. Stato HTTP e contenuto JSON devono essere valutati insieme; un campo `ok` da solo non sostituisce la gestione errori. Nei test vanno usati valori anonimizzati. Veri dati cliente, UUID produttivi, Session Token e timestamp concreti non devono comparire negli esempi pubblici. Il limite noto della piattaforma è 2.000 richieste in 15 minuti; non è dimostrato un limite individuale diverso. Le POST non idempotenti non devono essere ritentate alla cieca dopo un'interruzione ambigua. Errori tipici derivano da parametri obbligatori mancanti, tipi dati errati, codici monouso scaduti, Origin non autorizzate o record non implementati. L'applicazione dovrebbe gestirli separatamente e registrare il messaggio di errore senza contenuti segreti. Una richiesta riuscita conferma soltanto questo passaggio, non un successivo successo e-mail, pagamento o SSO. Questo è direttamente rilevante per `GET /api/public/legal/:slug`. La verifica tecnica deve basarsi sulla Registry in `app/frontend/src/content/api-reference/` e sulle route Backend corrispondenti. Le note di test live possono affermare soltanto ciò che è stato realmente verificato. Un test negativo o un'analogia di codice non costituiscono una prova completa di successo. Va distinto chiaramente tra struttura documentata, test automatico e comportamento live osservato in sicurezza.

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