Dokumentacja API

Ta referencja opisuje wyłącznie rzeczywiste, publicznie dostępne punkty końcowe JSON -- metodę, ścieżkę, typ uwierzytelniania, parametry obowiązkowe, przykładowe żądanie i odpowiedź oraz udokumentowane kody błędów dla każdego punktu końcowego. Zentor nie posiada ogólnego systemu kluczy API dla deweloperów; w zależności od trasy dostęp odbywa się bez uwierzytelniania albo za pomocą tokenu osadzenia widżetu z weryfikacją originu. Wewnętrzne trasy panelu i punkty końcowe Master Admin celowo nie są częścią tej publicznej referencji, ponieważ są dostępne wyłącznie w ramach zwykłej sesji logowania.

Każdy wpis punktu końcowego zawiera adnotację z testu na żywo, która ujawnia, czy informacja pochodzi ze schematu rejestru, z testu automatycznego, czy z rzeczywistej obserwacji na żywo -- samo podobieństwo do działającej ścieżki kodu nie jest uznawane za pełny dowód. Technicznie udane wywołanie potwierdza ponadto zawsze wyłącznie przetworzenie danego żądania, a nie automatycznie dalsze procesy, takie jak doręczenie e-maila, sfinalizowanie płatności czy zakończone logowanie SSO.

Zabezpieczenie zależy od danej grupy. Publiczne punkty końcowe prawne, marketingowe i formularzy nie wymagają sesji panelu. Widżet czatu używa natomiast nagłówka `X-Widget-Token` i listy dozwolonych originów (allowlist). Logowanie do panelu zwraca sesyjny token JWT ważny dwanaście godzin oraz token odświeżania ważny siedem dni. Punkty końcowe SSO działają z własnymi kodami jednorazowymi i przebiegami callback.

Każdą stronę punktu końcowego należy czytać jako samodzielny kontrakt. Decydujące są metoda HTTP, ścieżka, parametry obowiązkowe, typy danych, treść żądania, struktura odpowiedzi, kody błędów i idempotentność. Przykład pokazuje możliwy format, ale nie zastępuje sprawdzenia rzeczywistej odpowiedzi. Stan konfiguracji, walidacje, uprawnienia i zewnętrzni dostawcy mogą zmienić wynik.

Potwierdzony limit dla całej platformy wynosi 2 000 żądań w ciągu 15 minut. Odrębne limity dla poszczególnych punktów końcowych nie są konsekwentnie udokumentowane. Klienci nie powinni więc stosować niepotrzebnie gęstych pętli odpytywania. Przy operacjach nieidempotentnych automatyczne ponowienia mogą tworzyć zduplikowane rekordy lub wiadomości.

Wrażliwe wartości nie powinny trafiać do logów. Należą do nich hasła, tokeny resetowania, kody weryfikacyjne, tokeny widżetu, identyfikatory sesji i rzeczywiste przykładowe dane osobowe. W dokumentacji i testach używaj wartości zanonimizowanych. Adnotacje z testów na żywo muszą poprawnie odzwierciedlać faktyczny dowód.