POST/api/public/contact

Zentor वेबसाइट का सार्वजनिक संपर्क फॉर्म। आंतरिक लीड सिस्टम में एक अनुरोध बनाता है।

`POST /api/public/contact` Zentor वेबसाइट के सार्वजनिक संपर्क फ़ॉर्म को संभालता है और अनुरोध को आंतरिक लीड प्रणाली में सहेजता है। इस एंडपॉइंट के लिए डैशबोर्ड प्रमाणीकरण की आवश्यकता नहीं है और यह आइडेंपोटेंट (idempotent) नहीं है। प्रत्येक सफल सबमिशन एक नया लीड उत्पन्न कर सकता है। इसलिए, फ्रंटएंड को पहले क्लिक के बाद सबमिट बटन को निष्क्रिय कर देना चाहिए और स्वचालित पुनरावृत्ति को ट्रिगर नहीं करना चाहिए। पुष्टि किए गए अनिवार्य फ़ील्ड में `name`, `email` और `message` शामिल हैं। नाम की लंबाई 2 से 120 अक्षरों के बीच होनी चाहिए, ईमेल पते में एक वैध प्रारूप होना चाहिए, और संदेश को सर्वर-साइड सत्यापन नियमों को पूरा करना चाहिए। अतिरिक्त फ़ील्ड केवल तभी भेजे जाने चाहिए जब वे वास्तविक स्कीमा में निर्धारित हों। अज्ञात मानों का उपयोग लीड की आंतरिक संपत्तियों को नियंत्रित करने के लिए नहीं किया जाना चाहिए। एक सही फ़ॉर्म ब्राउज़र में ही अनिवार्य फ़ील्डों की जांच करता है, लेकिन केवल उसी पर निर्भर नहीं रहता। सर्वर निर्णायक भूमिका निभाता है। सत्यापन त्रुटि होने पर, इंटरफ़ेस को प्रभावित फ़ील्ड को चिह्नित करना चाहिए और उपयोगकर्ता द्वारा दर्ज सामग्री को बनाए रखना चाहिए। एक सामान्य सफलता संदेश केवल सकारात्मक सर्वर प्रतिक्रिया के बाद ही दिखाई देना चाहिए। संपर्क फ़ॉर्म पासवर्ड, API कुंजियाँ, विजेट टोकन, भुगतान डेटा या पूर्ण ग्राहक डेटा रिकॉर्ड के लिए एक सुरक्षित चैनल नहीं है। उपयोगकर्ताओं को उपयोग मामले, प्रभावित उत्पाद और एक संपर्क योग्य व्यावसायिक ईमेल पता प्रदान करना चाहिए। तकनीकी समस्याओं में, टेंनेंट नाम, समय, प्रभावित कार्यक्षमता और पुनरुत्पादक चरण बिना अनावश्यक व्यक्तिगत सामग्री स्थानांतरित किए मदद करते हैं। एक यथार्थवादी प्रवाह: आगंतुक नाम, ईमेल और संदेश भरता है, यदि आवश्यक हो तो पृष्ठ की गोपनीयता सूचनाओं की पुष्टि करता है और फ़ॉर्म सबमिट करता है। सर्वर डेटा का सत्यापन करता है, लीड बनाता है और एक सफलता प्रतिक्रिया प्रदान करता है। अमान्य ईमेल या बहुत छोटे नाम के मामले में कोई पूर्ण लीड उत्पन्न नहीं होता। एंडपॉइंट कोई टेंनेंट नहीं बनाता, कोई पैकेज बुक नहीं करता और न ही संरचित उत्पाद विन्यास या परामर्श प्रक्रिया का विकल्प बनता है। स्पैम और स्वचालित श्रृंखला अनुरोधों से बचाव के लिए, क्लाइंट को सर्वर-साइड त्रुटियों का सम्मान करना चाहिए और तुरंत अंतहीन लूप शुरू नहीं करने चाहिए। एक सफल प्रतिक्रिया को केवल तभी इनपुट फ़ील्डों को खाली करना चाहिए जब सर्वर स्वीकृति की पुष्टि कर दे। यदि प्रतिक्रिया नहीं आती है, तो उपयोगकर्ता सामग्री को सुरक्षित कर सकता है और बाद में नियंत्रित रूप से पुनः सबमिट कर सकता है। आंतरिक आवंटन के लिए, संदेश में वास्तविक कारण होना चाहिए, बिना मार्केटिंग जालशब्दों या गोपनीय संलग्नक के। एक स्पष्ट विषय और एक सटीक समस्या विवरण पूछताछ को कम करता है। हालांकि, 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)सत्य होना चाहिए (डेटा सुरक्षा सहमति)

Beispiel-Request

{"name":"मैक्स मुस्टर्मैन","email":"max@example.com","message":"आपका संदेश (कम से कम 10 अक्षर).","consentGiven":true}

Beispiel-Response

{"ok":true,"message":"आपका अनुरोध भेज दिया गया है।"}

Fehlercodes

400 VALIDATION_ERRORअनिवार्य फ़ील्ड अनुपस्थित/अमान्य है, या डेटा सुरक्षा सहमति अनुपस्थित है (व्यक्तिगत त्रुटि संदेशों के साथ विवरण-एरे)।

Live-Test-Nachweis

सफलता (200) और नकारात्मक मामला (400, अनुपस्थित फ़ील्ड्स सहित सहमति की कमी) लाइव सत्यापित किया गया।

सार्वजनिक फॉर्म