Almost every SMM panel in existence exposes the same API. Not similar — the same, down to the parameter names, because they nearly all descend from the same original script.
Knowing its shape is what turns "integrating a panel" into a configuration step.
The four actions
One endpoint, usually `/api/v2`, taking POST requests with a `key` and an `action`:
- **services** — the full catalogue: id, name, rate per thousand, minimum and maximum quantity
- **add** — place an order: service id, link, quantity. Returns an order id.
- **status** — where an order stands: pending, in progress, completed, partial, canceled. Usually with start count and remaining.
- **balance** — what is left in your account
There are extras — refill, cancel, multi-status — and support for those varies. The four above are effectively universal.
Where the money is made
The rate a panel returns is your cost, not your price.
Your margin is whatever you add on top, and the decision is per service rather than global: competitive services need thin margins, unusual ones carry more. A flat percentage across a catalogue of a thousand services leaves money on the table at one end and prices you out at the other.
This is also why importing a catalogue wholesale and selling it untouched rarely works. The catalogue is the supplier's, the prices have to be yours.
What breaks in practice
Three things, consistently:
- **Balance runs out.** Orders start failing while everything looks healthy from the outside. Watch the balance, not just the orders.
- **Service ids change.** A panel reorganises its catalogue and the id you saved now points at something else, or nothing. Re-sync rather than trusting a stored id forever.
- **Status stops moving.** An order sits "in progress" for days. You need a definition of stuck and something that surfaces it, or your customer finds it before you do.
More than one panel
Most shops end up with several — one for cheap volume, one that is reliable for the services that matter, one that carries something niche.
The thing to get right is that a service remembers which panel it came from. When an order is placed, it has to go back to that panel, with that panel's service id and that panel's key. Mixing them up sends an order into the void with no error to explain it.
Building on top
If you are writing this yourself, the shape above is all you need for a first version.
If you are using a platform, the useful question is whether it exposes the same API outward — so your own customers can buy from you programmatically, the same way you buy from your suppliers. A reseller who can sell to other resellers has a different business from one who cannot.