POST/api/public/consultation

Modulo pubblico di richiesta consulenza del sito Zentor.

La pagina «POST /api/public/consultation — Riferimento API» descrive l'area funzionale identificata dalla URL. Il contenuto esistente viene ampliato con workflow reale, prerequisiti e limiti noti. Il Form Builder supporta moduli liberamente configurabili con keyword Trigger, tipi di campo e flag obbligatorio. La funzione è testata E2E. La documentazione di `POST /api/public/consultation` deve essere letta come descrizione tecnica di questo endpoint specifico. Sono decisivi metodo, percorso, autenticazione, campi obbligatori, possibili errori e la questione se un nuovo richiamo produca lo stesso effetto. La URL https://zentor-app.de/hilfe/api-referenz/formulare/forms.consultation non deve quindi contenere affermazioni pubblicitarie generiche ma soltanto passaggi di integrazione tracciabili ed esempi di risposta comprovati. Per una chiamata a `/api/public/consultation`, la richiesta viene costruita secondo la Registry. Le route pubbliche non richiedono una Developer API Key generale perché Zentor non offre questo sistema. Le route Widget protette usano invece l'Embed Token mostrato una sola volta e una verifica Origin. Stato HTTP e contenuto JSON devono essere valutati insieme; un campo `ok` da solo non sostituisce la gestione errori. Nei test di `POST /api/public/consultation` vanno usati valori anonimizzati. Veri dati cliente, UUID produttivi, Session Token e timestamp concreti non devono comparire negli esempi pubblici. Il limite noto della piattaforma è 2.000 richieste in 15 minuti; non è dimostrato un limite individuale diverso. Le POST non idempotenti non devono essere ritentate alla cieca dopo un'interruzione di rete ambigua. Errori tipici derivano da parametri obbligatori mancanti, tipi dati errati, codici monouso scaduti, Origin non autorizzate o record non presenti in precedenza. L'applicazione dovrebbe gestire separatamente tali casi e registrare il messaggio di errore restituito dall'endpoint senza scrivere contenuti segreti. Una richiesta riuscita conferma soltanto questo passaggio di elaborazione, non automaticamente un successivo successo e-mail, pagamento o SSO. Questo è direttamente rilevante per `POST /api/public/consultation`. La verifica tecnica della pagina deve basarsi obbligatoriamente sulla Registry in `app/frontend/src/content/api-reference/` e sulle route Backend corrispondenti. Le note di test live possono affermare soltanto ciò che è stato realmente verificato. Un test negativo o un'analogia di codice non costituiscono una prova completa di successo. Va quindi distinto chiaramente tra struttura documentata, test automatico e comportamento live osservato in sicurezza.

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

{"ok":true,"message":"Ihre Beratungsanfrage wurde übermittelt. Wir melden uns in Kürze bei Ihnen."}