notpanel
सेवाएंमूल्य निर्धारणFAQगिवअवेAPI
notpanel

हर प्लेटफॉर्म के लिए फॉलोअर्स, लाइक और व्यूज़।

कैटलॉग में हमारी सीधे संचालित सेवाएं और जांचे हुए साझेदारों की क्षमता दोनों शामिल हैं। उपलब्धता, समय, refill और drip-feed हर सेवा पर दिखते हैं; रूटिंग और साझेदारों की पहचान गोपनीय रहती है।

प्रोडक्ट

  • सेवाएं
  • मूल्य निर्धारण
  • मूल्य सूचकांक
  • एफिलिएट प्रोग्राम

संसाधन

  • API
  • ब्लॉग
  • FAQ
  • स्थिति

कंपनी

  • हमारे बारे में
  • NotPanel क्यों
  • संपर्क करें

कानूनी

  • सेवा की शर्तें
  • गोपनीयता नीति
  • रिफंड नीति

भाषाएँ

  • English
  • Español
  • Português
  • Русский
  • Türkçe
  • العربية
  • हिन्दी
  • Bahasa Indonesia
  • Français
  • 中文

© 2026 NotPanel. सर्वाधिकार सुरक्षित।

support@notpanel.com
notpanel
API डॉक्युमेंटेशन
+
API डॉक्युमेंटेशन

परिचय

  • अवलोकन
  • शुरू करना
  • प्रमाणीकरण
  • रेट लिमिट
  • एरर

कैटलॉग

  • सर्विसेज़ की सूची
  • Advanced catalog
  • सेवा प्रकार

ऑर्डर

  • ऑर्डर प्लेस करें
  • ऑर्डर स्टेटस
  • Refund quote
  • रिफिल
  • रद्द करें

अकाउंट

  • Account status
  • बैलेंस

Webhooks

  • Webhooks मैनेज करें

रेफ़रेंस

  • चेंजलॉग
  • SDK और लाइब्रेरी

मदद चाहिए?

support@notpanel.com →

रेट लिमिट

सभी कुंजियाँ एक साझा, rolling 60-second account window इस्तेमाल करती हैं। Lifetime retained successful spend account tier तय करता है; IP और action-specific सुरक्षा पहले या अलग से request रोक सकती है। कोई hourly या per-key tier quota नहीं है।

Rate-limit layers

प्रति-IP

20,000 requests / मिनट / IP address

की वैलिडेशन से पहले लागू किया जाता है ताकि ब्रूट-फ़ोर्स की enumeration सीमित रहे। एक ही IP के पीछे की सभी की में शेयर किया जाता है। डिफ़ॉल्ट ग्लोबली सेट होता है और यूज़र-कॉन्फ़िगरेबल नहीं है।

Shared account window

Rolling 60 seconds में 120–2,400 requests

एक account की सभी active API कुंजियाँ एक ही counter इस्तेमाल करती हैं। Direct RPM override न होने पर lifetime successful-spend ladder limit देता है।

Action-specific

Action पर निर्भर

कुछ sensitive actions में account का छोटा limit भी होता है। उदाहरण के लिए, cancel प्रति account 30 requests per minute स्वीकार करता है; उसका 429 action बताता है।

Lifetime successful-spend ladder

Qualification account के पूरे जीवन में retained successful spend पर आधारित है। Completed और partial delivery retained successful amount जोड़ती है; बाद के refunds इसे घटाते हैं। Effective limit किसी daily job के बिना stored total से update होता है। Earned tier और effective RPM देखने के लिए action=account_status इस्तेमाल करें।

TierMinimum lifetime spendRequests / मिनट
0$0.00000000120
1$10.00000000300
2$50.00000000600
3$100.00000000900
4$500.000000001,200
5$1000.000000001,800
6$2500.000000002,400

रिस्पॉन्स हेडर

हेडरविवरण
X-RateLimit-Limitसामान्य response में account का effective shared requests-per-minute limit। 429 पर rejecting layer द्वारा बताया गया limit।
X-RateLimit-Remainingसामान्य response में shared account window की बची requests। 429 पर rejecting layer द्वारा बताई गई remaining value।
X-RateLimit-Resetबताई window reset होने तक relative seconds; यह Unix timestamp नहीं है।
X-RateLimit-TierLifetime successful spend से मिला tier (0–6)। Custom RPM override इस value को नहीं बदलता।
X-RateLimit-SourceFixed ladder से effective RPM मिलने पर "tier"; admin के direct override से मिलने पर "custom"।
X-RateLimit-DeniedByजब कोई named limiter call रोकता है, 429 response में भेजा जाता है: "ip", "api_requests_per_minute" या "action"।
Retry-AfterRetryable 429 या 503 में Retry-After के बताए seconds से कम नहीं प्रतीक्षा करें। action=add के लिए प्रतीक्षा के बाद वही idempotency key फिर इस्तेमाल करें।

429s को हैंडल करना

  • X-RateLimit-Reset seconds तक रुकें। यह relative delay है, clock time नहीं। Retry से पहले jitter जोड़ें।
  • X-RateLimit-DeniedBy देखें। ip, api_requests_per_minute और action rejecting layer बताते हैं; कुंजी बदलने से shared account, IP या action limit bypass नहीं होती।
  • Polling घटाने के लिए webhooks इस्तेमाल करें। वे retries के साथ best-effort हैं, इसलिए idempotent handlers को महत्वपूर्ण state action=status से reconcile करनी चाहिए।
  • जहाँ supported हो batch इस्तेमाल करें। Status, refill और cancellation documented रूप में अधिकतम 100 IDs के batches स्वीकार करते हैं; हर action के सही parameter names इस्तेमाल करें।