API ही वह चीज़ है जो पैनल को साधारण ऑनलाइन दुकान से अलग करती है। उसी के ज़रिए पैनल बिना किसी इंसान के ऑर्डर लेता है, प्रोवाइडर को आगे भेजता है और स्टेटस वापस लाता है। और वही API आपके पैनल को दूसरों के लिए प्रोवाइडर बना देता है: दूसरे पैनल आपसे अपने आप, चौबीसों घंटे और बीच में किसी Telegram चैट के बिना खरीदने लगते हैं।
क्या कहाँ है, संक्षेप में: यह लेख बताता है कि API कैसे काम करता है और key किसे दें, जबकि तैयार व्यावसायिक जवाब - वह पैनल जिसमें दोनों API शुरू से चलते हैं - API वाला SMM पैनल पेज पर है।
कुंजी दे देना आधा काम है; बाक़ी आधा तब शुरू होता है जब उसी से कोई स्क्रिप्ट दोहरे ऑर्डर और बिना रुके स्टेटस पूछते हुए आती है। तब क्या टूटता है और कौन-सी जाँचें सर्वर पर होनी चाहिए, यह पैनल API के दुरुपयोग वाले लेख में है।
एक ही API के दो सिरे
पैनल मालिक एक साथ दो API के साथ काम करता है, और उन्हें आपस में गड्डमड्ड कर देना असली समस्या है।
- आपके प्रोवाइडर का API - यहाँ ग्राहक आप हैं। पैनल ऑर्डर को शृंखला में नीचे भेजता है, स्टेटस खींचता है और बैलेंस पर नज़र रखता है। लोग जिसे ऑटो-प्रोसेसिंग कहते हैं वह यही है: ग्राहक का ऑर्डर तब नहीं जब आप एडमिन पैनल खोलें, बल्कि कुछ सेकंड में काम में चला जाता है।
- आपका अपना API - यहाँ प्रोवाइडर आप हैं। दूसरे पैनल और सेवाएँ आपसे जुड़ती हैं, आपके मेथड कॉल करती हैं और आपकी सेवाएँ अपनी दुकान पर बेचती हैं। उनके लिए आप बस एक प्रोवाइडर हैं, ठीक वैसे ही जैसा वह जिससे आप खरीदते हैं।
पैसे के लिहाज़ से दूसरा सिरा ज़्यादा दिलचस्प है। API से जुड़ा रीसेलर एक खरीद नहीं, ऑर्डर की धारा लाता है: उसके अपने ग्राहक, अपना ट्रैफ़िक और अपना सपोर्ट होता है, जबकि मात्रा आपके ज़रिए बहती है।
कॉल की पूरी सूची, उनके पैरामीटर और जवाब का ढाँचा अलग संदर्भ लेख में है: SMM पैनल API के मेथड। यह लेख इस बारे में है कि key किसे और क्यों देनी है; वह इस बारे में कि आपके कोड को क्या सहारा देना है।
SMM पैनल का API कैसे बना होता है
इस निच में व्यवहार का एक मानक बन चुका है और लगभग हर पैनल उसे दोहराता है - यह सबके फ़ायदे में है, क्योंकि इंटीग्रेशन एक बार लिखा जाता है और दर्जनों पैनल पर फ़िट बैठता है। वह ऐसा है: एक ही endpoint, POST रिक्वेस्ट, पैरामीटर में access key और काम action पैरामीटर में। जवाब JSON में आता है।
services- सेवाओं की सूची: id, नाम, श्रेणी, प्रति 1000 कीमत, न्यूनतम और अधिकतम मात्रा।add- ऑर्डर बनाना। आपके पैनल में ऑर्डर की id लौटाता है।statusऔरmultistatus- एक ऑर्डर का या एक साथ कई ऑर्डर का स्टेटस।refill- पूरे हो चुके ऑर्डर पर refill का अनुरोध, जहाँ सेवा इसे सपोर्ट करती है।balance- रीसेलर के पास बचा हुआ पैसा।
Key लॉगिन और पासवर्ड दोनों एक साथ है: जिसके पास है वही बैलेंस खर्च करता है। इसलिए वह केवल HTTPS से जाती है, रीसेलर के सर्वर पर रहती है और ज़रा-सा शक होते ही बदल दी जाती है।
ऑर्डर में कौन से फ़ील्ड जाते हैं, यह सेवा के प्रकार पर निर्भर है
इंटीग्रेशन की सबसे आम ग़लती यह मान लेना है कि ऑर्डर हमेशा एक लिंक और मात्रा होता है। ज़्यादातर सेवाओं के लिए यह सही है, पर प्रोवाइडर ऐसी सेवाएँ भी बेचते हैं जिनमें कमेंट की सूची, लेखक का यूज़रनेम, हैशटैग का समूह चाहिए - या मात्रा चाहिए ही नहीं, क्योंकि वह सेवा में ही तय है। ग़लत पैरामीटर भेजिए, प्रोवाइडर ऑर्डर ठुकरा देगा, जबकि आपके ग्राहक का पैसा शायद जा चुका होगा।
इसीलिए सेवा का प्रकार सेवा के साथ ही रहना चाहिए, और ऑर्डर फ़ॉर्म तथा API दस्तावेज़ - दोनों एक ही प्रकार-रजिस्ट्री से बनने चाहिए। तब रीसेलर वह दस्तावेज़ पढ़ता है जिसमें ठीक वही फ़ील्ड लिखे हैं जो आपका पैनल स्वीकार करेगा, और असमर्थित प्रकार की सेवाएँ कैटलॉग में पहुँचती ही नहीं।
स्टेटस पूछना: इंटीग्रेशन कहाँ टूटते हैं
ऑर्डर बन गया - अब उसे किसी अंतिम स्टेटस तक पहुँचना है। इंटीग्रेशन यहाँ, ऑर्डर बनाने से ज़्यादा टूटते हैं।
- बहुत बार पूछना। हर ऑर्डर के लिए हर सेकंड
statusमारना rate limit में फँसने का सबसे तेज़ रास्ता है। समझदार अंतराल सेकंड नहीं, मिनट है। - एक-एक करके पूछना। एक हज़ार सक्रिय ऑर्डर के लिए
multistatusहै: एक हज़ार रिक्वेस्ट की जगह एक। - पूरे हो चुके ऑर्डर पूछना। अंतिम स्टेटस वाला ऑर्डर फिर कभी नहीं बदलता - उसे छोड़ दीजिए।
- त्रुटियाँ निगल जाना। त्रुटि का जवाब भी जवाब है: उसकी जगह शून्य नहीं, लॉग और अलर्ट है।
दोबारा कोशिश (retry) अलग से सोचने लायक है। अगर ऑर्डर बनाने की रिक्वेस्ट चली गई पर जवाब वापस नहीं आया, तो सीधा-सादा लॉजिक उसे दोहरा देता है और डुप्लीकेट ऑर्डर बना देता है। बचाव है भेजने वाली तरफ़ अपना पहचानांक और दोबारा भेजने से पहले जाँच।
अपने पैनल से रीसेलर जोड़ना
तकनीकी रूप से आप बस एक key जारी करते हैं। व्यवहार में पहले तीन बातें तय होती हैं: वे किन कीमतों पर खरीदेंगे, ख़राब ऑर्डर पर क्या होगा और बैलेंस कैसे भरेंगे। चलने वाली व्यवस्था सरल है - रीसेलर पहले से भरे बैलेंस से काम करते हैं, उनकी कीमतें अलग होती हैं (आम तौर पर दुकान की कीमतों से नीचे) और विवाद स्क्रीनशॉट से नहीं, आपके पैनल की ऑर्डर id से सुलझते हैं।
उन्हें तुरंत टेस्ट एक्सेस और थोड़ा शुरुआती बैलेंस दीजिए: डेवलपर इंटीग्रेशन लिखता है और उसे हर मेथड, त्रुटि वाले मामलों समेत, आज़माना पड़ता है। वह चैट में जितने कम सवाल पूछेगा, मात्रा उतनी जल्दी शुरू होगी।
Key देने से पहले यह जाँच लें
- कीमतें और सीमाएँ। रीसेलर आपकी पूरी मूल्य सूची देखता है - पक्का कर लीजिए कि उसमें कोई ऐसी सेवा न रह जाए जो आप घाटे में बेचते हैं।
- न्यूनतम ऑर्डर। API से बीस सेंट के सौ ऑर्डर आप पर डाल देना बहुत आसान है; न्यूनतम राशि आपके सपोर्ट को बचाती है।
- हर रीसेलर के लिए अलग key। एक साझा key न रद्द की जा सकती है, न लॉग में पहचानी जा सकती है।
- रिक्वेस्ट के लॉग। उनके बिना हर विवाद भरोसे की बहस बन जाता है।
निचोड़
API इंजीनियरों के लिए फ़ीचर नहीं, बिक्री का रास्ता है। जुड़ा हुआ एक रीसेलर अक्सर महीने भर के विज्ञापन से ज़्यादा मात्रा लाता है, क्योंकि वह एक ऑर्डर नहीं, अपने ग्राहकों की धारा लाता है। और शुरुआत बिना बजट की जा सकती है: SMMPanelRent में पैनल जो ऑर्डर हमारे अपने कैटलॉग से पूरे करता है, वे प्लान में गिने ही नहीं जाते - पैनल किसी भी मात्रा पर मुफ़्त रहता है - और तीसरे पक्ष के प्रोवाइडर पर महीने के पहले सौ ऑर्डर मुफ़्त हैं। यानी आप अपने API इंटीग्रेशन बना सकते हैं और देख सकते हैं कि वे क्या लाते हैं, जबकि पहला किराया बिल अभी वजूद में ही नहीं आया।
