POST/api/public/contact
Form liên hệ công cộng của trang web Zentor. Tạo yêu cầu trong hệ thống Lead nội bộ.
`POST /api/public/contact` xử lý biểu mẫu liên hệ công khai của trang web Zentor và lưu yêu cầu vào hệ thống Lead nội bộ. Điểm cuối này không yêu cầu xác thực Dashboard và không có tính idempotent. Mỗi lần gửi thành công có thể tạo ra một Lead mới. Do đó, giao diện người dùng nên vô hiệu hóa nút Gửi sau lần nhấp đầu tiên và không kích hoạt các lần lặp lại tự động. Các trường bắt buộc đã được xác nhận bao gồm `name`, `email` và `message`. Tên phải có độ dài từ 2 đến 120 ký tự, địa chỉ email phải có định dạng hợp lệ, và nội dung tin nhắn phải tuân thủ các quy tắc xác thực trên máy chủ. Các trường bổ sung chỉ được gửi nếu chúng được quy định trong lược đồ thực tế. Không nên sử dụng các giá trị không xác định để điều khiển các thuộc tính nội bộ của Lead. Một biểu mẫu chính xác sẽ kiểm tra các trường bắt buộc ngay trên trình duyệt nhưng không chỉ dựa vào việc kiểm tra này. Máy chủ vẫn đóng vai trò quyết định. Khi xảy ra lỗi xác thực, giao diện phải đánh dấu trường bị ảnh hưởng và giữ nguyên nội dung đã nhập. Thông báo thành công chung chỉ nên xuất hiện sau khi nhận được phản hồi tích cực từ máy chủ. Biểu mẫu liên hệ không phải là kênh an toàn cho mật khẩu, khóa API, token Widget, dữ liệu thanh toán hoặc hồ sơ khách hàng đầy đủ. Người dùng nên cung cấp trường hợp sử dụng, sản phẩm liên quan và địa chỉ email kinh doanh có thể liên hệ. Khi gặp vấn đề kỹ thuật, tên Tenant, thời điểm, chức năng bị ảnh hưởng và các bước tái tạo sẽ giúp ích, trong khi không truyền tải các nội dung cá nhân không cần thiết. Quy trình thực tế: Người truy cập điền tên, email và tin nhắn, xác nhận các lưu ý về bảo mật dữ liệu nếu cần và gửi biểu mẫu. Máy chủ xác thực dữ liệu, tạo Lead và trả về phản hồi thành công. Nếu email không hợp lệ hoặc tên quá ngắn, Lead hoàn chỉnh sẽ không được tạo. Điểm cuối này không tạo Tenant, không ghi nhận gói dịch vụ và không thay thế cấu hình sản phẩm có cấu trúc hoặc quy trình tư vấn. Để bảo vệ chống lại spam và các yêu cầu tự động hàng loạt, client phải tôn trọng lỗi từ máy chủ và không khởi động các vòng lặp vô tận ngay lập tức. Phản hồi thành công chỉ nên làm trống các trường nhập liệu khi máy chủ đã xác nhận chấp nhận. Nếu không nhận được phản hồi, người dùng có thể lưu nội dung và gửi lại một cách có kiểm soát sau này. Đối với việc phân loại nội bộ, tin nhắn cần nêu rõ lý do thực tế, tránh các cụm từ tiếp thị hoặc các tệp đính kèm nhạy cảm. Tiêu đề rõ ràng và mô tả vấn đề chính xác sẽ giảm thiểu các câu hỏi phản hồi. Tuy nhiên, chính API cũng không đảm bảo cấp độ ưu tiên và không xác nhận thời hạn xử lý cố định.
Xác thực & bảo mật
Không cần xác thực
Lũy đẳng (idempotent): Không
Tham số
name(body, string, bắt buộc)— 2–120 ký tựemail(body, string, bắt buộc)— Địa chỉ email hợp lệmessage(body, string, bắt buộc)— 10–3000 ký tựcompany(body, string)phone(body, string)topic(body, string)consentGiven(body, boolean, bắt buộc)— Phải là true (đồng ý bảo vệ dữ liệu)Request mẫu
{"name":"Max Mustermann","email":"max@example.com","message":"Tin nhắn của bạn (tối thiểu 10 ký tự).","consentGiven":true}Response mẫu
{"ok":true,"message":"Yêu cầu của bạn đã được gửi."}Mã lỗi
400 VALIDATION_ERROR — Thiếu trường bắt buộc/không hợp lệ, hoặc thiếu đồng ý bảo vệ dữ liệu (mảng chi tiết với các thông báo lỗi riêng lẻ).Bằng chứng kiểm thử trực tiếp
Thành công (200) và trường hợp tiêu cực (400, bao gồm cả các trường bị thiếu, kể cả sự đồng ý bị thiếu) đã được xác minh trực tuyến.