POST/api/public/contact

Zentor 網站的公開聯絡表單。在內部潛在客戶系統中建立查詢。

`POST /api/public/contact` 處理 Zentor 網站的公開聯絡表單，並將查詢記錄於內部潛在客戶系統。此端點無需儀表板認證，亦非冪等。每次成功傳送都可能產生一個新潛在客戶，因此前端應在首次點擊後停用「傳送」按鈕，並避免觸發自動重試。 已確認的必填欄位包括 `name`、`email` 及 `message`。姓名長度須介乎 2 至 120 個字元，電郵地址必須符合有效格式，訊息亦須滿足伺服器驗證規則。其他欄位僅可在實際架構中預設時方可傳送，不應使用未知數值來控制潛在客戶的內部屬性。 正確表單應先在瀏覽器內檢查必填欄位，但不可完全依賴此檢查；伺服器驗證仍為關鍵。若發生驗證錯誤，介面應標記相關欄位並保留已輸入內容。一般性成功訊息僅可在收到伺服器正面回應後才顯示。 聯絡表單並非安全渠道，不可用於傳送密碼、API 金鑰、小工具 Token、付款資料或完整客戶資料集。使用者應提供應用情境、涉及產品及可聯絡的商業電郵地址。若遇技術問題，提供租戶名稱、時間、受影響功能及可重現步驟將有助解決，同時避免不必要的個人資料傳輸。 實際流程如下：訪客填寫姓名、電郵及訊息，並確認網站的私隱政策（如適用），然後傳送表單。伺服器驗證資料、建立潛在客戶並返回成功回應。若電郵無效或姓名過短，則不會建立完整潛在客戶。此端點不會建立租戶、訂購方案，亦不會取代結構化產品配置或諮詢流程。 為防止垃圾訊息及自動化批量查詢，用戶端應尊重伺服器錯誤回應，切勿啟動即時無限循環。成功回應僅在伺服器確認接收後才清空輸入欄位；若無回應，使用者可保存內容並在稍後有控制地重新傳送。 內部分派時，訊息應包含實際事由，避免市場推廣套語或機密附件。清晰的標題及精確的問題描述可減少跟進查詢。然而，API 本身並不保證優先級，亦不確認固定的處理時限。

{"name":"Max Mustermann","email":"max@example.com","message":"您嘅訊息（最少 10 個字）","consentGiven":true}

{"ok":true,"message":"Ihre Anfrage wurde übermittelt."}