LumaKol को उस सॉफ़्टवेयर से जोड़ना जो आप पहले से चला रहे हैं
स्कोप वाली कुंजियों के साथ वर्कस्पेस API, सिंक के लिए कर्सर पेजिनेशन, और कॉलिंग टीम के लिए अहम छह इवेंट के साइन किए गए वेबहुक — साथ ही बिना कोड लिखे इसे Zapier, Make, n8n या Pabbly से कैसे जोड़ें।

कोई भी CRM किसी बिज़नेस का अकेला सिस्टम नहीं होता। एक अकाउंटिंग पैकेज होता है, एक वेबसाइट, एक टिकटिंग टूल, एक वेयरहाउस सिस्टम, 2019 में किसी की बनाई एक स्प्रेडशीट जिस पर आज भी सब निर्भर हैं। जो CRM इनमें से किसी से बात नहीं कर सकता, वह एक और टापू बन जाता है, और टापुओं के बीच का पुल आख़िरकार एक व्यक्ति बनता है जो दिन के अंत में हाथ से पंक्तियाँ कॉपी करता है।
LumaKol में अब एक सार्वजनिक API और आउटगोइंग वेबहुक हैं। दोनों मिलकर दोनों दिशाएँ संभालते हैं: ज़रूरत पड़ने पर आप LumaKol से डेटा माँग सकते हैं, और कुछ होते ही LumaKol आपको बता सकता है। यह पोस्ट इस बारे में है कि ये कैसे बने हैं और किसे कब इस्तेमाल करना है, यह कोई रेफ़रेंस नहीं है — एंडपॉइंट की सूची ऐप के डेवलपर सेक्शन में है, वहीं जहाँ आप कुंजियाँ बनाते हैं।
कुंजियाँ वर्कस्पेस की होती हैं, किसी व्यक्ति की नहीं
यह पहला डिज़ाइन फ़ैसला है, और यही आपकी किसी सोमवार सुबह को बचाता है। LumaKol में जारी की गई API कुंजी वर्कस्पेस की होती है। जब उसे बनाने वाला डेवलपर कंपनी छोड़ देता है और उसका अकाउंट निष्क्रिय हो जाता है, तो उसका बनाया इंटीग्रेशन चलता रहता है: कुंजी अपने लेखक के साथ ख़त्म होने के बजाय वर्कस्पेस मालिक के रूप में काम करने लगती है।
जिसने भी किसी निजी लॉगिन पर बना इंटीग्रेशन चलाया है, वह जानता है कि यह क्यों अहम है। ऐसे इंटीग्रेशन व्यक्ति के जाने के हफ़्तों बाद चुपचाप बंद हो जाते हैं, और गड़बड़ी का पहला संकेत होता है एक रिपोर्ट जिसमें खाली जगह है।
स्कोप
कुंजी इस साफ़ सूची के साथ जारी होती है कि वह क्या कर सकती है, और इसके अलावा कुछ नहीं:
| स्कोप | अनुमति देता है |
|---|---|
| leads:read | लीड, उनकी गतिविधि, स्टेज और डिस्पोज़िशन पढ़ना |
| leads:write | लीड बनाना और अपडेट करना, और नोट जोड़ना |
| calls:read | लॉग की गई कॉल पढ़ना |
| users:read | वर्कस्पेस के सदस्यों को पढ़ना |
| webhooks:manage | वेबहुक सब्सक्रिप्शन बनाना, बदलना और हटाना |
हर इंटीग्रेशन को उसकी अपनी कुंजी दें, सबसे छोटे स्कोप के साथ जिससे काम हो जाए। जो डैशबोर्ड सिर्फ़ चार्ट बनाता है उसे leads:read और calls:read मिलते हैं, और कुंजी ग़लत जगह पहुँच भी जाए तो वह कोई नुक़सान नहीं कर सकता। वेबसाइट फ़ॉर्म हैंडलर को leads:write मिलता है और वह आपकी कॉल हिस्ट्री नहीं पढ़ सकता। कुंजी बनाते समय इस आदत में कुछ नहीं लगता, और जिस दिन कुछ ग़लत होता है उस दिन यह बहुत काम आती है।
स्टोरेज और रद्द करना
कुंजी सिर्फ़ एक बार दिखाई जाती है, जिस पल वह बनती है, और फिर कभी नहीं। LumaKol उसका एकतरफ़ा हैश स्टोर करता है, इसलिए डेटाबेस से कुंजी को कोई भी वापस नहीं पढ़ सकता — हम भी नहीं। अगर वह खो जाए, तो आप नई जारी करते हैं; जानबूझकर, रिकवरी का कोई तरीका नहीं है।
रद्द करना तुरंत होता है। रद्द करें दबाइए और उस कुंजी से किया गया अगला अनुरोध अस्वीकार हो जाता है। न कोई छूट की अवधि, न फैलने में लगने वाली देरी का इंतज़ार — ठीक यही आप चाहते हैं जब कोई लैपटॉप गुम हो जाए या किसी ठेकेदार का काम ख़त्म हो।
कुंजियाँ वर्कस्पेस की स्थिति का भी पालन करती हैं। अगर वर्कस्पेस निलंबित है, तो उसकी कुंजियाँ पूरी तरह काम करना बंद कर देती हैं। अगर वह सिर्फ़-पढ़ने वाला है — ख़त्म हुआ ट्रायल, रद्द किया गया प्लान — तो कुंजियाँ GET अनुरोधों का जवाब देती रहती हैं लेकिन लिखने से मना करती हैं, ठीक वैसे ही जैसे ऐप ख़ुद करता है। कोई इंटीग्रेशन कभी अकाउंट की स्थिति को दरकिनार करने का पिछला दरवाज़ा नहीं बन सकता।
API पर बोझ डाले बिना डेटा पढ़ना
बेस URL यह है: https://api.lumakol.com/api/v1. सूचियाँ पेज नंबर के बजाय कर्सर से पेजिनेट होती हैं, और यह जितना लगता है उससे ज़्यादा अहम है।
सिंक के दौरान पेज नंबर गड़बड़ा जाते हैं। आप पेज एक लाते हैं, कोई एक लीड अपडेट करता है, क्रम बदल जाता है, और पेज दो अब ऐसे रिकॉर्ड के बाद शुरू होता है जिसे आपने कभी देखा ही नहीं। कुछ हज़ार लीड के रात के सिंक में, इसका मतलब है हर रात कुछ रिकॉर्ड छूट जाना और कोई संकेत नहीं कि ऐसा हुआ। कर्सर क्रम में एक तय जगह की ओर इशारा करता है, इसलिए पूरे सेट में पेज-दर-पेज जाने से हर रिकॉर्ड ठीक एक बार मिलता है, भले ही लोग काम कर रहे हों।
सूची वाले जवाब में पंक्तियाँ, अगला कर्सर, और एक फ़्लैग होता है जो बताता है कि और बाकी हैं या नहीं। लूप यह है: अनुरोध, प्रोसेस, कर्सर वापस भेजें, तब तक दोहराएँ जब तक फ़्लैग false न हो। इसे updated-since फ़िल्टर के साथ जोड़ें तो इंक्रीमेंटल सिंक आसान हो जाता है — पिछली सफल रन के बाद से बदली हर चीज़ माँगें, उसमें पेज-दर-पेज जाएँ, टाइमस्टैम्प सहेजें, रुक जाएँ। स्टेज, मालिक, स्रोत, टैग और फ़्री टेक्स्ट के फ़िल्टर हैं, साथ ही आपके अपने बाहरी पहचानकर्ता से खोज, ताकि आप मैपिंग टेबल रखे बिना LumaKol की लीड को अपने सिस्टम के रिकॉर्ड से मिला सकें।
वेबहुक: छह इवेंट जिन पर प्रतिक्रिया देना ठीक है
जो काम तुरंत होना चाहिए, उसके लिए पोलिंग ग़लत औज़ार है। अगर आप चाहते हैं कि लीड किसी ख़ास स्टेज पर पहुँचते ही संदेश जाए, तो हर पंद्रह मिनट पर जाँचने का मतलब है कि संदेश पंद्रह मिनट तक देर से जाता है और हर काम के अनुरोध के लिए आपने छियानवे बेकार अनुरोध किए।
आप अपना कोई HTTPS एंडपॉइंट इन छह इवेंट के किसी भी मेल के लिए सब्सक्राइब कर सकते हैं:
- lead.created — किसी भी स्रोत से कोई लीड वर्कस्पेस में आई।
- lead.updated — लीड का कोई फ़ील्ड बदला।
- lead.stage_changed — लीड पाइपलाइन में आगे बढ़ी। वह इवेंट जिस पर ज़्यादातर बिज़नेस लॉजिक टिका होता है।
- lead.assigned — लीड को नया मालिक मिला।
- call.logged — किसी लीड पर उसके नतीजे के साथ एक कॉल दर्ज हुई।
- follow_up.due — वादा किया गया कॉलबैक देय हो गया।
इवेंट उसी पल कतार में डाल दिए जाते हैं जब घटना होती है, बदलाव के साथ-साथ, इसलिए कार्रवाई और सूचना के बीच किसी रीस्टार्ट से कोई इवेंट खो नहीं सकता। ऐप के नज़रिए से ये भेजकर भूल जाने वाले भी हैं: बंद या धीमा वेबहुक एंडपॉइंट कभी किसी एजेंट के कॉल लॉग करने में देरी या रुकावट नहीं डाल सकता।
यह जाँचना कि डिलीवरी सच में हमारी ओर से आई
आपका एंडपॉइंट सार्वजनिक इंटरनेट पर एक URL है, और जिसे भी वह पता चले वह उस पर पोस्ट कर सकता है। इसलिए हर डिलीवरी में इवेंट और डिलीवरी की पहचान वाले हेडर, एक टाइमस्टैम्प, और एक HMAC-SHA256 सिग्नेचर होता है जो सिर्फ़ आपके साथ साझा किए गए सीक्रेट से टाइमस्टैम्प और बॉडी पर निकाला जाता है।
आपके रिसीवर को पेलोड के किसी भी फ़ील्ड पर भरोसा करने से पहले कच्ची रिक्वेस्ट बॉडी से वह सिग्नेचर दोबारा निकालकर मिलाना चाहिए। व्यवहार में दो बातें अहम हैं: पार्स किए गए JSON का दोबारा सीरियलाइज़ किया हुआ रूप नहीं, कच्ची बॉडी इस्तेमाल करें, क्योंकि एक भी व्हाइटस्पेस का फ़र्क़ सिग्नेचर बदल देता है; और सामान्य बराबरी जाँच के बजाय कॉन्स्टेंट-टाइम तुलना इस्तेमाल करें। सीक्रेट माँगने पर फिर से दिखाया जा सकता है — ताकि आप वेबहुक डिलीट किए बिना रिसीवर दोबारा बना सकें — और ज़रूरत पड़ने पर बदला जा सकता है।
जब आपका एंडपॉइंट बंद हो
असफल डिलीवरी को लगभग आधे दिन तक फैले, शुरुआत में घने शेड्यूल पर दोबारा भेजा जाता है: पहली कोशिशें मिनटों में होती हैं, फिर अंतर बढ़कर घंटों तक हो जाता है। डिप्लॉय के लिए बंद रिसीवर कुछ भी नहीं खोता। जो पूरे दिन बंद रहे, उस पर कोशिश छोड़ दी जाती है, क्योंकि तब तक इवेंट पुराने हो चुके होते हैं और बेहिसाब बढ़ती कतार किसी के काम की नहीं।
हाल की डिलीवरी कोशिशें ऐप में उनकी स्थिति, कोशिशों की गिनती और आपके एंडपॉइंट के दिए जवाब के साथ दिखती हैं, जिससे आम “गड़बड़ उनकी है या हमारी?” वाली बहस एक सूची पर दो मिनट की नज़र बन जाती है। एक टेस्ट डिलीवरी बटन भी है, ताकि उस पर निर्भर होने से पहले आप साबित कर सकें कि रिसीवर काम करता है। वेबहुक URL HTTPS होने चाहिए और किसी सार्वजनिक पते पर रिज़ॉल्व होने चाहिए — निजी या अंदरूनी रेंज की ओर इशारा करने वाला URL सहेजते समय अस्वीकार हो जाता है और हर डिलीवरी से पहले दोबारा जाँचा जाता है।
बिना कोड लिखे इसे जोड़ना
Zapier के लिए एक LumaKol ऐप बना हुआ है और Zapier की समीक्षा का इंतज़ार कर रहा है; जब तक वह उनकी डायरेक्टरी में नहीं आता, और Make, n8n या Pabbly Connect पर, रास्ता मैन्युअल कनेक्शन है। इसके लिए आपको किसी ऐप की ज़रूरत नहीं। इनमें से हर प्लैटफ़ॉर्म एक सामान्य वेबहुक ट्रिगर और एक सामान्य HTTP एक्शन देता है, और दोनों से मिलकर आप वह ज़्यादातर बना सकते हैं जो एक समर्पित ऐप देता।
- ऑटोमेशन प्लैटफ़ॉर्म में, उसके इनकमिंग वेबहुक ट्रिगर से शुरू होने वाला नया सिनेरियो बनाएँ — “Webhooks by Zapier”, Make में “Custom webhook”, n8n में Webhook नोड, Pabbly में “Catch Hook”। जो URL वह देता है, उसे कॉपी करें।
- LumaKol में, उस URL की ओर इशारा करने वाला वेबहुक जोड़ें और उसे उन इवेंट के लिए सब्सक्राइब करें जिनकी आपको परवाह है। एक टेस्ट डिलीवरी भेजें ताकि प्लैटफ़ॉर्म पेलोड का ढाँचा देखकर अपनी फ़ील्ड मैपिंग बना सके।
- अपना एक्शन स्टेप जोड़ें: Google Sheets में एक पंक्ति, Slack में एक संदेश, आपके अकाउंटिंग सिस्टम में एक रिकॉर्ड, किसी मैनेजर को एक ईमेल।
- LumaKol में वापस लिखने के लिए, प्लैटफ़ॉर्म के HTTP request एक्शन से API पर अनुरोध भेजें, ऑथराइज़ेशन हेडर में अपनी कोई कुंजी डालकर — लीड बनाना, स्टेज अपडेट करना या नोट जोड़ना। अगर आपको सिर्फ़ नई लीड भेजनी हैं, तो “वेबसाइट या कोई अन्य ऐप” प्रकार का लीड स्रोत (सेटअप → लीड स्रोत) आपको एक निजी वेबहुक URL देता है जिसे किसी कुंजी की ज़रूरत नहीं और जो उस स्रोत का मालिक, स्टेज और टैग हर लीड पर लागू करता है।
- सिनेरियो चालू करें और उस पर निर्भर होने से पहले जानबूझकर उसे तोड़ें: उसे ग़लत URL की ओर मोड़ें और देखें कि डिलीवरी सूची विफलता दिखाती है, ताकि आपको पता रहे कि असल में समस्या होने पर वह कैसी दिखती है।
Zapier ऐप सूचीबद्ध होने के बाद वहाँ कुछ क्लिक बचाएगा। सामान्य रास्ता आज हर प्लैटफ़ॉर्म पर काम करता है और, क्योंकि यह एक सादा साइन किया हुआ वेबहुक और एक सादा REST कॉल है, बाद में आप चाहे किसी भी ऑटोमेशन प्लैटफ़ॉर्म पर जाएँ, यह काम करता रहता है।
इस विषय पर प्रश्न
क्या बनाने के बाद मैं अपनी API कुंजी फिर से देख सकता हूँ?+
नहीं। सिर्फ़ एकतरफ़ा हैश स्टोर होता है, इसलिए असली कुंजी सिर्फ़ उसी जवाब में होती है जिसने उसे बनाया। अगर वह खो जाए, तो उसे रद्द करें और नई जारी करें।
अगर इंटीग्रेशन बनाने वाला व्यक्ति चला जाए, तो उनका क्या होता है?+
वे काम करते रहते हैं। कुंजियाँ किसी व्यक्ति की नहीं, वर्कस्पेस की होती हैं, और जिस कुंजी का निर्माता अब सक्रिय सदस्य नहीं है वह वर्कस्पेस मालिक के रूप में काम करने लगती है।
असफल वेबहुक डिलीवरी कितने समय तक दोबारा भेजी जाती है?+
लगभग आधे दिन तक, कोशिशें शुरुआत में घनी होती हैं ताकि छोटी-सी रुकावट से आपका कुछ न जाए। उसके बाद डिलीवरी असफल मार्क होती है और वजह डिलीवरी सूची में दिखती है।
अगर मैं पहले से API पोल कर रहा हूँ, तो क्या मुझे वेबहुक चाहिए?+
ज़रूरी नहीं, लेकिन पोलिंग ऐसी देरी जोड़ती है जिसे आप हटा नहीं सकते और उसके ज़्यादातर अनुरोध बेकार जाते हैं। जो कुछ तुरंत होना चाहिए उसके लिए वेबहुक इस्तेमाल करें, और बड़े पैमाने पर पढ़ने, बैकफ़िल और मिलान के लिए API।
संबंधित
- प्रोडक्टफ़ीचरLumaKol क्या-क्या करता है, हर स्क्रीन के साथ
- गाइडAPI और वेबहुक से अपना सॉफ़्टवेयर जोड़ें