POST/api/public/contact
فرم تماس عمومی وبسایت Zentor. یک درخواست در سیستم لید داخلی ایجاد میکند.
آدرس `POST /api/public/contact`، فرم تماس عمومی وبسایت Zentor را پردازش میکند و درخواست را در سیستم داخلی مدیریت سرنخها (Lead) ثبت میکند. این نقطه پایانی نیازی به احراز هویت داشبورد ندارد و غیرایدهپذیر است. هر ارسال موفق میتواند یک سرنخ جدید ایجاد کند. بنابراین، رابط کاربری (Frontend) باید دکمه "ارسال" را پس از اولین کلیک غیرفعال کند و از تکرار خودکار جلوگیری کند. فیلدهای اجباری که باید تکمیل شوند عبارتند از: `name` (نام)، `email` (ایمیل) و `message` (پیام). نام باید بین ۲ تا ۱۲۰ نویسه باشد، آدرس ایمیل باید قالب معتبری داشته باشد، و پیام باید قوانین اعتبارسنجی سمت سرور را برآورده کند. فیلدهای اضافی فقط در صورتی باید ارسال شوند که در طرحوارهٔ واقعی پیشبینی شده باشند. مقادیر ناشناخته نباید برای کنترل ویژگیهای داخلی لید استفاده شوند. یک فرم صحیح، فیلدهای اجباری را از قبل در مرورگر بررسی میکند، اما صرفاً به این بررسی تکیه نمیکند. سرور همچنان معیار اصلی است. در صورت خطای اعتبارسنجی، رابط کاربری باید فیلد مربوطه را علامتگذاری کند و محتوای واردشده حفظ شود. پیام موفقیتآمیز عمومی فقط پس از پاسخ مثبت سرور میتواند ظاهر شود. فرم تماس کانال امنی برای رمزهای عبور، کلیدهای API، توکنهای ویجت، دادههای پرداخت یا سوابق کامل مشتری نیست. کاربران باید مورد استفاده، محصول مربوطه و یک آدرس ایمیل تجاری قابل دسترس را ارائه دهند. در صورت بروز مشکل فنی، لطفاً نام مستاجر، زمان وقوع، عملکرد تحت تأثیر و مراحل قابل تکرار را ذکر کنید، بدون اینکه اطلاعات شخصی غیرضروری را منتقل نمایید. یک سناریوی واقعی: بازدیدکننده نام، ایمیل و پیام خود را وارد میکند، در صورت لزوم، به قوانین حفظ حریم خصوصی وبسایت رضایت میدهد و فرم را ارسال میکند. سرور دادهها را اعتبارسنجی میکند، یک سرنخ (Lead) ایجاد میکند و یک پاسخ موفقیتآمیز ارسال میکند. در صورت نامعتبر بودن ایمیل یا کوتاه بودن نام، یک سرنخ کامل ایجاد نخواهد شد. این نقطه پایانی، هیچ مستاجری ایجاد نمیکند، هیچ بستهای رزرو نمیکند و پیکربندی ساختاریافته محصول یا فرآیند مشاوره را جایگزین نمیکند. برای جلوگیری از هرزنامه و درخواستهای سریالی خودکار، کلاینت باید خطاهای سمت سرور را رعایت کند و از ایجاد حلقههای بینهایت فوری خودداری کند. یک پاسخ موفق، فقط زمانی باید فیلدهای ورودی را خالی کند که سرور، پذیرش را تأیید کرده باشد. در صورتی که پاسخی دریافت نشود، کاربر میتواند محتوا را ذخیره کرده و بعداً به صورت کنترلشده، مجدداً ارسال کند. برای تخصیص داخلی، پیام باید شامل دلیل واقعی باشد، بدون هیچگونه عبارت تبلیغاتی یا فایلهای ضمیمه محرمانه. یک عنوان واضح و یک توضیح دقیق از مشکل، احتمال پرسشهای بیشتر را کاهش میدهد. با این حال، API به خودی خود، اولویت تضمینشدهای ارائه نمیدهد و هیچ مهلت پردازش مشخصی را تایید نمیکند.
Auth & Absicherung
Keine Authentifizierung erforderlich
Idempotent: Nein
Parameter
name(body, string, erforderlich)— 2–120 کاراکترemail(body, string, erforderlich)— آدرس ایمیل معتبرmessage(body, string, erforderlich)— 10–3000 نویسهcompany(body, string)phone(body, string)topic(body, string)consentGiven(body, boolean, erforderlich)— باید true باشد (رضایت حفاظت از دادهها)Beispiel-Request
{"name":"Max Mustermann","email":"max@example.com","message":"پیام شما (حداقل ۱۰ کاراکتر).","consentGiven":true}Beispiel-Response
{"ok":true,"message":"درخواست شما ارسال شد."}Fehlercodes
400 VALIDATION_ERROR — فیلد الزامی وجود ندارد/نامعتبر است، یا رضایت حفظ حریم خصوصی وجود ندارد (آرایه جزئیات با پیامهای خطای جداگانه).Live-Test-Nachweis
موفقیت (200) و حالت منفی (400، فیلدهای缺失 شامل عدم رضایت) بهصورت زنده تأیید شد.