API
कोई निजी एंडपॉइंट नहीं है। इंटरफ़ेस के लिए भी नहीं।
अधिकांश उत्पादों में दो API होते हैं: एक प्रलेखित API जो आपको दिया जाता है, और दिलचस्प वाला जिसका उपयोग उनकी अपनी स्क्रीनें करती हैं। दूसरा हमेशा बेहतर होता है, और आपको उसके पास कभी नहीं जाने दिया जाता। यहाँ एक ही है, और इंटरफ़ेस उसका एक क्लाइंट है बाकी सब की तरह — जो हमारे लिए एक बाधा है, और यही कारण है कि आप जो कुछ बनाना चाहते हैं वह संभव है।
इस नियम की वास्तविक कीमत क्या है
इसका मतलब है कि कोई स्क्रीन कभी-कभी API के सही होने की प्रतीक्षा करती है, बजाय एक सुविधाजनक फ़ील्ड के लिए उसके आसपास से जाने के। जिस दिन किसी स्क्रीन को कुछ चाहिए जो सार्वजनिक API नहीं दे सकता, वही दिन API गलत होता है, और समाधान API ही है।
इसका लाभ यह है कि तीन बहुत अलग क्लाइंट की लगभग कोई अतिरिक्त लागत नहीं है। MCP सर्वर एक क्लाइंट है। dash-b टाइल एक क्लाइंट है। आपकी अपनी स्क्रिप्ट एक क्लाइंट है। इनमें से कोई भी द्वितीय श्रेणी का नागरिक नहीं है जो किसी और के लिए डिज़ाइन की गई सतह के आसपास काम कर रहा हो, क्योंकि दूसरी कोई सतह है ही नहीं जिस पर द्वितीय होना हो।
प्रलेखित, और परखा हुआ
OpenAPI /docs पर जनरेट होता है और हर रूट का एक परीक्षण है जो प्रलेखन में दिया उदाहरण है। कोड से अलग से लिखा गया प्रलेखन एक महीने में पिछड़ जाता है; गलत होने पर बिल्ड को विफल कर देने वाला प्रलेखन नहीं।
साइन इन करना
आपका castomo खाता, PKCE के साथ authorization code flow के माध्यम से — वही खाता जो आप dash-b और परिवार के बाकी हिस्सों के लिए उपयोग करते हैं। अपना कोई सर्वर न रखने वाला पेज उस फ़्लो को पूरी तरह चला सकता है; यही उस फ़्लो को डिज़ाइन करने का उद्देश्य था। मशीन-टू-मशीन कार्य के लिए, प्रोजेक्ट-स्कोप्ड API कुंजी।
- 1लोग
/v1/contacts·/lists·/segments·/tags·/imports - 2सामग्री
/v1/creatives, प्रत्येक लक्ष्य के लिए सत्यापन, पूर्वावलोकन और रेंडर के साथ - 3ऑटोमेशन
/v1/funnels·/funnels/:id/versions·/runs·/simulate - 4ब्रॉडकास्ट
/v1/campaigns, ऑडियंस, मटेरियलाइज़, शेड्यूल और भेजने के अलग-अलग चरणों के साथ - 5इवेंट आना
/v1/events— आपकी अपनी एप्लिकेशन के इवेंट, ट्रिगर के रूप में - 6डिलीवरी
/sender-identities·/domains·/apps·/webhooks - 7संख्याएँ
/v1/reports/*, और ट्रैकिंग होस्ट पर/track/*
/docs पर OpenAPIउसी प्रोसेस पर /mcp
परंपराएँ
हर अन्य castomo सेवा के समान वही ढाँचा
जो इससे अधिक मायने रखता है जितना लगता है। यदि आप पहले से इनमें से किसी एक को कॉल करते हैं, तो आप पहले से जानते हैं कि यह वाला कैसे उत्तर देता है, विफल होता है और पेजिनेट करता है।
एक त्रुटि एनवेलप
हर विफलता का एक ही आकार होता है, एक स्थिर कोड और एक संदेश जो किसी व्यक्ति के लिए होता है। कोई रूट अपनी असंतुष्टि का अपना तरीका नहीं बनाता।
कर्सर पेजिनेशन
ऑफ़सेट नहीं। एक सूची जो आपके उस पर चलते समय बदलती है, चुपचाप पंक्तियाँ छोड़ती या दोहराती नहीं है, जो ऑफ़सेट पेजिनेशन चुपचाप और लगातार करता है।
इडेम्पोटेंसी कुंजियाँ
हर म्यूटेटिंग रूट पर। कोई अनुरोध दोहराएँ जिसके लैंड होने के बारे में आप निश्चित नहीं हैं और वही उत्तर पाएँ बजाय दूसरे संपर्क, दूसरे अभियान या दूसरी भेजी गई चीज़ के।
प्रोजेक्ट तक सीमित
एक टोकन एक टेनेंट और एक प्रोजेक्ट, दोनों को संबोधित करता है। पंक्ति-स्तरीय सुरक्षा डेटाबेस में ही लागू होती है, कोई क्लॉज़ जोड़ना याद रखने के बजाय।
वेबहुक बाहर
हस्ताक्षरित, बैकऑफ़ के साथ पुनः प्रयासित, और कम से कम एक बार डिलीवर — इसलिए आपका एंडपॉइंट भी इडेम्पोटेंट होना चाहिए। इवेंट वही शब्दावली है जिसका उपयोग रिपोर्ट करती हैं।
मिटाना और निर्यात
किसी संपर्क को API के ज़रिए निर्यात या मिटाया जा सकता है, और मिटाने की क्रिया परिवार के अपने आंतरिक मार्ग से उसकी प्रति रखने वाली हर सहोदर सेवा तक पहुँचती है।
जो कुछ भी इंटरफ़ेस कर सकता है, वही एक POST कर सकता है।
इवेंट ही दिलचस्प हिस्सा हैं
इस पृष्ठ पर बाकी सब वही प्लंबिंग है जिसकी आप अपेक्षा करते हैं। POST /v1/events वह रूट है जो बदल देता है कि यह उत्पाद किस काम के लिए है।
आपका एप्लिकेशन पहले से वे बातें जानता है जो कोई भी मार्केटिंग टूल नहीं देख सकता: किसने ऑनबोर्डिंग पूरी की, किसने किसी सहकर्मी को आमंत्रित किया, किसने किसी सीमा को छुआ, किसने रविवार की दोपहर को अपना डेटा निर्यात किया। इन्हें अपने अपने टोकन के साथ इवेंट के रूप में पोस्ट करें, और हर एक ट्रिगर, शर्त और सेगमेंट बन जाता है।
बाकी सब संपर्क मॉडल से निकलता है। इवेंट जोड़े जाते हैं, कभी संपादित नहीं होते; वही वह लॉग है जिस पर पूरा उत्पाद टिका है। आपके परिभाषित किसी इवेंट पर चालू होने वाला फ़नल कोई इंटीग्रेशन नहीं है — वह वही तंत्र है जिसका उपयोग message_opened करता है, बस उसमें नाम अलग है।
- 1आप इसे पोस्ट करते हैं
POST /v1/events— एक नाम, एक संपर्क, एक पेलोड, एक आइडेंपोटेंसी कुंजी। - 2यह पहुँच जाता हैसंपर्क के लॉग में जोड़ दिया जाता है। इसके अस्तित्व के बारे में किसी और को जानने की ज़रूरत नहीं है।
- 3एक फ़नल शुरू होता हैकोई भी फ़नल जिसकी प्रविष्टि उस इवेंट का नाम लेती है, उसकी प्रविष्टि-स्पेसिफिकेशन के अंतर्गत पात्र किसी भी संपर्क के लिए।
- 4अन्य फ़नल इस पर शाखाएँ निकालते हैं"क्या यह इवेंट पिछले 14 दिनों में हुआ है" एक साधारण सेगमेंट-विधेय है।
- iऔर यह रन समाप्त करता हैउसी इवेंट का नाम लेने वाला एक लक्ष्य-नोड व्यक्ति के काम करते ही अनुक्रम को रोक देता है।
आपकी शब्दावलीआपका टोकन
निर्माण से पहले जानने लायक सीमाएँ
ClickSomo आपके बारे में तीन पहचानकर्ता रखता है — एक टेनेंट, एक प्रोजेक्ट और एक यूज़र, अपारदर्शी आइडी के रूप में — और इसके अलावा कुछ नहीं। कोई पासवर्ड नहीं, कोई प्रोफ़ाइल नहीं, कोई कार्ड नहीं, कोई इनवॉइस नहीं। योजना की सीमाएँ संख्याओं के रूप में आती हैं: कितने संपर्क, कितने भेजे गए संदेश, कितनी जनरेशन। भुगतान की शब्दावली उस रेखा को किसी भी दिशा में पार नहीं करती।
आपके संपर्क आपके हैं। आप डेटा नियंत्रक हैं; हम प्रोसेसर हैं। परिवार का कोई अन्य उत्पाद आपकी संपर्क सूची पढ़ या लिख सके, ऐसा कोई रास्ता नहीं है, और उसके उपयोग के लिए कोई इनजेस्ट लेन नहीं है।
अगर आप इसे गंभीरता से मूल्यांकन कर रहे हैं: इस वेबसाइट का और कुछ पढ़ने से पहले /docs पढ़ें। API ही उत्पाद के काम का ईमानदार विवरण है, और इन पृष्ठों पर हर दावा किसी रूट या नोड-प्रकार से मेल खाता है जो आपको वहाँ मिलेगा। जब स्कीमा बदलता है, तो ये पृष्ठ बदलते हैं।