POST/api/public/consultation

Publiczny formularz zapytania doradczego strony Zentor.

Strona „POST /api/public/consultation — 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. Kreator formularzy obsługuje dowolnie konfigurowalne formularze ze słowami kluczowymi wyzwalającymi, typami pól i oznaczaniem pól obowiązkowych. Funkcja została przetestowana E2E. Dokumentację dotyczącą `POST /api/public/consultation` trzeba traktować jako 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. Niniejszy adres URL https://zentor-app.de/hilfe/api-referenz/formulare/forms.consultation 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/consultation` 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 `POST /api/public/consultation` 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 rekordu danych, który wcześniej nie istniał. 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 „POST /api/public/consultation”. 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 POST /api/public/consultation — referencja API należy wyraźnie rozróżniać udokumentowaną strukturę, test automatyczny i bezpiecznie zaobserwowane zachowanie na żywo.

Uwierzytelnianie i zabezpieczenia

Uwierzytelnianie nie jest wymagane

Idempotentny: Nie

Parametry

name(body, string, wymagane)— 2–120 znaków
email(body, string, wymagane)— Prawidłowy adres e-mail
company(body, string)
message(body, string)
phone(body, string)
consentGiven(body, boolean, wymagane)— Musi być true

Przykładowe żądanie

{"name":"Max Mustermann","email":"max@example.com","company":"Musterfirma","message":"Sprawa","consentGiven":true}

Przykładowa odpowiedź

{"ok":true,"message":"Twoje zapytanie doradcze zostało wysłane. Skontaktujemy się z Tobą wkrótce."}

Kody błędów

400 VALIDATION_ERROR — Brakuje pola obowiązkowego lub jest nieprawidłowe, lub brakuje zgody.

Dowód z testu na żywo

Pomyślny (200) i negatywny (400) przypadek zweryfikowano na żywo.

← Publiczne formularze