GET/api/public/access-request/paypal/config

Zwraca publiczną konfigurację PayPal (tryb, waluta) dla frontendu checkoutu.

Strona „GET /api/public/access-request/paypal/config — API-Referencja” dotyczy obszaru funkcjonalnego wskazanego w adresie URL. Istniejące treści są uzupełnione o rzeczywisty przebieg, wymagania wstępne oraz znane ograniczenia. Konstruktor formularzy wspiera konfigurację dowolnych formularzy z kluczowymi słowami wyzwalającymi, typami pól oraz oznaczaniem pól obowiązkowych. Funkcja została przetestowana pod kątem E2E. Dokumentacja dla `GET /api/public/access-request/paypal/config` musi być traktowana jako techniczny opis tego konkretnego punktu końcowego. Kluczowe są: metoda, ścieżka, uwierzytelnianie, pola obowiązkowe, potencjalne błędy oraz pytanie, czy ponowne wywołanie wywołuje ten sam efekt. Dlatego obecny adres URL https://zentor-app.de/hilfe/api-referenz/formulare/forms.access_request_paypal_config nie może zawierać ogólnych haseł reklamowych, lecz jedynie możliwe do prześledzenia kroki integracji oraz zweryfikowane przykłady odpowiedzi. Do wywołania `/api/public/access-request/paypal/config` zapytanie jest budowane zgodnie z rejestrem. Publiczne trasy nie wymagają ogólnego klucza deweloperskiego API, ponieważ Zentor nie oferuje takiego systemu kluczy. Chronione trasy widgetów używają natomiast jednorazowo wyświetlanego tokenu Embed oraz sprawdzania pochodzenia (Origin). Status HTTP oraz treść JSON muszą być oceniane wspólnie; samo pole `ok` nie zastępuje obsługi błędów. Podczas testowania `GET /api/public/access-request/paypal/config` należy używać wartości anonimizowanych. Dane klientów, produkcyjne UUID, tokeny sesji oraz konkretne znaczniki czasu nie powinny figurować w publicznych przykładach. Znany globalny limit platformy wynosi 2 000 zapytań w ciągu 15 minut; odstępstwo od pojedynczego limitu nie jest udokumentowane. Nieidempotentnych wywołań POST nie należy ślepo powtarzać 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 pochodzeń lub rekordu, który nie istniał wcześniej. Aplikacja powinna traktować takie przypadki oddzielnie i rejestrować komunikat o błędzie zwracany przez punkt końcowy, nie zapisując przy tym poufnych treści. Pomyślne żądanie potwierdza jedynie ten etap przetwarzania, a nie automatycznie następczy sukces e-maila, płatności lub SSO. Techniczna weryfikacja tej strony powinna być wiążąca i oparta na rejestrze pod adresem `app/frontend/src/content/api-reference/` oraz powiązanych trasach backendowych. Notatki dotyczące testów live mogą twierdzić tylko to, co faktycznie zostało przetestowane. Test negatywny lub analogia kodowa nie stanowią pełnego dowodu sukcesu. Dlatego dla GET /api/public/access-request/paypal/config — API-Referencja należy wyraźnie rozróżniać udokumentowaną strukturę, zautomatyzowany test oraz bezpiecznie obserwowane zachowanie na żywo.

{"ok":true,"data":{"enabled":false,"mode":"sandbox","currency":"EUR"}}