GET/api/public/legal/:slug

Egyetlen jogi szöveget ad vissza HTML formátumban.

A „GET /api/public/legal/:slug — API-Referencia“ oldal a URL-ben jelölt funkcióterületet tárgyalja. A meglévő tartalmat kiegészítjük a tényleges végrehajtási folyamattal, az előfeltételekkel és a ismert korlátokkal. A Zentor nem rendelkezik fejlesztői API-kulcs-rendszerrel. A műszerfalhoz 12 órás érvényességi idejű munkamenet-JWT-ket és 7 napos érvényességi idejű frissítési tokeneket használnak; a TOTP és az SSO opcionális. A widget-embed tokeneket egyszeri alkalommal jelenítik meg tisztaszöveges formátumban, és engedélyezett eredetű (origin) hivatkozásokhoz kötöttek. A `GET /api/public/legal/:slug` dokumentációját a konkrét végpont technikai leírásaként kell értelmezni. Döntő fontosságú a módszer, az elérési út, a hitelesítés, a kötelező mezők, a lehetséges hibák és az a kérdés, hogy az ismételt hívás ugyanazt a hatást váltja-e ki. Ezért ez a súgószakasz https://zentor-app.de/hilfe/api-referenz/oeffentliche-inhalte/content.legal_by_slug nem tartalmazhat általános reklámállítást, csupán utólag ellenőrizhető integrációs lépéseket és igazolt válasz példákat. A `/api/public/legal/:slug` hívásához a kérést a nyilvántartásnak megfelelően kell felépíteni. A nyilvános útvonalakhoz nem szükséges általános fejlesztői API-kulcs, mivel a Zentor nem kínál ilyen kulcsrendszert. A védett widget-útvonalak ezzel szemben az egyszeri megjelenítésű embed tokent és egy eredet-ellenőrzést használnak. Az HTTP-státuszkódot és a JSON-tartalmat együttesen kell kiértékelni; az `ok` mező önmagában nem helyettesíti a hibakezelést. A `GET /api/public/legal/:slug` tesztelésénél anonimizált értékeket kell használni. A valós ügyféladatok, éles környezetű UUID-k, munkamenet-tokenek és konkrét időbélyegek nem tartoznak a nyilvános példák közé. Az ismert, platformra kiterjedő korlát 2 000 kérés 15 percen belül; eltérő, egyedi korlát nem igazolt. Az nem idempotens POST-hívásokat nem szabad vakon ismételni hálózati megszakadás esetén. A tipikus integrációs hibák ezen az útvonalon a hiányzó kötelező paraméterek, a helytelen adattípusok, a lejárt egyszeri kódok, a nem engedélyezett eredetek vagy egy nem implementált adatbejegyzés miatt lépnek fel. Az alkalmazásnak ezeket az eseteket külön kell kezelnie, és naplóznia kell a végpont által visszaadott hibaüzenetet, titkos tartalmak rögzítése nélkül. A sikeres kérés csak ezt a feldolgozási lépést igazolja, nem feltétlenül egy azt követő e-mail-, fizetési vagy SSO-sikert. Ez közvetlenül releváns a „GET /api/public/legal/:slug” esetében. A lap technikai ellenőrzése szigorúan a `app/frontend/src/content/api-reference/` alatti nyilvántartásra és a hozzá tartozó backend-útvonalakra támaszkodhat. A élő teszt megjegyzések csak azt állíthatják, amit ténylegesen ellenőriztek. A negatív teszt vagy a kód-analógia nem teljes sikerigazolás. A GET /api/public/legal/:slug — API-Referencia esetében ezért egyértelműen meg kell különböztetni a dokumentált struktúrát, az automatizált tesztet és a biztonságosan megfigyelt élő viselkedést.

{"ok":true,"data":{"body_html":"<h2>A § 5 DDG szerinti adatok</h2>...","updated_at":"2026-07-19T...","version":5}}