SMM panel API तुलना: JAP, CheapSMMPanel और NotPanel
तीन सार्वजनिक SMM APIs की तुलना fields, retries, webhooks और HTTP errors के आधार पर — केवल प्रकाशित contract के अनुसार।
मैंने तीन public API pages खोले: JustAnotherPanel, CheapSMMPanel और NotPanel। तुलना price या catalog size की नहीं, contract की है।
दो pages familiar v2 shape दोहराते हैं। असली फर्क पहले POST के बाद शुरू होता है: field names, retry identity, webhooks और HTTP status line।
किस वजह से आप child panel को नए upstream से जोड़ने से रुकेंगे?
एक विकल्प चुनें. सिर्फ़ इस डिवाइस पर सेव होता है — गढ़ा हुआ सर्वे नहीं.
Scoreboard
तीनों form body और JSON response वाला v2-style POST इस्तेमाल करते हैं। इसके बाद वे interchangeable नहीं रहते।
JAP client को CheapSMM के लिए fields remap करने होंगे। NotPanel पर order बनाने के लिए request_id भी चाहिए; यह अंतर जानबूझकर है।
वही sample order। वही photocopy।
Public pages demo order और list, add, status, balance का basic flow दिखाते हैं। पहली call के लिए ठीक है, लेकिन network failure में क्या होगा यह नहीं बताते।
एक example syntax साबित करता है, लेकिन retry behavior, signed events या failure handling नहीं। Integration को production में भेजने से पहले public contract review करें।
Field names छोटी बात नहीं हैं
| काम | JAP / NotPanel | CheapSMMPanel |
|---|---|---|
| Auth | key | api_token |
| Catalog | action=services | action=packages |
| Service id | service | package |
| Start count | start_count | start_counter |
| Status | In progress / in_progress | Title case in examples |
CheapSMM migration को straightforward कहता है, लेकिन auth, catalog, service और quantity fields बदलने पर हर call site बदलती है। केवल base URL बदलना migration plan नहीं है।
Status strings भी money matter हैं। अगर reconciler completed के अलावा हर status को refundable मान ले, तो नाम का फर्क loss बन सकता है।
जहाँ ज़रूरी है वहाँ NotPanel बेहतर क्यों है
ये कीमत या catalog size के दावे नहीं, बल्कि जाँचे जा सकने वाले contract differences हैं।
Retry-safe orders
add में request_id अनिवार्य है। वही key और body दोबारा भेजने पर original order लौटता है; अलग body reject होती है।
Add contract देखें →Signed status events
Webhook reference raw body पर HMAC-SHA256, timestamp और event बताता है; private या link-local URLs reject होते हैं।
Delivery verify करें →Clear errors
API HTTP 400, 403, 429 और 500 responses document करता है, इसलिए client invalid input, block, limit और service failure अलग कर सकता है।
Errors और responses पढ़ें →Visible limits
Responses X-RateLimit-Limit, Remaining और Reset headers देते हैं, साथ में लागू होने पर tier और block reason भी।
Rate limits देखें →Migration से पहले हर point को public reference के against test किया जा सकता है।
Timeout failure नहीं है
Public sample clients caller-supplied identifier नहीं दिखाते। NotPanel हर add में request_id मांगता है: same key और body original id लौटाते हैं; अलग body reject होती है।
Key को retry loop के बाहर एक बार बनाएं। Timeout unknown result है, यह proof नहीं कि order हुआ ही नहीं।
देखें place-order reference · integration guide.
Timeout unknown है। Safe retry वही है जिसे server पहचान सके।
Polling या signed envelope
JAP और CheapSMM अपने guest API pages पर outbound webhooks document नहीं करते। Implied integration है status poll करना। यह चलता है, लेकिन unchanged orders पर rate limit खर्च करता है।
NotPanel webhook.add, list और remove देता है। Delivery में raw body का HMAC-SHA256, timestamp और named event होता है। Private और link-local URLs reject होते हैं; delivery at-least-once है, इसलिए handler idempotent होना चाहिए।
Recipes हैं webhooks reference · HMAC walkthrough.
Status line, 200-with-error नहीं
Cloned spec HTTP 200 के साथ error object लौटा सकता है। केवल status line पर भरोसा करने वाली retry library इसे success मानेगी।
Limits IP, key और tier layers में होते हैं। Retry loop बनाने से पहले errors और rate-limits references पढ़ें।
Argument यही है: missing half invent किए बिना contract के साथ automation। Traffic move करने से पहले public docs पढ़ें। notpanel.com/developers.
Money leaks के दो अलग guides हैं: timeout retries और webhooks vs polling।
FAQ
क्या JustAnotherPanel का reseller API है?
हाँ। Public v2 page services, add, status, refill, cancel और balance के लिए key और action दिखाती है। Webhooks, idempotency, HTTP error catalog और rate-limit headers document नहीं हैं।
JAP API और NotPanel API में क्या फर्क है?
Basic v2 shape similar है, लेकिन NotPanel request_id मांगता है, signed webhooks document करता है, explicit error statuses लौटाता है और rate-limit headers publish करता है। JAP अधिक specialty fields और cancel document करता है।
क्या CheapSMMPanel वही API इस्तेमाल करता है जो JAP?
नहीं। Guest docs api_token, action=packages, package और start_counter इस्तेमाल करते हैं। JAP client unchanged नहीं चलेगा।
क्या SMM panels webhooks support करते हैं?
कुछ करते हैं, लेकिन कई public v2 pages उनका उल्लेख नहीं करतीं। अगर signing document नहीं है तो inbound POST को untrusted मानें।
NotPanel request_id क्यों मांगता है?
Timeout वाला add unknown result है। Caller key के बिना retry दूसरा charge हो सकता है; same key और body original order लौटाते हैं।
क्या existing JAP client को NotPanel पर point कर सकता हूँ?
Reads में URL और status casing review काफी हो सकता है। add को request_id चाहिए, cancel exposed नहीं है और special fields documented होने चाहिए।