POST/api/public/contact
Modulo contatto pubblico del sito Zentor. Crea una richiesta nel sistema Lead interno.
`POST /api/public/contact` elabora il modulo contatto pubblico del sito Zentor e salva la richiesta nel sistema Lead interno. L'endpoint non richiede autenticazione dashboard e non è idempotente. Ogni invio riuscito può creare un nuovo Lead. Il Frontend dovrebbe quindi disattivare il pulsante Invia dopo il primo clic e non attivare retry automatici. Tra i campi obbligatori confermati rientrano `name`, `email` e `message`. Il nome deve avere tra 2 e 120 caratteri, l'indirizzo e-mail deve avere un formato valido e il messaggio deve rispettare le regole di validazione lato server. Altri campi possono essere inviati solo se previsti dallo schema reale. Valori sconosciuti non devono essere usati per tentare di controllare proprietà interne del Lead. Un modulo corretto verifica i campi obbligatori già nel browser, ma non si affida esclusivamente a questa verifica. Il server resta autoritativo. In caso di errore di validazione l'interfaccia dovrebbe evidenziare il campo interessato e mantenere i contenuti inseriti. Una generica conferma di successo può comparire solo dopo una risposta positiva del server. Il modulo contatto non è un canale sicuro per password, API Key, Widget Token, dati di pagamento o set completi di dati cliente. Gli utenti dovrebbero indicare caso d'uso, prodotto interessato e un indirizzo e-mail aziendale raggiungibile. In caso di problema tecnico sono utili nome Tenant, orario, funzione interessata e passaggi riproducibili, senza trasmettere contenuti personali non necessari. Flusso realistico: il visitatore compila nome, e-mail e messaggio, conferma se necessario le informazioni privacy della pagina e invia il modulo. Il server valida i dati, crea il Lead e restituisce una risposta di successo. Con e-mail non valida o nome troppo corto non viene creato un Lead completo. L'endpoint non crea un Tenant, non prenota un pacchetto e non sostituisce la configurazione prodotto strutturata o il processo di consulenza. Per proteggersi da spam e richieste seriali automatizzate, il client deve rispettare gli errori lato server e non avviare loop immediati infiniti. Una risposta di successo dovrebbe svuotare i campi soltanto dopo che il server ha confermato l'accettazione. Se la risposta non arriva, l'utente può salvare il contenuto e inviarlo successivamente in modo controllato. Per l'assegnazione interna, il messaggio dovrebbe contenere il motivo reale senza frasi marketing o allegati riservati. Un oggetto chiaro e una descrizione precisa del problema riducono le domande successive. La API non assegna tuttavia una priorità garantita né conferma un termine fisso di elaborazione.
Autenticazione e sicurezza
Nessuna autenticazione richiesta
Idempotente: No
Parametri
name(body, string, obbligatorio)— 2–120 caratteriemail(body, string, obbligatorio)— Indirizzo e-mail validomessage(body, string, obbligatorio)— 10–3000 carattericompany(body, string)phone(body, string)topic(body, string)consentGiven(body, boolean, obbligatorio)— Deve essere true (consenso privacy)Richiesta di esempio
{"name":"Max Mustermann","email":"max@example.com","message":"Il vostro messaggio (min. 10 caratteri).","consentGiven":true}Risposta di esempio
{"ok":true,"message":"Ihre Anfrage wurde übermittelt."}Codici di errore
400 VALIDATION_ERROR — Campo obbligatorio mancante/non valido oppure consenso privacy mancante (array Details con singoli messaggi di errore).Prova del test live
Successo (200) e caso negativo (400, campi mancanti incluso consenso mancante) verificati live.