How an SMM panel API works, and what the v2 convention is
I co-founded an SMM panel and still help operate it, and a large share of that work happens through APIs rather than on the website. Our panel places orders with upstream panels by calling their APIs, and resellers and agencies place orders with us the same way. This guide describes how that interface usually looks from both ends of the connection. It names no panels and quotes no prices, and where panels differ I say so instead of pretending there is one rule.
Who uses a panel API, and why
The order form is fine for one order at a time. It stops being practical when orders arrive in large numbers, or when someone else is placing them.
The users I deal with most are resellers. A reseller panel does not fill its own orders, so every order a customer places on its site has to be placed again on the panel above it. The panel software holds an API key for each upstream account and forwards those orders automatically.
Agencies are another group, often connecting their own dashboard to a panel so staff never log in to the panel itself. The last group is people writing scripts to place recurring orders or follow a large batch without clicking through the order history. All of them want orders placed without a browser and an answer a machine can read.
What the v2 convention is
The panel APIs I work with tend to share one shape, often marked v2 in the endpoint address. There is a single URL, something like panel.example/api/v2, and every request goes to it, usually as a POST with form fields. Each request carries at least two fields: key, which is your API key, and action, which names the operation. What else the request needs depends on the action.
The panel replies in JSON. There is no separate address for each operation and no login session to keep alive. The key alone identifies the account, which is convenient and is also the main risk, as I come back to below.
The services action
Sending action=services returns the catalogue as a list. Each entry normally includes the service ID, the name, a type, a category, the rate, and the minimum and maximum quantity. The rate is the rate per 1000, in whatever currency the account balance is held in. Many entries also carry true or false flags for whether the service supports refill and whether it supports cancel.
The type field matters more than it looks, because it tells software which fields an order for that service needs. The set of types is not the same on every panel.
Placing an order with add
An add request carries the service ID, the link and the quantity. If the order is accepted, the response contains the new order ID and little else.
POST panel.example/api/v2
key=fakekey123&action=add&service=412&link=POST_LINK&quantity=500
{"order": 88213}Some service types need more. A drip-feed order adds runs, the number of times the order repeats, and interval, the wait between runs, commonly given in minutes. A custom comments order sends a comments field with one comment per line, and the number of lines stands in for the quantity. Services that watch a profile for new posts take their own set of fields, and those vary a lot between panels.
How do you check an order's status through the API?
You send action=status with the order ID. The reply usually holds five values: the status itself (pending, in progress, completed, partial, canceled and similar), the charge, the currency the charge is in, the start count, and remains, which is the part of the quantity not yet delivered.
On a partial order, remains is normally what the refund is calculated from. The start count is what a later refill claim gets measured against, plus the quantity ordered.
The layout also has a multi-order status request, typically in an orders field separated by commas, which returns a result for each. Check the panel's API page for how many IDs one request takes, since that is the limit that decides how a polling loop is written.
A polling loop is the only way to learn that anything changed. The document this layout comes from ships with Perfect Panel, the software the ten panels in the audit set run, and it names no webhook, callback or push of any kind: the ten documents in the audit set were read on one day and none of them offers one. Nothing arrives unless you ask.
Balance, refill and cancel
action=balance returns the funds on the account and their currency. Reseller software checks it before forwarding orders, because an upstream account that has run dry is a quiet way for orders to stall.
action=refill takes an order ID and, if the service offers refill, opens a refill request and returns a refill ID. A separate action, often called refill_status, takes that refill ID and reports whether the refill is pending, running, completed or rejected. What a refill actually covers is a matter of the service's terms rather than the API, which I go through in what refill means on an SMM panel.
action=cancel takes one or more order IDs and asks for them to be cancelled. It only applies to services flagged as cancellable, and asking is not the same as succeeding. An order whose delivery has already moved on can still complete.
How a reseller panel maps services and keeps orders in sync
Inside a reseller panel, each catalogue entry is linked to a provider and to that provider's service ID. The numbers are not shared. Our service 57 might be service 412 upstream, and the panel software stores that pair.
When a customer orders service 57, the software sends add to the provider with service 412, the customer's link and the same quantity, then saves the upstream order ID next to its own.
Keeping status in step is a matter of asking again and again. A scheduled job sends status requests for every open order, compares each answer with what is stored, and updates the local order when something has changed. When the provider reports partial, the panel works out the refund from remains. When it reports completed, the local order closes. Between checks, the status a customer sees is simply the last thing the provider said.
What mistakes cost when you work through an API
The API does what you send it, and mistakes usually cost money rather than produce a warning.
A wrong service ID places a real order on the wrong service. Two services with almost identical names can differ only by number, one with refill and one without, and the charge is taken either way.
Drip-feed quantity is per run. An order of 500 with ten runs is five thousand units, charged as five thousand. Scripts that put the total in the quantity field produce some very expensive surprises.
Stored rates go stale. Panels change rates when their providers do, so a rate your script saved some time ago may no longer apply. Pull the services list again before large orders.
A leaked key is a leaked balance. Anyone holding it can place orders, so keep it out of shared code and public repositories, and regenerate it if you suspect it has been seen.
Keep every order ID that add returns, together with the service ID, link and quantity you sent. Support will ask for the ID, and without your own record you are relying entirely on the panel's.
Field names are a convention, not a standard
Nothing enforces the v2 shape. It is a shared habit rather than a specification: panel software reuses it, and resellers are better served when upstream APIs look alike. Action names, parameter names, status spellings and the extra fields for special service types all drift from one panel to the next. One panel writes Canceled where another writes Cancelled, and some add actions of their own. Read each panel's API page before you connect, and place a small order before you trust an integration with volume.
The limits of this measurement
This guide describes the API layout that panels commonly share, based on the author's work connecting a panel to upstream APIs and supporting the resellers and agencies who connect to it. It does not examine any individual panel's API, check how accurately any panel reports order status, or list every action and service type in use. Parameter names, response fields and supported actions differ between panels and can change without notice, so the API page of the panel you connect to is the authority for any integration, not this description.
Frequently asked questions
What is an SMM panel API used for?
It lets software place and track orders instead of a person using the order form. Reseller panels use it to pass their customers' orders to the panel above them, agencies use it to run client campaigns from their own tools, and individuals use it for recurring orders or large batches. Every request carries an API key, and every answer comes back as JSON.
What does v2 mean in an SMM panel API address?
It names a common layout rather than an official version of any specification. A v2-style API has one endpoint, expects an API key and an action field on every request, and replies in JSON. Two panels that both label their API v2 can still use different parameter names, spell statuses differently and expect different extra fields for special service types.
Is it safe to give my panel API key to a developer?
The key authorises spending from your balance, so whoever holds it can place orders just as you can. If a developer needs it to build an integration, keep it in a configuration file rather than in the code, never post it anywhere public, and regenerate it once the work is finished or as soon as you think it may have been exposed.
Why did my drip-feed API order cost more than I expected?
On a drip-feed order the quantity field is normally the amount delivered in each run, not the total. The panel multiplies that quantity by the number of runs and charges the whole amount at the service rate. Before sending the request, multiply the two numbers yourself and confirm the result is the total you actually meant to buy.
How often should a reseller panel check order status with its provider?
There is no fixed rule. Checking too rarely leaves customers looking at old statuses and delays refunds on partial orders, while checking too often burns through requests and can run into limits a provider may set. The layout includes a status request that takes a list of order IDs, usually in an orders field separated by commas, so batching the open orders makes frequent checks far less costly.
Can I use a service ID from one panel on another panel?
No. Service IDs are local to each panel, so a number that means one service on one panel can point to something unrelated, or to nothing, somewhere else. A reseller gives each imported service its own ID and stores the upstream ID separately. Always take IDs from the services action of the panel you are about to order from.
Does cancelling an order through the API always return my money?
Not always. The cancel action is a request, and it only applies to services the panel marks as cancellable. If delivery has already progressed, the order may continue or complete regardless. When a cancellation does go through, any refund follows that panel's own policy, so check the order's status afterwards to see what the panel actually recorded.