ConnectWiz + API और Webhooks
लाइव इंटीग्रेशनजो API हम बेचते हैं, वही API हम इस्तेमाल करते हैं
पूरा प्लेटफ़ॉर्म एक ही OpenAPI अनुबंध में लिखा है, और हमारा अपना पैनल तथा मोबाइल ऐप उसी से बनते हैं — कोई छिपा एंडपॉइंट नहीं, दस्तावेज़ और हक़ीक़त में कोई फ़ासला नहीं. उसके ऊपर: दायरे वाली Commerce API कुंजियाँ, सुरक्षित webhook ट्रिगर, और ऐसे फ़्लो जो आपके सिस्टम को कॉल करते हैं.
डेवलपर
यह ठीक-ठीक क्या करता है
एक दर्ज अनुबंध
एक ही OpenAPI 3 दस्तावेज़ पूरे प्लेटफ़ॉर्म को लिखता है; हमारे अपने TypeScript क्लाइंट उसी से बनते हैं — दस्तावेज़ हक़ीक़त से भटक नहीं सकते, क्योंकि हक़ीक़त दस्तावेज़ से बनी है.
Commerce API कुंजियाँ
किरायेदार की जारी की हुई कुंजियाँ, साफ़ दायरों के साथ — कैटलॉग पढ़ना, ऑर्डर पढ़ना, ऑर्डर लिखना — आपके अपने स्टोरफ़्रंट या ऐप को उसी ऑर्डर इंजन पर चलाती हैं, और कीमतें हमेशा सर्वर पर तय होती हैं.
इनबाउंड webhook, सुरक्षित
हर फ़्लो webhook ट्रिगर का अपना URL और secret है, कच्ची बॉडी पर HMAC जाँच और रीप्ले से बचाव. कोई पेलोड किसी व्यक्ति का नाम ले सकता है; वह फ़्लो की भीतरी चाल कभी नहीं मोड़ सकता.
फ़्लो से आउटबाउंड
REST क़दम आपके सिस्टम को ठीक उन पलों पर कॉल करता है जो आप कैनवस पर खींचते हैं — ऑर्डर लगा, सहमति मिली, बुकिंग हुई.
तकनीकी पहलू
API डिज़ाइन के रुख़, साफ़ कहे हुए
कीमतें कभी क्लाइंट से नहीं आतीं
एक ऑर्डर अनुरोध बताता है क्या और कितना — नाम और कीमत उसी वक़्त कैटलॉग से, सर्वर पर पढ़ी जाती हैं और लाइन पर स्नैपशॉट बनकर लिखी जाती हैं. छेड़ा हुआ अनुरोध कोई छूट नहीं गढ़ सकता.
कॉल से पहले क्षमताएँ
हर इंटीग्रेशन जगह अपना क्षमता अनुबंध छापती है — क्या वह फ़ोन से मिलान कर सकती है, मेहमान ऑर्डर गिना सकती है, ऑर्डर बना सकती है? — और घोषित "नहीं" के आगे कॉल करने पर वह फ़ौरन एरर देती है, कहीं गहराई में जाकर फ़ेल होने के बजाय.
ऐसी ग़लतियाँ जिनका मतलब होता है
ट्रांसपोर्ट "अनधिकृत" और "सेवा बंद" में फ़र्क़ करता है — तो "दुकान तक पहुँचा नहीं जा सका" कभी "इस ग्राहक ने कभी कुछ ख़रीदा ही नहीं" बनकर नहीं दिखता. नाम वाली ग़लतियाँ ही एक API और अटकलबाज़ी के खेल के बीच का फ़र्क़ हैं.
रीप्ले-रोधी webhook
हर इनबाउंड इवेंट प्रोसेस होने से पहले एक idempotency लेजर में अपनी अलग कुंजी दर्ज कराता है — दोबारा भेजी या रीप्ले की गई डिलीवरी डेटाबेस परत पर ही मर जाती है, आपके ऑटोमेशन में नहीं.
कुंजियाँ हैश, secret दायरे में
API कुंजियाँ हैश बनकर रखी जाती हैं, और दरवाज़े पर सिर्फ़ हैश और दायरे ही पढ़े जा सकते हैं — लीक हुई कोई डेटाबेस पंक्ति न किसी वर्कस्पेस का नाम बताती है, न अपने दायरे से बाहर कुछ खोलती है.
ड्राफ़्ट और पुष्टि, दोनों साफ़ कहे हुए
ऑर्डर बनाने में एक साफ़ confirm पैरामीटर लगता है — सार्वजनिक API डिफ़ॉल्ट रूप से पुष्ट मानता है, पैनल के फ़्लो ड्राफ़्ट रोक सकते हैं — तो "क्या यह असली है?" एक फ़ील्ड है, कोई रिवाज़ नहीं.
सेटअप
यह कैसे जुड़ता है
एक कुंजी जारी करें
पैनल में दायरे वाली Commerce API कुंजी बनाएँ; उतनी ही आसानी से रद्द करें.
एक webhook जोड़ें
webhook ट्रिगर वाला एक फ़्लो बनाएँ; उसके secret से अनुरोध साइन करें.
वापस कॉल करें
REST क़दम वहाँ जोड़ें जहाँ आपके सिस्टम को ख़बर चाहिए.
साथ में बेहतर
यह किनके साथ जुड़ता है
Flows
Webhook ट्रिगर यह शुरू करते हैं: फ़्लो; REST क़दम आपके सिस्टम को ठीक उन पलों पर वापस बुलाते हैं जो आप कैनवस पर खींचते हैं — इनबाउंड और आउटबाउंड ऑटोमेशन एक ही कैनवस साझा करते हैं.
कॉमर्स
यह कैटलॉग और ऑर्डर इंजन जो API के पीछे है, वही है जिसे चैट शॉप और AI इस्तेमाल करते हैं — ऑर्डर का एक सच, चार दरवाज़े.
आपका अपना स्टोरफ़्रंट
टीमें आज Commerce API पर हेडलेस स्टोरफ़्रंट चला रही हैं — यही रास्ता Shopify पेज ईमानदारी से सुझाता है, जब तक नेटिव कनेक्टर बन नहीं जाता.
सुरक्षा और गारंटी
उबाऊ गारंटियाँ
कच्ची बॉडी पर HMAC
Webhook की जाँच कच्ची अनुरोध बॉडी को हर ट्रिगर के अपने secret से साइन करती है और स्थिर समय में मिलान करती है — पार्सिंग सबूत के बाद ही होती है.
पेलोड डेटा हैं, हुक्म कभी नहीं
कोई webhook पेलोड किसी व्यक्ति का हवाला दे सकता है; वह फ़्लो की भीतरी चाल कभी नहीं मोड़ सकता, प्रॉम्प्ट दोबारा नहीं लिख सकता, टूल नहीं चला सकता. डेटा और हुक्म के बीच की सीमा बर्ताव की नहीं, बनावट की है.
हर दरवाज़े पर दर सीमाएँ
सार्वजनिक एंडपॉइंट सामान्य थ्रॉटलिंग पर चलते हैं, और पढ़ने की हदें सर्वर पर ही बँधी हैं — बदतमीज़ी करता क्लाइंट ख़ुद को धीमा करता है, प्लेटफ़ॉर्म को नहीं.
बारीक अक्षर, ईमानदारी से
सीमाएँ, साफ़ लिखी हुई
अभी कोई फ़ायरहोज़ नहीं
सब कुछ सब्सक्राइब कर लेने वाला आम webhook फ़ीड बना ही नहीं है — आउटबाउंड इवेंट आज फ़्लो के क़दमों से होते हैं. यहाँ इसलिए लिखा है कि किसी सेल्स कॉल को उल्टा इशारा न करना पड़े.
बँधी हुई रीड, जान-बूझकर
रीड कर्सर के साथ ज़्यादा से ज़्यादा 100 पंक्तियाँ लौटाती है — यह API कामकाजी इंटीग्रेशन के लिए बना है, थोक एक्सपोर्ट के लिए नहीं. थोक की ज़रूरत एक बातचीत है, कोई झरोखा नहीं.
ईमानदारी से जुड़ा होना, शोर मचाकर जुड़े होने से बेहतर है.
यहाँ हर इंटीग्रेशन को उसी से बताया गया है जो वह असल में करता है — दिशा, मालिकाना हक़ और सीमाएँ, सब शामिल.