1हर प्लान में क्या शामिल है
विभाजन रेखा सरल है। टेक्स्ट स्पैम-चेकिंग हर प्लान पर उपलब्ध है, इसलिए फ़्री टियर भी Telm के डिटेक्शन को अपने ख़ुद के प्रोडक्ट में एक फ़िल्टर के रूप में इस्तेमाल कर सकता है। पूरा हिस्सा — जोखिम स्तरों के साथ यूज़र स्क्रीनिंग, फ़ैसला जर्नल और एनालिटिक्स, सेटिंग्स और नियम मैनेजमेंट, और webhooks — Pro और Business प्लान का भाग है।
हर प्लान को एक रोज़ाना रिक्वेस्ट कोटा मिलता है, इस तरह आकार दिया गया कि भारी इंटीग्रेशन भारी प्लान पर बैठें:
- **Free** — प्रति दिन 100 API रिक्वेस्ट, सिर्फ़ स्पैम-चेक।
- **Basic** — प्रति दिन 1,000 API रिक्वेस्ट, सिर्फ़ स्पैम-चेक।
- **Pro** — प्रति दिन 10,000 API रिक्वेस्ट, साथ में पूरा API हिस्सा और webhooks।
- **Business** — प्रति दिन 50,000 API रिक्वेस्ट, साथ में पूरा API हिस्सा और webhooks।
- अपनी keys Settings → API & Webhooks के तहत बनाएँ, उन्हें अपने सीक्रेट स्टोर में रखें, हर webhook का सिग्नेचर सत्यापित करें, और वही इंजन जो आपके समूहों की रखवाली करता है आपके अपने स्टैक का हिस्सा बन जाता है।
2हर फ़ैसले का क्वेरी करने योग्य रिकॉर्ड
इंजन जो भी तय करता है वह सब रिकॉर्ड होता है, और `GET journal` वह रिकॉर्ड आपके कोड को सौंप देता है। हर प्रविष्टि एक फ़ैसला है: वर्डिक्ट, उसके पीछे का स्कोर, कौन-से नियम चले, और जो कार्रवाई हुई। चूँकि यह कर्सर-पेजिनेटेड है, आप पूरी हिस्ट्री भरोसे से चल सकते हैं — पेज दर पेज, बिना अंतराल या डुप्लिकेट के — और उसे वहाँ खींच सकते हैं जहाँ आप रिकॉर्ड रखते हैं।
यही जर्नल को एक कम्प्लायंस आर्काइव की रीढ़ बनाता है। जिन टीमों को दिखाना होता है कि किसी सदस्य को क्यों हटाया गया — किसी प्लेटफ़ॉर्म पॉलिसी, किसी क्लाइंट अनुबंध या किसी नियामक के लिए — वे लॉग को एक शेड्यूल पर अपने दीर्घकालिक स्टोर में एक्सपोर्ट करती हैं, जिससे उन्हें हर प्रवर्तन कार्रवाई का एक स्वतंत्र, क्वेरी करने योग्य ब्योरा मिलता है जो Telegram में पीछे स्क्रॉल करने पर निर्भर नहीं करता। यह वही सबूत है जो डैशबोर्ड का ऑडिट लॉग इंसानों को दिखाता है, आपके सिस्टम के लिए उपलब्ध कराया गया।
इसके साथ, एक एनालिटिक्स एंडपॉइंट दिन-दर-दिन की सीरीज़ लौटाता है — समय के साथ मात्राएँ और रुझान — ताकि आप स्क्रीन पर पढ़ने के बजाय अपने ख़ुद के बिज़नेस-इंटेलिजेंस टूल में मॉडरेशन भार को उस बाक़ी सब चीज़ के बगल में चार्ट कर सकें जिसे आप ट्रैक करते हैं। जर्नल और एनालिटिक्स दोनों Pro और Business प्लान का हिस्सा हैं।
3ऐसी डिलीवरी जिस पर आप भरोसा कर सकें
एक पुश मॉडल तभी भरोसेमंद है जब वह उन पलों को संभाल ले जब आपका एंडपॉइंट धीमा हो, रीस्टार्ट हो रहा हो, या थोड़ी देर बंद हो — और Telm का संभालता है। डिलीवरी कम-से-कम-एक-बार है: हर इवेंट में एक स्थिर `id` होता है, और Telm तब तक कोशिश करता रहता है जब तक आपका एंडपॉइंट उसे स्वीकार न कर ले। चूँकि कम-से-कम-एक-बार का मतलब है कि वही इवेंट वाजिब तौर पर दो बार आ सकता है, उस `id` पर डिडुप करें — जिन्हें आपने प्रोसेस कर लिया उन्हें रिकॉर्ड करें और दोहराव को नज़रअंदाज़ करें — और आपकी हैंडलिंग सही बनी रहती है, चाहे कोई डिलीवरी कितनी भी बार रिट्राई हो।
रिट्राई किसी जूझते एंडपॉइंट को हथौड़े मारने के बजाय बढ़ते अंतराल वाले शेड्यूल का पालन करते हैं: तुरंत, फिर एक मिनट, पाँच मिनट, तीस मिनट, दो घंटे, और छह घंटे बाद — कुल छह प्रयास, फैलाए हुए ताकि एक उबरती सेवा को लौटने की जगह मिले। अगर कोई एंडपॉइंट ख़राब बना रहता है — लगातार बीस विफलताएँ और बहत्तर घंटे बिना किसी सफल डिलीवरी के — Telm उसे भेजना अपने-आप बंद कर देता है और आपको Telegram में सूचित करता है, ताकि एक मृत URL विफलताओं के चुपचाप ढेर लगने के बजाय आपके रिसीवर को ठीक करने का एक साफ़ इशारा बन जाए।
किसी नए इंटीग्रेशन को सही करने के लिए, आपको उसे टेस्ट करने हेतु असली इवेंट उकसाने की ज़रूरत नहीं। एक टेस्ट पिंग आपको माँग पर अपने एंडपॉइंट पर एक नमूना डिलीवरी दागने और अपने सिग्नेचर चेक व हैंडलर के काम करने की पुष्टि करने देता है, और एक डिलीवरी हिस्ट्री दिखाती है कि क्या भेजा गया और हर प्रयास कैसा रहा — ताकि आप अटकल के बजाय रिकॉर्ड से एक ग़लत बरताव करते रिसीवर को डिबग कर सकें।
4ऐसी मॉडरेशन जो आपके बाक़ी स्टैक से बात करती है
एक मॉडरेशन बॉट जो पूरी तरह Telegram के भीतर रहता है, उपयोगी है, पर वह एक द्वीप भी है। यह जो फ़ैसले लेता है — हर संदेश जो हटाता है, हर यूज़र जिसे स्क्रीन करता है, हर रेड जिसे वापस मोड़ता है — तब तक एक चैट विंडो में बंद रहते हैं जब तक कोई देखने के लिए Telegram न खोले। एक अकेले समुदाय के लिए यह ठीक है। किसी बड़े परिचालन के हिस्से के रूप में मॉडरेशन चलाने वाली टीम के लिए इसका मतलब है कि जो एक सिस्टम आपके स्थानों का दुरुपयोग करने वालों के बारे में सबसे ज़्यादा जानता है, वही एक सिस्टम है जो आपके चलाए किसी और चीज़ से बात नहीं कर सकता।
पब्लिक REST API और webhooks इस खाई को पाटते हैं। वे Telm को एक स्व-निहित बॉट से एक ऐसे कंपोनेंट में बदल देते हैं जिसे आप अपने पास पहले से मौजूद टूल में जोड़ सकते हैं: आपकी मॉनिटरिंग और ऑन-कॉल व्यवस्था, आपका कम्प्लायंस आर्काइव, आपका अपना प्रोडक्ट, आपके इंटरनल डैशबोर्ड। वही इंजन जो आपके समूहों की रक्षा करता है वह कुछ ऐसा बन जाता है जिसे आपके बाक़ी सिस्टम क्वेरी कर सकते हैं, सुन सकते हैं और चला सकते हैं।
यह गाइड बताती है कि API और webhooks असल में क्या उजागर करते हैं — एंडपॉइंट, इवेंट, सुरक्षा मॉडल — और वे ठोस चीज़ें जो टीमें इनसे बनाती हैं। नीचे सब कुछ आज उपलब्ध एक असली क्षमता है; कोई SDK नहीं जिसका इंतज़ार करना पड़े और यहाँ बताई कोई ऐसी चीज़ नहीं जिसे प्रोडक्ट सिर्फ़ करने की योजना बनाता हो।
5टेक्स्ट और यूज़र की माँग पर स्क्रीनिंग
दो एंडपॉइंट आपको Telm का फ़ैसला माँग पर, अपने ख़ुद के कोड से चलाने देते हैं, बिना किसी संदेश के कभी किसी Telegram समूह से गुज़रे।
`POST /spam/check` टेक्स्ट के एक टुकड़े को ठीक उसी प्रोडक्शन इंजन से भेजता है जो आपके समुदायों की रखवाली करता है — साझा स्पैमर सिग्नल, पैटर्न नियम, क्लासिफ़ायर — और एक वर्डिक्ट लौटाता है। यही वह एक कॉल है जो हर प्लान पर उपलब्ध है, जो इसे आपके अपने प्रोडक्ट के लिए एक स्वाभाविक स्पैम फ़िल्टर बनाती है: कमेंट, साइन-अप बायो, सपोर्ट टिकट या मार्केटप्लेस लिस्टिंग को उसी डिटेक्शन से स्क्रीन करें जो आपके Telegram स्थानों की रक्षा करती है। कठिन, ज़्यादा अस्पष्ट मामलों के लिए एक AI वर्डिक्ट जोड़ने हेतु `include_ai` डालें (Pro और Business पर उपलब्ध), और उन प्लान पर आप प्रति आइटम एक बार कॉल करने के बजाय एक ही रिक्वेस्ट में बीस तक टेक्स्ट बैच कर सकते हैं।
`POST /users/check` किसी संदेश के बजाय एक व्यक्ति को स्क्रीन करता है। यह वैश्विक CAS ब्लॉकलिस्ट, कई समुदायों में मॉडरेशन से बने Telm के अपने डेटासेट को मिलाता है, और एक जोखिम स्तर लौटाता है (Pro और Business पर) ताकि आप तय कर सकें कि कितना घर्षण लगाना है — किसी साफ़ अकाउंट को सीधे गुज़रने दें, किसी जोखिम भरे को समीक्षा के लिए रोकें। इसे अपने ख़ुद के ऑनबोर्डिंग में जोड़ने से आप किसी ज्ञात बुरे कर्ता को अपनी वेबसाइट या ऐप के दरवाज़े पर पकड़ लेते हैं, न कि सिर्फ़ Telegram समूह में जुड़ने के बाद।
दोनों कॉल इन-लाइन जवाब देती हैं: आप टेक्स्ट या यूज़र भेजते हैं, आपको आकलन रिस्पॉन्स में वापस मिल जाता है। पोल करने के लिए कोई क़तार नहीं और इंतज़ार करने के लिए कोई कॉलबैक नहीं — फ़ैसला जवाब के साथ ही आता है।
6जिस पल यह होता है, उसी पल पुश पाना
आर्काइविंग के लिए जर्नल पोल करना ठीक है, पर जब आप किसी चीज़ पर उसी पल *प्रतिक्रिया* करना चाहते हैं जब वह घटती है, तो आप पुश पाना चाहते हैं, पूछना नहीं। Webhooks (Pro और Business पर) ठीक यही करते हैं: आप एक एंडपॉइंट रजिस्टर करते हैं, और Telm उसे उसी पल एक HTTP रिक्वेस्ट भेजता है जब कोई प्रासंगिक इवेंट चलता है। इवेंट उन पलों को कवर करते हैं जो मायने रखते हैं — कंटेंट के लिए `spam.detected` और `message.suspicious`, और सदस्यता के लिए `user.banned`, `user.kicked`, `user.muted`, `user.joined`, और `user.left`।
स्पष्ट उपयोग है एक स्पैम लहर को एक अलर्ट में बदलना। `spam.detected` को अपने मॉनिटरिंग या ऑन-कॉल सिस्टम पर लगाएँ और एक अचानक उछाल उसी जगह ड्यूटी पर मौजूद व्यक्ति के लिए एक पेज बन जाता है जहाँ आपकी बाक़ी घटनाएँ आती हैं — किसी हमले की शुरुआत को भाँपने के लिए किसी को Telegram देखते रहने की ज़रूरत नहीं। वही स्ट्रीम रियल-टाइम डैशबोर्ड को फ़ीड करती है, किसी बाहरी सिस्टम को बैन के साथ सिंक रखती है, या आपकी पसंद का कोई भी वर्कफ़्लो ट्रिगर करती है।
चूँकि ये रिक्वेस्ट बाहरी दुनिया से आपके इंफ़्रास्ट्रक्चर में आती हैं, हर डिलीवरी सिग्नेचर वाली होती है। हर रिक्वेस्ट में `v1=hex(hmac_sha256(secret, "timestamp.body"))` रूप का एक `X-Telm-Signature` हेडर होता है — टाइमस्टैम्प और रॉ बॉडी पर एक HMAC-SHA256, जिसकी कुंजी एक ऐसा सीक्रेट है जिसे सिर्फ़ आप और Telm साझा करते हैं। उस सिग्नेचर को अपनी ओर दोबारा गणना करना साबित करता है कि रिक्वेस्ट सचमुच Telm से आई और रास्ते में फ़र्ज़ी या छेड़छाड़ नहीं की गई; टाइमस्टैम्प आपको बासी रीप्ले अस्वीकार करने देता है। पेलोड पर भरोसा करने से पहले सिग्नेचर सत्यापित करें — यह कुछ लाइन कोड है और एक सुरक्षित webhook रिसीवर का सबसे अहम क़दम है।
7REST API और आपकी keys
API `https://api.telm.com/api/public/v1` पर रहता है। यह एक सादा REST इंटरफ़ेस है — आप इसे सामान्य HTTPS रिक्वेस्ट और JSON के साथ, किसी भी भाषा से कॉल करते हैं, किसी ख़ास क्लाइंट लाइब्रेरी की ज़रूरत नहीं। अगर आपका कोड HTTP रिक्वेस्ट बना सकता है, तो वह Telm से बात कर सकता है।
ऑथेंटिकेशन API key से होता है। आप keys डैशबोर्ड में Settings → API & Webhooks के तहत बनाते हैं, और हर एक आपको बनाते समय ठीक एक बार दिखाई जाती है — उसे उसी वक़्त अपने सीक्रेट स्टोर में कॉपी कर लें, क्योंकि उसे बाद में दोबारा हासिल नहीं किया जा सकता। keys के आगे `tk_live_` लगा होता है ताकि उन्हें logs और config में पहचानना आसान हो। हर key में एक स्कोप होता है — read या write — इसलिए जिस सेवा को सिर्फ़ फ़ैसला लॉग खींचना है वह एक read-only key रख सकती है, जबकि सेटिंग्स बदलने वाले ऑटोमेशन को एक write key मिलती है। हर सिस्टम के लिए एक key बनाएँ, और किसी लीक हुई या रिटायर की गई key को रद्द करना बाक़ियों को कभी नहीं छेड़ता।
उपयोग आपके प्लान से जुड़े एक रोज़ाना रिक्वेस्ट कोटा द्वारा नियंत्रित होता है, इसलिए थ्रूपुट पूर्वानुमेय रहता है और एक बेक़ाबू स्क्रिप्ट सब कुछ ख़त्म नहीं कर सकती। सबसे हल्का चेक — टेक्स्ट स्पैम स्कैनिंग — उस कोटा के भीतर हर प्लान पर उपलब्ध है; ज़्यादा भरा-पूरा हिस्सा, फ़ैसला जर्नल से लेकर सेटिंग्स मैनेजमेंट से webhooks तक, Pro और Business प्लान का भाग है। सटीक आँकड़े अंत में दिए गए हैं।
8कई समूहों को कोड से मैनेज करना
API सिर्फ़ पढ़ता और सुनता ही नहीं — यह लिखता भी है। Pro और Business पर आप किसी समूह की सेटिंग्स को `PATCH` कर सकते हैं और उसके नियमों व व्हाइटलिस्ट पर पूरा create/read/update/delete चला सकते हैं, सब कुछ प्रोग्रामेटिक रूप से। जो कुछ भी आप डैशबोर्ड में हाथ से कॉन्फ़िगर करते, वह आप एक स्क्रिप्ट से कॉन्फ़िगर कर सकते हैं।
यही मॉडरेशन को बड़े पैमाने पर चलाना व्यावहारिक बनाता है। दर्जनों समुदाय मैनेज करने वाली एजेंसी या एक बड़ा ऑपरेटर हर एक को खोलकर वही बदलाव क्लिक करते नहीं फिरना चाहते; वे पॉलिसी एक बार परिभाषित करके हर जगह लागू करना चाहते हैं। API के साथ आप एक नया नियम रोल आउट करते हैं, एक थ्रेशोल्ड समायोजित करते हैं, या पूरे बेड़े में हर व्हाइटलिस्ट में एक पता जोड़ते हैं एक ही स्वचालित पास में, और अपने मानक विकसित होते जाने पर समूहों को क़दम-दर-क़दम बनाए रखते हैं।
यह मॉडरेशन पॉलिसी को आपके अपने सोर्स कंट्रोल में रहने भी देता है। वांछित कॉन्फ़िगरेशन को कोड की तरह रखें, उसे API के ज़रिए लागू करें, और आपके समूह किस तरह संचालित होते हैं उसमें हर बदलाव आपके बाक़ी इंफ़्रास्ट्रक्चर की तरह समीक्षित और वर्शन किया जाता है — यह याद रखने से कोसों दूर कि आपने किस चैट में कौन-सी सेटिंग टॉगल की थी।