GET/api/public/legal

Zwraca zbiorczo wszystkie publiczne teksty prawne (Impressum, ochrona danych, regulamin).

Strona „GET /api/public/legal — referencja API” opisuje obszar funkcjonalny wskazany w adresie URL. Istniejąca treść została uzupełniona o rzeczywisty przebieg, wymagania wstępne i znane ograniczenia. Zentor nie posiada systemu kluczy API dla deweloperów. W panelu używane są sesyjne tokeny JWT ważne dwanaście godzin oraz tokeny odświeżania ważne siedem dni; TOTP i SSO są opcjonalne. Tokeny osadzenia widżetu są wyświetlane jawnym tekstem tylko raz i są powiązane z dozwolonymi originami. Dokumentację dotyczącą `GET /api/public/legal` należy traktować jako wiążący opis techniczny tego konkretnego punktu końcowego. Decydujące są metoda, ścieżka, uwierzytelnianie, pola obowiązkowe, możliwe błędy oraz to, czy ponowne wywołanie wywołuje ten sam skutek. Ta sekcja pomocy https://zentor-app.de/hilfe/api-referenz/oeffentliche-inhalte/content.legal_list nie może więc zawierać ogólnych haseł reklamowych, a jedynie możliwe do odtworzenia kroki integracji i udokumentowane przykłady odpowiedzi. Wywołanie `/api/public/legal` buduje się zgodnie z rejestrem (Registry). Trasy publiczne nie wymagają ogólnego klucza API dla deweloperów, ponieważ Zentor nie oferuje takiego systemu kluczy. Chronione trasy widżetu używają natomiast jednorazowo wyświetlanego tokenu osadzenia i weryfikacji originu. Status HTTP i treść JSON należy oceniać łącznie; samo pole `ok` nie zastępuje obsługi błędów. Podczas testowania `GET /api/public/legal` należy używać wartości zanonimizowanych. Rzeczywiste dane klientów, produkcyjne identyfikatory UUID, tokeny sesji i konkretne znaczniki czasu nie powinny trafiać do publicznych przykładów. Znany limit dla całej platformy wynosi 2 000 żądań w ciągu 15 minut; odrębny limit dla pojedynczego punktu końcowego nie jest udokumentowany. Nieidempotentnych wywołań POST nie wolno ponawiać na ślepo po niejasnym przerwaniu połączenia sieciowego. Typowe błędy integracji dla tej trasy wynikają z brakujących parametrów obowiązkowych, nieprawidłowych typów danych, wygasłych kodów jednorazowych, niedozwolonych originów lub niezaimplementowanego rekordu danych. Aplikacja powinna obsługiwać takie przypadki osobno i rejestrować komunikat błędu zwrócony przez punkt końcowy, nie zapisując przy tym poufnych treści. Udane żądanie potwierdza wyłącznie ten etap przetwarzania, a nie automatycznie powodzenie następującego po nim wysłania e-maila, płatności lub logowania SSO. Jest to bezpośrednio istotne dla „GET /api/public/legal”. Weryfikacja techniczna tej strony musi opierać się na rejestrze w `app/frontend/src/content/api-reference/` oraz na powiązanych trasach backendu. Adnotacje z testów na żywo mogą stwierdzać wyłącznie to, co zostało faktycznie sprawdzone. Test negatywny lub analogia w kodzie nie stanowi pełnego dowodu powodzenia. Dlatego w przypadku GET /api/public/legal — referencja API należy wyraźnie rozróżniać udokumentowaną strukturę, test automatyczny i bezpiecznie zaobserwowane zachowanie na żywo.

{"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}}}