GET/api/public/legal

Összegyűjti az összes nyilvános jogi szöveget (Impresszum, adatvédelem, ÁSZF).

A „GET /api/public/legal — 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-beágyazási tokeneket egyszer jelenítik meg tisztaszöveges formátumban, és engedélyezett eredetű (origin) URL-ekhez kötöttek. A `GET /api/public/legal` dokumentációját kötelező érvényű műszaki leírásként kell értelmezni erre a konkrét végpontra. 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 egy újrahí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_list) nem tartalmazhat általános reklámállításokat, csupán utólag ellenőrizhető integrációs lépéseket és igazolt válaszpéldákat. A `/api/public/legal` 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 egyszer megjelenített beágyazási 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` 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 vonatkozó 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 egy tisztázatlan hálózati megszakítás után nem szabad vakon ismételni. Ennek az útvonalnak a tipikus integrációs hibái 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 merülnek fel. Az alkalmazásnak ezeket az eseteket külön kell kezelnie, és naplóznia kell a végpontról visszaadott hibaüzenetet, titkos tartalmak rögzítése nélkül. Egy 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” esetében. Ennek az oldalnak a műszaki 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ő tesztelési megjegyzések csak azt állíthatják, amit ténylegesen ellenőriztek. Egy negatív teszt vagy egy kód-analógia nem teljes sikerigazolás. A GET /api/public/legal — 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":{"impressum":{"body_html":"...","updated_at":null,"version":0},"datenschutz":{"body_html":"...","updated_at":null,"version":0},"agb":{"body_html":"...","updated_at":null,"version":0}}}