तकनीकी
SMM पैनल API v2 का मानक
आख़िरी अपडेट , PanelCompare की संपादकीय टीम द्वारा · 6 मिनट में पढ़ें
SMM पैनल API v2 क्या है?
यह एक अकेला POST एंडपॉइंट है, जो परंपरा से /api/v2 पर होता है, application/x-www-form-urlencoded बॉडी लेता है और JSON लौटाता है। ऑथेंटिकेशन हेडर से नहीं, बॉडी में key पैरामीटर से होता है। न वर्ज़न की कोई बातचीत, न रिक्वेस्ट साइनिंग, न nonce (स्पेसिफ़िकेशन justanotherpanel.com/api से मिलाया गया, 2026-09-06)।
यह स्पेसिफ़िकेशन सबसे प्रचलित पैनल स्क्रिप्टों से शुरू हुआ और इतने बड़े पैमाने पर कॉपी हुआ कि अब व्यवहार में इंडस्ट्री का मानक है। इस बाज़ार की लगभग हर दूसरी बात के पीछे यही तथ्य है: किसी स्क्रिप्ट को प्रोवाइडर के API से जोड़कर एक दोपहर में पैनल शुरू हो सकता है, इसीलिए हज़ारों पैनल हैं और इसीलिए उनके बीच फ़र्क इतना कम है।
API की लंबे समय तक चलने वाला bearer सीक्रेट है
API की रिक्वेस्ट बॉडी में जाती है, बिना साइनिंग, nonce या टाइमस्टैम्प के, इसलिए स्पेसिफ़िकेशन में न रीप्ले से सुरक्षा है, न की की मियाद ख़त्म होती है। जिसके पास भी की है, वह आपका वॉलेट बैलेंस खर्च कर सकता है और हर वह लिंक पढ़ सकता है जिस पर आपने ऑर्डर दिया है। कोई भी थर्ड-पार्टी टूल जोड़ने के बाद की बदल दें।
API कौन-से एक्शन देता है?
| एक्शन | पैरामीटर | क्या लौटाता है |
|---|---|---|
| services | key, action | कैटलॉग की पंक्तियों का array: service, name, type, category, rate, min, max, refill, cancel |
| add | key, action, service, link, और टाइप के हिसाब से पैरामीटर | नए ऑर्डर की id |
| status | key, action, order | charge, start_count, status, remains, currency |
| status (कई ऑर्डर) | key, action, orders (कॉमा से अलग, अधिकतम 100) | ऑर्डर id के हिसाब से keyed object |
| refill | key, action, order (या orders, कॉमा से अलग) | रिफिल id, या order/refill जोड़ियों का array |
| refill_status | key, action, refill (या refills, कॉमा से अलग) | रिफिल का स्टेटस |
| cancel | key, action, orders (कॉमा से अलग) | हर ऑर्डर के कैंसल का नतीजा |
| balance | key, action | balance और currency |
स्रोत: SMM Panel API v2 स्पेसिफ़िकेशन, justanotherpanel.com/api से मिलाया गया, 2026-09-06।
ध्यान दें कि मूल स्पेसिफ़िकेशन में अलग से कोई multi_status एक्शन नहीं है। कई ऑर्डरों का स्टेटस उसी status एक्शन से मिलता है, बस बहुवचन orders पैरामीटर के साथ, और एक रिक्वेस्ट में अधिकतम 100 id — यही बारीकी ज़्यादातर पहले इंटीग्रेशन को गिरा देती है।
रिक्वेस्ट और जवाब असल में कैसे दिखते हैं?
POST /api/v2
Content-Type: application/x-www-form-urlencoded
key=YOUR_KEY&action=services
// 200 OK
[
{
"service": 1,
"name": "Followers",
"type": "Default",
"category": "First Category",
"rate": "0.90",
"min": "50",
"max": "10000",
"refill": true,
"cancel": true
}
]POST /api/v2
key=YOUR_KEY&action=add&service=1&link=https://example.com/p&quantity=1000
// 200 OK
{ "order": 23501 }
POST /api/v2
key=YOUR_KEY&action=status&order=23501
// 200 OK
{
"charge": "0.27819",
"start_count": "3572",
"status": "Partial",
"remains": "157",
"currency": "USD"
}rate फ़ील्ड अकाउंट की करेंसी में प्रति 1,000 की कीमत है, जो string के रूप में आती है। असली कैटलॉग में 3,000–8,000 पंक्तियाँ होती हैं, इसलिए services कॉल पन्नों में बँटा जवाब नहीं, एक बड़ा अकेला जवाब होता है।
कौन-से पेच पहले इंटीग्रेशन को तोड़ देते हैं?
- एरर पर भी आम तौर पर HTTP 200 आता है। ज़्यादातर पैनलों पर फ़ेल हुई रिक्वेस्ट 200 के साथ लौटती है और बॉडी में error object होता है, और कुछ पैनल गलत की पर 401 और वैसी ही JSON बॉडी लौटाते हैं, इसलिए स्टेटस कोड पर भरोसा नहीं किया जा सकता और हर क्लाइंट को गड़बड़ी पकड़ने के लिए बॉडी पार्स करनी पड़ती है।
- संख्याएँ string के रूप में आती हैं। rate, min, max, charge, start_count और remains सब quoted string हैं; बिना बदले इनकी संख्या की तरह तुलना करने पर चुपचाप गलत नतीजे आते हैं।
- कई ऑर्डरों का स्टेटस अलग एक्शन नहीं, बहुवचन पैरामीटर है, और इसकी सीमा 100 id है।
- ड्रिप-फ़ीड की मात्रा हर रन की होती है। runs=10 वाली add कॉल quantity × 10 डिलीवर करती है और उसी का पैसा काटती है।
- सर्विस id हर पैनल की अपनी होती हैं और बदल सकती हैं। पैनल किसी id को दूसरे अपस्ट्रीम की ओर मोड़ सकता है, इसलिए सेव की गई id चुपचाप किसी और चीज़ का मतलब देने लग सकती हैं।
- refill और cancel वहीं काम करते हैं जहाँ कैटलॉग की पंक्ति इन्हें दिखाती है, और cancel आम तौर पर सिर्फ़ डिलीवरी शुरू होने से पहले।
हर ऑर्डर टाइप को कौन-से पैरामीटर चाहिए?
हर add कॉल को service और link चाहिए। इसके अलावा क्या चाहिए, यह कैटलॉग की पंक्ति का type फ़ील्ड तय करता है, और इन ज़रूरतों का अंदाज़ा नहीं लगाया जा सकता। पूरी जानकारी यही टेबल है।
| ऑर्डर टाइप | अतिरिक्त पैरामीटर |
|---|---|
| Default / Drip-feed | quantity, runs (वैकल्पिक), interval (वैकल्पिक, मिनटों में) |
| Custom Comments | comments (हर कमेंट नई लाइन पर) |
| Custom Comments Package | comments |
| Mentions (यूज़र लिस्ट / हैशटैग / कस्टम लिस्ट) | quantity, usernames, hashtags |
| Mentions Hashtag | quantity, hashtag (मेंशन किए जाने वाले अकाउंट हैशटैग से स्क्रेप किए जाते हैं) |
| Mentions User Followers | quantity, username (मेंशन किए जाने वाले अकाउंट उस यूज़र के फॉलोअर्स से स्क्रेप किए जाते हैं) |
| Mentions Media Likers | quantity, media (URL) |
| Comment Likes | quantity, username |
| Comment Replies | username, comments |
| Poll | quantity, answer_number |
| Subscriptions | username, min, max, posts (वैकल्पिक), delay, expiry (वैकल्पिक), old_posts (वैकल्पिक) |
| Invites from Groups | quantity, groups (हर ग्रुप नई लाइन पर) |
| Package | सिर्फ़ link; मात्रा तय है |
| Web Traffic | quantity, country, device, type_of_traffic, google_keyword या referring_url |
स्रोत: SMM Panel API v2 स्पेसिफ़िकेशन, justanotherpanel.com/api से मिलाया गया, 2026-09-06।
इस पर इंटीग्रेशन कैसे बनाना चाहिए?
- 1.हर जवाब को बिना टाइप वाला मानें। पहले बॉडी पार्स करें, error की जाँचें, फिर संख्या वाली string को साफ़ तौर पर संख्या में बदलें।
- 2.पैनल की सर्विस id अपनी मानक सर्विस के साथ सेव करें, और तय समय पर कैटलॉग दोबारा सिंक करें, ताकि मोड़ी गई id पकड़ी जाए, मान न ली जाए।
- 3.स्टेटस की पोलिंग हर ऑर्डर पर एक रिक्वेस्ट से नहीं, बहुवचन orders पैरामीटर से 100-100 के बैच में करें।
- 4.पार्शियल को एरर नहीं, बराबर का एक नतीजा मानकर संभालें। इसके साथ remains का आँकड़ा और वॉलेट में अपने-आप क्रेडिट आता है।
- 5.रिक्वेस्ट बॉडी कभी लॉग न करें। API की उसी में होती है।
- 6.की तय समय पर बदलें, और किसी भी थर्ड-पार्टी इंटीग्रेशन में बदलाव के बाद भी।
API किसी पैनल के बारे में क्या बताता है?
मार्केटिंग कॉपी से ज़्यादा। अगर API v2 से मेल खाने वाला एंडपॉइंट मौजूद है, तो /api/v2 को बिना की के खोलने पर सही बनावट वाला एरर जवाब आता है, और 404 आए तो पैनल का API होने का दावा झूठा साबित होता है। यह तेज़, वस्तुनिष्ठ जाँच है जो कोई भी कर सकता है।
तुलना के लायक कीमतें बड़े पैमाने पर इकट्ठा करने का भी यही एकमात्र तरीका है। ज़्यादातर पैनल कैटलॉग को रजिस्ट्रेशन के पीछे रखते हैं और सार्वजनिक रूप से सिर्फ़ मार्केटिंग कॉपी दिखाते हैं, इसलिए सार्वजनिक पेज स्क्रेप करने से बाज़ार का छोटा हिस्सा ही कवर होता है। अकाउंट रजिस्टर करके services एक्शन कॉल करने पर पूरा कैटलॉग एक रिक्वेस्ट में स्ट्रक्चर्ड JSON के रूप में आ जाता है, और PanelCompare अपना प्राइस इंडेक्स इसी तरह बनाता है।
फटाफट जवाब
SMM पैनल API v2 क्या है?
एक अकेला POST एंडपॉइंट, जो परंपरा से /api/v2 पर होता है, form-encoded पैरामीटर लेता है और JSON लौटाता है, और जिसमें services, add, status, refill, refill_status, cancel और balance के एक्शन हैं। लगभग हर पैनल इसे लागू करता है, इसलिए एक क्लाइंट सैकड़ों पैनलों पर चलता है।
SMM पैनल API में ऑथेंटिकेशन कैसे करें?
रिक्वेस्ट बॉडी में key पैरामीटर से। न हेडर से ऑथेंटिकेशन है, न रिक्वेस्ट साइनिंग, न nonce, इसलिए की लंबे समय तक चलने वाला bearer सीक्रेट है और किसी भी थर्ड-पार्टी इंटीग्रेशन में बदलाव के बाद इसे बदल देना चाहिए।
एरर होने पर भी API 200 क्यों लौटाता है?
क्योंकि स्पेसिफ़िकेशन HTTP स्टेटस कोड का कोई सार्थक इस्तेमाल नहीं करता। गड़बड़ी आम तौर पर HTTP 200 के साथ लौटती है और बॉडी में error object होता है, और कुछ पैनल गलत की पर वैसी ही बॉडी के साथ 401 देते हैं, इसलिए हर क्लाइंट को गड़बड़ी पकड़ने के लिए जवाब की बॉडी पार्स करनी पड़ती है।
एक साथ कई ऑर्डरों का स्टेटस कैसे देखें?
उसी status एक्शन को बहुवचन orders पैरामीटर के साथ इस्तेमाल करें, जिसमें कॉमा से अलग की गई 100 तक ऑर्डर id हों। मूल स्पेसिफ़िकेशन में अलग से कोई multi_status एक्शन नहीं है।
यहाँ का हर आँकड़ा स्रोत और तारीख़ के साथ है
इस बाज़ार में कीमतें हर हफ़्ते बदलती हैं, इसलिए जिस संख्या के साथ उसे लेने की तारीख़ न हो, वह सिर्फ़ सजावट है। यह गाइड जहाँ भी कोई आँकड़ा देती है, वहाँ उसका स्रोत और जाँच का समय बताती है। अगर इनमें से कोई ग़लत है, तो हमारे बारे में पेज पर दी गई सुधार की प्रक्रिया में दो कामकाजी दिनों में जवाब देने का लक्ष्य है, और सुधार चुपचाप नहीं किए जाते, बल्कि तारीख़ वाले नोट के साथ प्रकाशित किए जाते हैं।