Compare an SMM panel API by the workflow you need to run: discover a suitable service, place one order, recover from a timeout, and reconcile the result. Matching an endpoint version or a few field names is only the beginning.
NotPanel's comparison of the public JustAnotherPanel, CheapSMMPanel and NotPanel references, checked 2026-09-09; the NotPanel entries reflect its October 2026 API update. This is a documentation review, not a live delivery benchmark or an authenticated test of competitor accounts. A feature absent from a checked guest page may be available elsewhere; ask the provider before treating it as unavailable.
JustAnotherPanel · CheapSMMPanel · NotPanel
What the public references document
The familiar key + action shape is useful for existing reseller clients. Before changing the base URL, load the destination catalog, map its service IDs, check required fields and prices, and confirm how your client reads statuses. Credentials, service IDs and account balances do not transfer between panels. On NotPanel, any order can be canceled for a full refund in its first 15 seconds; after that, a cancel request is possible on services that support it, and the undelivered part is refunded automatically when the cancel is confirmed.
Map a request before moving an integration
Auth JAP / NotPanel: key CheapSMMPanel: api_token
Catalog JAP / NotPanel: action=services CheapSMMPanel: action=packages
Service id JAP / NotPanel: service CheapSMMPanel: package
Four field names to check
| Job | JAP / NotPanel | CheapSMMPanel |
|---|---|---|
| Auth | key | api_token |
| Catalog | action=services | action=packages |
| Service id | service | package |
| Start count | start_count | start_counter |
A field mapping belongs in one adapter, with a saved example for each request and response your application uses. Both checked competitor pages show title-case status examples. NotPanel returns a display status and a stable status_key; use the documented machine field when building status rules. An unfamiliar status is a reason to reconcile, not evidence that money is refundable.
Names are display text; IDs are the contract
Use numeric service IDs to place orders and names to display choices. NotPanel's services action supports familiar clients and also lists each service's order fields, drip-feed limits and availability; catalog adds discovery options such as pagination and search. An optional language can localize display names. canonical_name retains the English name and name_language identifies the language actually returned, including en when a translation falls back to English.
A timeout is not a failure
Keep the original request_id after a timeout.
Retry with the same key and unchanged order details.
Save the original order ID that the retry returns.
2026-09-09 — request_id and idempotency_key are optional. Without either, the same account and exact payload receive 60-second duplicate protection; this also means an intentional identical order inside that window returns the first order. Wait 60 seconds or send a unique request_id to place an intentional duplicate immediately. Explicit keys remain the strongest retry contract and request_id wins when both aliases are sent.
Generate the key once, outside the retry loop. A timeout is an unknown outcome, not proof that the order never happened.
Read the place-order reference · integration guide.
Use events and status together
Receive a signed order notification.
Verify its signature and timestamp; handle repeated event IDs.
Confirm important order state with a status request.
The JAP and CheapSMM guest pages checked on 2026-09-09 document order-status requests. Outbound webhooks were not documented on those pages; page-level absence does not establish that a feature is unavailable elsewhere. Ask about any account-specific contract your application needs.
NotPanel documents signed webhooks with retries; each delivery carries one signed event with its id, type, sequence and data. Verify X-Webhook-Signature against the original request body and X-Webhook-Timestamp, and use X-Webhook-Delivery-Id for delivery tracking. Process each event ID once, reject events outside your chosen replay window, and reconcile important order state with status. A notification is useful evidence to check; it is not a substitute for an order record.
The recipes are the webhooks reference · HMAC walkthrough.
Read the response before deciding to retry
Read both the HTTP status and the JSON body. They answer different questions: whether a request was accepted, and what happened to the requested operation. The public examples below are NotPanel responses; this review does not establish the HTTP behavior of competitor accounts.
NotPanel documents X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. API keys on the same account share its request limit. Read the errors and rate-limits references before deciding what to retry, when to wait, or when to ask an operator to review the request.
NotPanel features you can verify
These are links to specific NotPanel contracts, so you can check the behavior your application depends on.
- Keep a retry identity: Identical same-account legacy adds have automatic 60-second duplicate protection. Optional request_id or idempotency_key identifies an exact retry; request_id takes precedence if both are provided.
- Verify notifications: The webhook reference defines the exact signed message (one event per delivery), headers and supported events. Verify the signature on the original body, handle repeats and keep status reconciliation.
- Distinguish errors: Every error carries a fixed error_code, an HTTP status and a retryable flag, so you can separate invalid input, access problems, rate limits and retryable errors.
- Respect shared limits: Rate-limit response headers explain the effective account window; changing API keys does not create a separate account allowance.
Check the relevant reference again when changing a client: a comparison article is a guide to evaluation, not a version-pinned API specification.
Choose the contract that covers the work your application actually does. A stable existing integration can remain a good choice. Add NotPanel when its documented retry identity, discovery or reconciliation features solve a specific gap, and validate that gap before moving traffic.
FAQ
Does JustAnotherPanel have a reseller API?
Yes. Its guest reference checked on 2026-09-09 documents key + action requests for services, add, status, refill, refill_status, cancel and balance. Idempotency, signed webhooks and rate-limit response headers were not documented on that checked page; this is not proof they are unavailable elsewhere.
Does CheapSMMPanel use the same API as JustAnotherPanel?
The two checked references share add, status and balance action names, but differ on authentication, catalog selection and the service identifier sent with an order. CheapSMMPanel documents api_token, packages, package and start_counter. Map the complete request and response; do not assume a shared v2 label makes clients interchangeable.
Idempotency built in?
Identical same-account legacy adds have automatic 60-second duplicate protection. Optional request_id or idempotency_key identifies an exact retry; request_id takes precedence if both are provided.
Can I point an existing JAP client at NotPanel?
The familiar key + action shape is useful for existing reseller clients. Before changing the base URL, load the destination catalog, map its service IDs, check required fields and prices, and confirm how your client reads statuses. Credentials, service IDs and account balances do not transfer between panels. On NotPanel, any order can be canceled for a full refund in its first 15 seconds; after that, a cancel request is possible on services that support it, and the undelivered part is refunded automatically when the cancel is confirmed.
