Almost every SMM panel exposes an API, and almost all of them expose the *same* API. This guide explains the shared format, what integration actually involves, and the failure modes that cost people money when they automate.
Why every panel's API looks identical
The dominant panel software established a convention that the rest of the market copied, so a panel API is typically a single endpoint that accepts POST form parameters, with an `action` field selecting the operation and a `key` field authenticating you. Learn one and you have effectively learned all of them.
The common actions are: fetch the service list, place an order, check order status, check multiple orders at once, request a refill, and read your balance. Responses are JSON. Errors usually arrive as HTTP 200 with an `error` field in the body rather than as an HTTP error status — which is the first thing that trips up a naive integration.
The order lifecycle
1. Pull the service list. Service IDs are panel-specific and change without notice. Never hard-code them; refresh and map by name. 2. Place the order with a service ID, link and quantity. You get back an order ID. 3. Poll for status. Typical states are Pending, In progress, Processing, Completed, Partial and Canceled. 4. Handle Partial. The panel refunds the undelivered remainder to your balance. Your system needs to reconcile this, or your accounting drifts. 5. Request a refill where the service supports it, inside the stated window.
Polling is the part people get wrong. Status endpoints are rate-limited and panels are not shy about blocking noisy integrations. Poll on a backoff — minutes, not seconds — and use the multi-order status call rather than one request per order.
What your integration must handle
| Failure | What to do |
|---|---|
| Insufficient balance | Fail loudly; never silently retry, or you queue orders that never place |
| Invalid service ID | Refresh the service list and re-map by name |
| Rate limiting | Exponential backoff; treat the panel as a shared resource |
| Duplicate submission | Store your own idempotency key against the panel order ID |
| Partial delivery | Reconcile the refund to balance, and decide whether to re-order |
| Silent price change | Re-read the service list before ordering, not once at deploy time |
The last one is the expensive one. Panel prices change without notice, and an integration that cached a rate at deploy time will happily place orders at a price you never agreed to.
Security, briefly
An API key is a bearer credential to a wallet with money in it. Treat it as such: keep it out of source control and client-side code, store it in your environment or a secrets manager, rotate it if it has ever been pasted anywhere shared, and keep the wallet balance low enough that a compromise is survivable.
If you are building something customer-facing on top of a panel, never expose the panel's API directly to your users. Proxy it through your own service so that your key, your margins and your rate limits stay yours.
Should you build on one panel or several?
Single-panel integrations are simpler and fragile: when that panel's supply degrades, everything you built degrades with it. Multi-panel integrations are meaningfully more work — you need a service-mapping layer so "Instagram Followers HQ" resolves to the right ID on each panel — but they let you route around a bad day.
The middle path most people land on: build against one panel, but keep the service mapping in configuration rather than code, so adding a second is a data change rather than a rewrite.
Before you automate anything
Run the 30-minute manual evaluation on the panel first. Automation multiplies whatever the panel does — including its failures. An integration that places 500 orders a day against a panel with a 40% drop rate is an efficient way to lose money.
If you are choosing a panel specifically to build on, filter the listings for API support and compare the ones that publish it.
A realistic integration checklist
Before your integration touches real money, it should handle every line here. Most do not, and the missing lines are where the losses come from.
- Service list refreshed on a schedule, mapped by name, with a diff you can inspect when IDs change.
- Price re-read immediately before ordering, with a ceiling above which you refuse to place the order automatically.
- Idempotency: your own request key stored against the returned panel order ID, so a retry after a timeout cannot double-order.
- Timeout handling that assumes the order may have succeeded. A network timeout is not a failure; it is an unknown. Query before retrying.
- Backoff on every poll, plus a cap on total polls per order.
- Partial reconciliation so refunds to balance are recorded rather than silently absorbed.
- Balance monitoring with an alert before you hit zero, not after.
- A kill switch. One flag that stops all outbound ordering, reachable without a deploy.
The kill switch is the one people add after their first incident. Add it before.
Where multi-panel routing gets hard
Routing across panels sounds like a small abstraction and is not, because the same nominal service is not the same product across two panels. "Instagram Followers HQ" on panel A may be a different tier, quality and drop rate from panel B's identically named service.
That means your mapping layer needs more than a name match. In practice it needs, per service: which panel, which service ID, the observed drop rate from your own testing, the refill terms, and the price you last saw. Once you have that table, routing becomes a decision you can make on evidence — cheapest, most reliable, or fastest — rather than a coin flip.
Panels also fail asymmetrically. One goes down; another degrades quietly, delivering completed statuses for orders that never arrived. Your monitoring should compare panel-reported completion against the real metric on a sample of orders, because a panel's own status field is a claim, not a measurement.
What automation does not fix
Automating a bad supplier gets you more bad orders faster, and automating a good one does not make its supply infinite. The constraints that matter — retention, delivery quality, support responsiveness when something breaks — are all upstream of your code.
The reasonable use of a panel API is removing manual work from a process you have already validated by hand: an agency placing the same orders for many clients, a child panel routing customer orders to a supplier, or a scheduler that runs an order when new content is posted. It is not a way to turn an unreliable panel into a reliable one.