POST/api/public/contact

Zentor ویب سائٹ کا عوامی رابطہ فارم۔ یہ اندرونی لیڈ سسٹم میں درخواست درج کرتا ہے۔

`POST /api/public/contact` Zentor ویب سائٹ کے عوامی رابطہ فارم کو پروسیس کرتا ہے اور انکوائری کو اندرونی لیڈ سسٹم میں محفوظ کرتا ہے۔ اس اینڈ پوائنٹ کے لیے ڈیش بورڈ آتھنٹیکیشن ضروری نہیں اور یہ idempotent نہیں ہے۔ ہر کامیاب ارسال ایک نیا لیڈ بنا سکتا ہے۔ اس لیے فرنٹ اینڈ کو پہلے کلک کے بعد بھیجنے کا بٹن غیر فعال کرنا چاہیے اور خودکار دہرانے (Retries) نہیں چلانے چاہییں۔ تصدیق شدہ لازمی فیلڈز میں `name`، `email` اور `message` شامل ہیں۔ نام 2 سے 120 حروف کے درمیان ہونا چاہیے، ای میل ایڈریس کا فارمیٹ درست ہونا چاہیے اور پیغام کو سرور سائیڈ ویلیڈیشن قواعد پورے کرنے چاہییں۔ مزید فیلڈز صرف تب بھیجے جا سکتے ہیں جب وہ اصل اسکیما میں موجود ہوں۔ نامعلوم ویلیوز کو لیڈ کی اندرونی خصوصیات کنٹرول کرنے کے لیے استعمال نہیں کرنا چاہیے۔ ایک درست فارم لازمی فیلڈز کو براؤزر میں ہی جانچتا ہے، لیکن صرف اس جانچ پر انحصار نہیں کرتا۔ سرور فیصلہ کن رہتا ہے۔ ویلیڈیشن کی غلطی پر انٹرفیس کو متاثرہ فیلڈ کو نشان زد کرنا اور درج شدہ مواد برقرار رکھنا چاہیے۔ عمومی کامیابی کا پیغام صرف سرور کے مثبت جواب کے بعد ظاہر ہونا چاہیے۔ رابطہ فارم پاس ورڈز، API کیز، Widget-Tokens، ادائیگی کے ڈیٹا یا مکمل کسٹمر ریکارڈز کے لیے محفوظ چینل نہیں ہے۔ صارفین کو استعمال کا معاملہ، متاثرہ پروڈکٹ اور قابلِ رابطہ کاروباری ای میل ایڈریس دینا چاہیے۔ کسی تکنیکی مسئلے میں ٹیننٹ کا نام، وقت، متاثرہ فنکشن اور قابلِ تکرار مراحل مدد کرتے ہیں، بغیر غیر ضروری ذاتی مواد منتقل کیے۔ ایک حقیقت پسندانہ عمل: وزیٹر نام، ای میل اور پیغام بھرتا ہے، اگر ضروری ہو تو صفحے کے ڈیٹا پروٹیکشن نوٹسز کی تصدیق کرتا ہے اور فارم بھیجتا ہے۔ سرور ڈیٹا کو ویلیڈیٹ کرتا ہے، لیڈ بناتا ہے اور کامیابی کا جواب دیتا ہے۔ غلط ای میل یا بہت مختصر نام کی صورت میں مکمل لیڈ نہیں بنتا۔ یہ اینڈ پوائنٹ کوئی ٹیننٹ نہیں بناتا، کوئی پیکیج بک نہیں کرتا اور منظم پروڈکٹ کنفیگریشن یا مشاورتی عمل کی جگہ نہیں لیتا۔ اسپیم اور خودکار سلسلہ وار درخواستوں سے بچاؤ کے لیے کلائنٹ کو سرور سائیڈ غلطیوں کا احترام کرنا چاہیے اور فوری لامتناہی لوپ شروع نہیں کرنے چاہییں۔ کامیاب جواب پر ان پٹ فیلڈز صرف تب خالی کی جانی چاہییں جب سرور نے قبولیت کی تصدیق کر دی ہو۔ اگر جواب نہ آئے تو صارف مواد محفوظ کر سکتا ہے اور بعد میں کنٹرولڈ طریقے سے دوبارہ بھیج سکتا ہے۔ اندرونی تفویض کے لیے پیغام میں اصل وجہ ہونی چاہیے، مارکیٹنگ کے جملوں یا خفیہ اٹیچمنٹس کے بغیر۔ واضح موضوع اور درست مسئلے کی وضاحت وضاحتی سوالات کو کم کرتی ہے۔ تاہم API خود کوئی یقینی ترجیح مقرر نہیں کرتا اور کسی مقررہ کارروائی کی مدت کی تصدیق نہیں کرتا۔

تصدیقِ شناخت اور تحفظ

تصدیقِ شناخت ضروری نہیں

Idempotent (دہرانے پر یکساں اثر): نہیں

پیرامیٹرز

name(body, string، ضروری)— 2–120 حروف
email(body, string، ضروری)— درست ای میل ایڈریس
message(body, string، ضروری)— 10–3000 حروف
company(body, string)
phone(body, string)
topic(body, string)
consentGiven(body, boolean، ضروری)— true ہونا ضروری ہے (ڈیٹا پروٹیکشن رضامندی)

مثالی Request

{"name":"Max Mustermann","email":"max@example.com","message":"آپ کا پیغام (کم از کم 10 حروف)۔","consentGiven":true}

مثالی Response

{"ok":true,"message":"آپ کی درخواست جمع ہو گئی ہے۔"}

خرابی کے کوڈز

400 VALIDATION_ERROR — لازمی فیلڈ غائب/غلط ہے، یا ڈیٹا پروٹیکشن رضامندی موجود نہیں (Details-Array میں الگ الگ غلطی کے پیغامات)۔

لائیو ٹیسٹ کا ثبوت

کامیابی (200) اور منفی صورت (400، غائب فیلڈز بشمول غائب رضامندی) لائیو تصدیق شدہ۔

← عوامی فارم