POST/api/public/consultation

Öffentliches Beratungsanfrage-Formular der Zentor-Website.

Die Seite „POST /api/public/consultation — API-Referenz“ behandelt den in der URL bezeichneten Funktionsbereich. Der vorhandene Inhalt wird um den tatsächlichen Ablauf, die Voraussetzungen und die bekannten Grenzen ergänzt. Der Formular-Baukasten unterstützt frei konfigurierbare Formulare mit Trigger-Schlüsselwörtern, Feldtypen und Pflichtfeld-Kennzeichnung. Die Funktion ist E2E-getestet. Die Dokumentation zu `POST /api/public/consultation` muss als technische Beschreibung dieses konkreten Endpunkts gelesen werden. Entscheidend sind Methode, Pfad, Authentifizierung, Pflichtfelder, mögliche Fehler und die Frage, ob ein erneuter Aufruf denselben Effekt auslöst. Die vorliegende URL https://zentor-app.de/hilfe/api-referenz/formulare/forms.consultation darf deshalb keine allgemeinen Werbeaussagen enthalten, sondern nur sobaldvollziehbare Integrationsschritte und belegte Antwortbeispiele. Für einen Aufruf von `/api/public/consultation` wird die Anfrage entsprechend der Registry aufgebaut. Öffentliche Routen benötigen keinen allgemeinen Entwickler-API-Schlüssel, weil Zentor kein solches Schlüsselsystem anbietet. Geschützte Widget-Routen verwenden dagegen den einmalig angezeigten Embed-Token und eine Origin-Prüfung. Der HTTP-Status und der JSON-Inhalt müssen gemeinsam ausgewertet werden; ein `ok`-Feld allein ersetzt keine Fehlerbehandlung. Beim Test von `POST /api/public/consultation` sind anonymisierte Werte zu verwenden. Reale Kundendaten, produktive UUIDs, Sitzungs-Tokens und konkrete Zeitstempel gehören nicht in öffentliche Beispiele. Der bekannte plattformweite Grenzwert liegt bei 2.000 Anfragen innerhalb von 15 Minuten; ein abweichendes Einzellimit ist nicht belegt. Nicht idempotente POST-Aufrufe dürfen nach einem unklaren Netzwerkabbruch nicht blind wiederholt werden. Typische Integrationsfehler für diese Route entstehen durch fehlende Pflichtparameter, falsche Datentypen, abgelaufene Einmalcodes, nicht erlaubte Origins oder einen nicht im Vorfeld vorhandenen Datensatz. Die Anwendung sollte solche Fälle getrennt behandeln und die vom Endpunkt zurückgelieferte Fehlermeldung protokollieren, ohne geheime Inhalte mitzuschreiben. Ein erfolgreicher Request bestätigt nur diesen Verarbeitungsschritt, nicht automatisch einen sobaldgelagerten E-Mail-, Zahlungs- oder SSO-Erfolg. Dies ist für „POST /api/public/consultation“ unmittelbar relevant. Die technische Prüfung dieser Seite soll verbindlich sich auf die Registry unter `app/frontend/src/content/api-reference/` und die zugehörigen Backend-Routen stützen. Live-Test-Vermerke dürfen nur das behaupten, was tatsächlich geprüft wurde. Ein Negativtest oder eine Code-Analogie ist kein vollständiger Erfolgsim Anschluss anweis. Für POST /api/public/consultation — API-Referenz ist daher klar zwischen dokumentierter Struktur, automatisiertem Test und sicher beobachtetem Live-Verhalten zu unterscheiden.

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

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