notpanel
ServicesPricingFAQGiveawayAPI
notpanel

Followers, likes and views for every platform.

The catalog combines directly operated services with capacity from vetted partners. Current availability, timing, refill, and drip-feed support are shown per service; routing and partner identities remain confidential.

Product

  • Services
  • Pricing
  • Price Index
  • Affiliate Program

Resources

  • API
  • Blog
  • FAQ
  • Status

Company

  • About
  • Why NotPanel
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
  • Refund Policy

Languages

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

© 2026 NotPanel. All rights reserved.

support@notpanel.com
notpanel
API documentation
+
API documentation

Introduction

  • Overview
  • Getting started
  • Authentication
  • Rate limits
  • Errors

Catalog

  • List services
  • Advanced catalog
  • Service types

Orders

  • Place order
  • Order status
  • Refund quote
  • Refill
  • Cancel

Account

  • Account status
  • Balance

Webhooks

  • Manage webhooks

Reference

  • Changelog
  • SDKs & libraries

Need help?

support@notpanel.com →

Rate limits

Requests use one rolling 60-second account window shared by every key. Lifetime retained successful spend earns the account tier; IP and action-specific protections may reject earlier or separately. There is no hourly or per-key tier quota.

Rate-limit layers

Per-IP

20,000 requests / minute / IP address

Applied before key validation so brute-force key enumeration is bounded. Shared across all keys behind the same IP. The default is set globally and is not user-configurable.

Shared account window

120–2,400 requests / rolling 60 seconds

All active API keys on one account consume the same counter. The fixed lifetime-successful-spend ladder supplies the limit unless a direct admin RPM override exists.

Action-specific

Depends on the action

Some sensitive actions add a narrower account rule. For example, cancel accepts 30 requests per minute per account; its 429 reports action.

Lifetime successful-spend ladder

Qualification uses retained successful spend over the account's lifetime. Completed and partial delivery adds the retained successful amount; later refunds reduce it. The effective limit updates from the stored total without a daily upgrade job. Use action=account_status to read the earned tier and effective RPM.

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

Response headers

HeaderDescription
X-RateLimit-LimitOn normal responses, the effective shared account requests-per-minute limit. On a 429, the limit reported by the rejecting layer.
X-RateLimit-RemainingOn normal responses, requests remaining in the shared account window. On a 429, the remaining value reported by the rejecting layer.
X-RateLimit-ResetRelative number of seconds until the reported window resets; it is not a Unix timestamp.
X-RateLimit-TierThe earned lifetime-successful-spend tier (0–6). A custom RPM override does not change this value.
X-RateLimit-Source"tier" when the fixed ladder supplies the effective RPM; "custom" when a direct admin override supplies it.
X-RateLimit-DeniedBySent on 429 responses when a named limiter rejects the call: "ip", "api_requests_per_minute", or "action".
Retry-AfterOn a retryable 429 or 503 with Retry-After, wait at least this many seconds before retrying. For action=add, reuse the same idempotency key after the wait.

Handling 429s

  • Wait for Retry-After when it is present. Otherwise wait for X-RateLimit-Reset seconds. Both values are relative delays, not clock times; add jitter before retrying.
  • Inspect X-RateLimit-DeniedBy. ip, api_requests_per_minute, and action identify the rejecting layer; changing keys does not bypass the shared account, IP, or action limit.
  • Use webhooks to reduce polling. They are best-effort with retries, so idempotent handlers must still reconcile important state with action=status.
  • Batch where supported. Status, refill, and cancellation support documented batches of up to 100 IDs; follow each action's parameter names.