POST/api/public/contact

Formulari publik i kontaktit të faqes së Zentor. Krijon një kërkesë në sistemin e brendshëm të lead-eve.

`POST /api/public/contact` përpunon formularin publik të kontaktit të faqes së Zentor dhe e ruan kërkesën në sistemin e brendshëm të lead-eve. Pika përfundimtare nuk kërkon autentifikim në dashboard dhe nuk është idempotente. Çdo dërgim i suksesshëm mund të krijojë një lead të ri. Prandaj frontend-i duhet ta çaktivizojë butonin e dërgimit pas klikimit të parë dhe të mos shkaktojë ripërsëritje automatike. Fushat e detyrueshme të konfirmuara janë `name`, `email` dhe `message`. Emri duhet të ketë 2 deri në 120 karaktere, adresa e email-it duhet të ketë format të vlefshëm dhe mesazhi duhet të plotësojë rregullat e validimit në server. Fusha të tjera lejohen të dërgohen vetëm nëse janë të paraqitura në skemën reale. Vlerat e panjohura nuk duhet të përdoren për të kontrolluar veti të brendshme të lead-it. Një formular i saktë i kontrollon fushat e detyrueshme tashmë në shfletues, por nuk mbështetet vetëm te ky kontroll. Serveri mbetet vendimtar. Në rast gabimi validimi, ndërfaqja duhet ta shënojë fushën e prekur dhe ta ruajë përmbajtjen e futur. Një mesazh i përgjithshëm suksesi lejohet të shfaqet vetëm pas një përgjigjeje pozitive të serverit. Formulari i kontaktit nuk është kanal i sigurt për fjalëkalime, çelësa API, tokenë widget-i, të dhëna pagese ose regjistrime të plota të dhënash klientësh. Përdoruesit duhet të tregojnë rastin e përdorimit, produktin e prekur dhe një adresë të arritshme email-i biznesi. Në rast problemi teknik ndihmojnë emri i tenant-it, koha, funksioni i prekur dhe hapat e riprodhueshëm, pa dërguar përmbajtje të panevojshme personale. Një rrjedhë realiste: vizitori plotëson emrin, email-in dhe mesazhin, konfirmon nëse është e nevojshme njoftimet e privatësisë të faqes dhe e dërgon formularin. Serveri i validon të dhënat, krijon lead-in dhe kthen një përgjigje suksesi. Me email të pavlefshëm ose emër shumë të shkurtër nuk krijohet asnjë lead i plotë. Pika përfundimtare nuk krijon tenant, nuk rezervon paketë dhe nuk zëvendëson konfigurimin e strukturuar të produktit ose procesin e konsulencës. Për mbrojtje nga spam-i dhe kërkesat serike të automatizuara, klienti duhet t'i respektojë gabimet e serverit dhe të mos nisë cikle të pafundme të menjëhershme. Një përgjigje e suksesshme duhet t'i zbrazë fushat e futjes vetëm kur serveri e ka konfirmuar pranimin. Nëse përgjigjja mungon, përdoruesi mund ta ruajë përmbajtjen dhe ta dërgojë përsëri më vonë në mënyrë të kontrolluar. Për caktimin e brendshëm, mesazhi duhet të përmbajë shkakun real, pa fraza marketingu ose bashkëngjitje konfidenciale. Një subjekt i qartë dhe një përshkrim i saktë i problemit ul pyetjet shtesë. Vetë API-ja nuk cakton asnjë prioritet të garantuar dhe nuk konfirmon asnjë afat të caktuar përpunimi.

{"name":"Max Mustermann","email":"max@example.com","message":"Mesazhi juaj (paktën 10 shenja).","consentGiven":true}

{"ok":true,"message":"Kërkesa juaj u dërgua."}