POST/api/public/contact
Offentligt kontaktformulär för Zentor-webbplatsen. Skapa en förfrågan i det interna lead-systemet.
`POST /api/public/contact` hanterar det offentliga kontaktformuläret på Zentors webbplats och lägger in förfrågan i det interna lead-systemet. Endpointen kräver ingen dashboard-autentisering och är inte idempotent. Varje lyckad inskickning kan skapa ett nytt lead. Frontenden bör därför inaktivera skicka-knappen efter det första klicket och inte utlösa några automatiska upprepningar. Till de bekräftade obligatoriska fälten hör `name`, `email` och `message`. Namnet måste vara mellan 2 och 120 tecken långt, e-postadressen måste ha ett giltigt format och meddelandet måste uppfylla valideringsreglerna på serversidan. Ytterligare fält får endast skickas om de finns med i det faktiska schemat. Okända värden bör inte användas för att styra interna egenskaper hos lead:et. Ett korrekt formulär kontrollerar de obligatoriska fälten redan i webbläsaren men förlitar sig inte enbart på den kontrollen. Servern är avgörande. Vid ett valideringsfel bör gränssnittet markera det berörda fältet och behålla de inmatade uppgifterna. Ett generellt framgångsmeddelande får inte visas förrän servern har svarat positivt. Kontaktformuläret är ingen säker kanal för lösenord, API-nycklar, widget-tokens, betalningsuppgifter eller fullständiga kunddatauppsättningar. Användare bör ange användningsfallet, den berörda produkten och en nåbar e-postadress för företaget. Vid ett tekniskt problem hjälper tenantnamn, tidpunkt, berörd funktion och reproducerbara steg, utan att onödiga personuppgifter överförs. Ett realistiskt förlopp: Besökaren fyller i namn, e-post och meddelande, bekräftar vid behov sidans dataskyddsinformation och skickar formuläret. Servern validerar uppgifterna, skapar lead:et och returnerar ett framgångssvar. Vid en ogiltig e-postadress eller ett för kort namn skapas inget fullständigt lead. Endpointen skapar ingen tenant, bokar inget paket och ersätter inte den strukturerade produktkonfigurationen eller rådgivningsprocessen. Som skydd mot spam och automatiserade serieförfrågningar bör klienten respektera felen från servern och inte starta omedelbara oändliga loopar. Ett lyckat svar bör tömma inmatningsfälten först när servern har bekräftat mottagandet. Uteblir svaret kan användaren spara innehållet och skicka det kontrollerat på nytt senare. För den interna tilldelningen bör meddelandet innehålla den faktiska anledningen, utan marknadsföringsfraser eller konfidentiella bilagor. Ett tydligt ämne och en exakt problembeskrivning minskar antalet följdfrågor. API:et själv tilldelar dock ingen garanterad prioritet och bekräftar ingen fast handläggningstid.
Autentisering & säkerhet
Ingen autentisering krävs
Idempotent: Nej
Parametrar
name(body, string, obligatorisk)— 2–120 teckenemail(body, string, obligatorisk)— Giltig e-postadressmessage(body, string, obligatorisk)— 10–3000 teckencompany(body, string)phone(body, string)topic(body, string)consentGiven(body, boolean, obligatorisk)— Måste vara true (samtycke till dataskydd)Exempel på request
{"name":"Max Mustermann","email":"max@example.com","message":"Ditt meddelande (minst 10 tecken).","consentGiven":true}Exempel på response
{"ok":true,"message":"Din förfrågan har skickats in."}Felkoder
400 VALIDATION_ERROR — Obligatoriskt fält saknas/är ogiltigt, eller samtycke till dataskydd saknas (details-array med enskilda felmeddelanden).Bevis från livetest
Framgång (200) och negativt fall (400, saknade fält inklusive saknat samtycke) verifierade live.