POST/api/public/contact

Publiczny formularz kontaktowy strony Zentor. Tworzy zapytanie w wewnętrznym systemie leadów.

`POST /api/public/contact` przetwarza publiczny formularz kontaktowy strony Zentor i rejestruje zapytanie w wewnętrznym systemie leadów. Punkt końcowy nie wymaga uwierzytelniania w panelu sterowania i nie jest idempotentny. Każda udana wysyłka może wygenerować nowy lead. Z tego powodu interfejs użytkownika powinien po pierwszym kliknięciu wyłączyć przycisk Wyślij i nie inicjować automatycznych ponowień. Do potwierdzonych pól wymaganych należą `name`, `email` oraz `message`. Nazwa musi mieć długość od 2 do 120 znaków, adres e-mail musi mieć poprawny format, a wiadomość musi spełniać reguły walidacji po stronie serwera. Dodatkowe pola można wysyłać tylko wtedy, gdy są przewidziane w faktycznym schemacie. Nieznane wartości nie powinny być używane do sterowania wewnętrznymi właściwościami leadu. Poprawny formularz sprawdza pola wymagane już w przeglądarce, ale nie polega wyłącznie na tej walidacji. Decydujące pozostaje serwer. W przypadku błędu walidacji interfejs powinien oznaczyć pole, którego dotyczy błąd i zachować wprowadzone dane. Ogólna wiadomość o sukcesie może pojawić się dopiero po pozytywnej odpowiedzi serwera. Formularz kontaktowy nie jest bezpiecznym kanałem do przesyłania haseł, kluczy API, tokenów widgetów, danych płatności lub kompletnych zestawów danych klientów. Użytkownicy powinni podać cel zastosowania, produkt, którego dotyczy sprawa oraz osiągalny adres e-mail biznesowy. W przypadku problemów technicznych pomocne są nazwa tenanta, moment wystąpienia, funkcja, której dotyczy problem i powtarzalne kroki, bez nadmiernego przekazywania danych osobowych. Realistyczny przebieg: odwiedzający wypełnia nazwę, e-mail i wiadomość, ewentualnie potwierdza informacje o ochronie danych na stronie i wysyła formularz. Serwer waliduje dane, tworzy lead i zwraca odpowiedź o sukcesie. W przypadku nieprawidłowego e-maila lub zbyt krótkiej nazwy nie powstaje pełny lead. Punkt końcowy nie tworzy tenanta, nie wykupuje pakietu i nie zastępuje ustrukturyzowanej konfiguracji produktu ani procesu doradztwa. W celu ochrony przed spamem i zautomatyzowanymi seriami zapytań klient powinien szanować błędy po stronie serwera i nie uruchamiać natychmiastowych pętli nieskończonych. Udana odpowiedź powinna opróżniać pola wprowadzania dopiero po potwierdzeniu przyjęcia przez serwer. Jeśli odpowiedź nie nastąpi, użytkownik może zapisać treść i później kontrolnie ponownie wysłać. Dla wewnętrznego przypisania wiadomość powinna zawierać rzeczywisty powód, bez frazesów marketingowych lub poufnych załączników. Jasny temat i precyzyjne opisanie problemu zmniejszają konieczność ponownych pytań. API samo jednak nie nadaje gwarantowanego priorytetu ani nie potwierdza stałego terminu realizacji.

{"name":"Max Mustermann","email":"max@example.com","message":"Twoja wiadomość (min. 10 znaków).","consentGiven":true}

{"ok":true,"message":"Twoje zapytanie zostało wysłane."}