Technical
The SMM panel API v2 standard
Last updated by The PanelCompare editorial team, 5 min read
What is the SMM panel API v2?
It is a single POST endpoint, conventionally at /api/v2, taking an application/x-www-form-urlencoded body and returning JSON. Authentication is a key parameter in the body rather than a header. There is no versioning negotiation, no request signing and no nonce (specification verified against justanotherpanel.com/api, 2026-09-06).
The specification originated with the dominant panel scripts and has been copied so widely that it is now the industry’s de-facto standard. That is the fact behind almost everything else about this market: a panel can be launched in an afternoon by pointing a script at a provider’s API, which is why there are thousands of panels and why differentiation between them is thin.
The key is a long-lived bearer secret
Because the API key travels in the request body with no signing, nonce or timestamp, there is no replay protection and no expiry in the specification. Anyone holding the key can spend your wallet balance and read every link you have ordered against. Rotate after connecting any third-party tool.
What actions does the API expose?
| Action | Parameters | Returns |
|---|---|---|
| services | key, action | Array of catalogue rows: service, name, type, category, rate, min, max, refill, cancel |
| add | key, action, service, link, plus type-specific parameters | The new order id |
| status | key, action, order | charge, start_count, status, remains, currency |
| status (multi) | key, action, orders (comma-separated, max 100) | An object keyed by order id |
| refill | key, action, order — or orders (comma-separated) | A refill id, or an array of order/refill pairs |
| refill_status | key, action, refill — or refills (comma-separated) | The refill status |
| cancel | key, action, orders (comma-separated) | Per-order cancel result |
| balance | key, action | balance and currency |
Source: SMM Panel API v2 specification, verified against justanotherpanel.com/api, 2026-09-06.
Note that there is no separate multi_status action in the canonical specification. Multi-order status is the same status action with a plural orders parameter, capped at 100 ids per request — a detail that trips up most first integrations.
What does a request and response actually look like?
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"
}The rate field is the price per 1,000 in the account currency, returned as a string. Real catalogues run 3,000–8,000 rows, so a services call is a large single response rather than a paginated one.
What are the gotchas that break first integrations?
- Errors return HTTP 200. A failed request comes back as 200 with a body like an error object, so response codes carry no information and every client must parse the body to detect failure.
- Numbers arrive as strings. rate, min, max, charge, start_count and remains are all quoted strings; comparing them numerically without conversion silently misbehaves.
- Multi-status is the plural parameter, not a separate action, and caps at 100 ids.
- Drip-feed quantity is per run. An add call with runs=10 delivers and charges for quantity × 10.
- Service ids are panel-local and mutable. A panel can repoint an id to a different upstream, so stored ids can quietly start meaning something else.
- refill and cancel only work where the catalogue row advertises them, and cancel typically only before delivery starts.
Which parameters does each order type need?
Every add call needs a service and a link. What else it needs is determined by the type field on the catalogue row, and the requirements are not guessable — this table is the whole of it.
| Order type | Additional parameters |
|---|---|
| Default / Drip-feed | quantity, runs (optional), interval (optional, minutes) |
| Custom Comments | comments (newline-separated list) |
| Custom Comments Package | comments |
| Mentions (user list / hashtag / custom list) | quantity, usernames, hashtags |
| Mentions Hashtag scrape | quantity, hashtag |
| Mentions User Followers scrape | 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 (opt), delay, expiry (opt), old_posts (opt) |
| Invites from Groups | quantity, groups (newline-separated) |
| Package | link only — quantity is fixed |
| Web Traffic | quantity, country, device, type_of_traffic, google_keyword or referring_url |
Source: SMM Panel API v2 specification, verified against justanotherpanel.com/api, 2026-09-06.
How should you build against it?
- 1.Treat every response as untyped. Parse the body first, check for an error key, then coerce numeric strings explicitly.
- 2.Store the panel’s service id alongside your own canonical service, and re-sync the catalogue on a schedule so a repointed id is detected rather than assumed.
- 3.Batch status polling with the plural orders parameter, in chunks of 100, rather than one request per order.
- 4.Handle Partial as a first-class outcome, not an error. It comes with a remains figure and an automatic wallet credit.
- 5.Never log the request body. The API key is in it.
- 6.Rotate keys on a schedule and after every third-party integration change.
What does the API tell you about a panel?
More than the marketing copy does. Fetching /api/v2 with no key returns a valid error response if an API v2-compatible endpoint exists, and a 404 disproves a panel’s claim to have an API — which is a fast, objective check anyone can run.
It is also the only scalable way to collect comparable prices. Most panels gate the catalogue behind registration and publish only marketing copy publicly, so scraping public pages covers a minority of the market. Registering an account and calling the services action returns the entire catalogue as structured JSON in one request, which is how PanelCompare builds its price index.
Quick answers
What is the SMM panel API v2?
A single POST endpoint, conventionally at /api/v2, taking form-encoded parameters and returning JSON, with actions for services, add, status, refill, refill_status, cancel and balance. Almost every panel implements it, so one client works against hundreds.
How do I authenticate to an SMM panel API?
With a key parameter in the request body. There is no header auth, no request signing and no nonce, so the key is a long-lived bearer secret and should be rotated after any third-party integration change.
Why does the API return 200 on errors?
Because the specification does not use HTTP status codes meaningfully. Failures come back as HTTP 200 with an error object in the body, so every client has to parse the response body to detect failure.
How do I check many order statuses at once?
Use the same status action with a plural orders parameter holding up to 100 comma-separated order ids. There is no separate multi_status action in the canonical specification.
Every figure here is attributed and dated
Prices in this market move weekly, so a number without a capture date is decorative. Where this guide quotes a figure it names the source and when it was checked. If one of them is wrong, the correction process on the about page has a two-working-day reply target, and corrections are published with a dated note rather than quietly patched.