Running your own SMM panel on top of ours with the API v2

If you already run a panel, you do not need an integration project. The API is the standard SMM Panel v2 spec, which is what your software is almost certainly already speaking.

The shape of it

One endpoint, POST, form-encoded. Every request carries your key and an action; everything else depends on the action. Responses are JSON. If your panel software has a "custom API provider" screen with fields for a URL and a key, that is all it needs.

The actions

• services — the full catalogue with your rates, which already include any account discount you have. Cache it; do not fetch it per pageview.
• add — place an order. Takes the service id, link and quantity, plus comments, runs and interval where the service supports them.
• status and multi-status — where an order is, how much remains, what it cost, its start count.
• refill and refill_status — request a top-up on a service that carries cover, and check how it went.
• cancel — pull an order that has not started.
• balance — what is left in your wallet. Poll it on a schedule and alert yourself before it runs out.

Two things that catch people out

1. Business errors come back as HTTP 200 with an error key in the body. Not enough balance, unknown service, quantity out of range — all 200. That is the spec, not a bug. Check the body, not the status code, or your integration will report every rejection as a success.
2. Poll status in batches. Multi-status takes a list of order ids in one request. Asking one at a time for two hundred open orders is two hundred round trips and will hit the rate limit, at which point you get throttled and your customers see stale statuses.

Service ids

The id we publish is the supplier's service number — the same number every other panel reselling this catalogue prints. That is deliberate: a customer moving an order list from another panel finds the same service under the same id, and you do not have to maintain a translation table.

Pricing on top

Your customers never see us. Our rate is your cost; whatever margin you add is yours, and you set it in your own panel. The one thing to watch is that supplier prices move — a service that cost you a fifth of a cent last month may not this month. If your prices are typed in by hand and refreshed rarely, you are either overcharging or selling at a loss, and both get noticed. Re-pull the catalogue on a schedule and re-apply your margin from it.

Keeping the balance topped up

An order placed with an empty wallet is rejected, and if your panel does not surface that clearly, your customer sees a mysterious failure. Poll balance on a cron, alert yourself at a threshold that covers a day of trading, and keep a buffer. This is the most common way a reseller's Saturday goes wrong.

Handling refunds on your side

When an order partials or is cancelled, we refund your wallet automatically. Your panel needs to do the same for your customer, or you keep money for units nobody delivered — and that is the fastest way to lose a reseller's reputation. Read the remaining quantity from the status response and mirror the refund downstream.

Rate limits and good behaviour

The API is rate limited per key. Sensible polling — batched status every few minutes rather than every few seconds for every order — stays comfortably inside it. If you are hitting the limit, the fix is almost always batching rather than a higher limit.

Testing against a real balance

There is no sandbox. Every call you make places a real order and spends real money, which sounds worse than it is: the cheapest services in the catalogue cost a fraction of a taka per hundred units, so a full integration test — place, poll, refill, cancel — costs a few taka in total.

Do that once, deliberately, against a link you own. Watch the order move from pending to processing to complete and confirm your panel mirrors each transition. It is a far better use of an afternoon than reading the spec twice, and it surfaces the one class of bug documentation never does: what your code does when the response takes eight seconds instead of two.

Mapping the catalogue into your own

Pulling 900-odd services straight into a customer-facing panel is a bad first move. Most of them are near-duplicates, several are dead ends, and you cannot answer a question about any of them.

A pattern that works: import everything into a staging table, mark the twenty or thirty you have actually tested as visible, and show only those. Keep the rest importable so you can promote one when a customer asks for it. Your panel then has a catalogue you can stand behind, and adding to it costs one order rather than a migration.

When you re-pull, update cost, limits and capability flags but never overwrite a name or description you have edited. That single rule saves an enormous amount of rework — otherwise every sync undoes the wording you wrote for your own customers.

Idempotency and duplicate orders

The one failure mode that costs real money is a timeout on add: your request went through, the response did not come back, and your retry places the order twice. The spec has no idempotency key, so the protection has to be yours.

Record your own reference against the order before you call, and on a timeout query status rather than retrying blind. If you must retry, retry once and reconcile afterwards. A reseller who retries aggressively on timeouts eventually discovers it the expensive way.

What to log

Log the request you sent and the body you got back for every order, keyed by your own order id. When a customer asks why their order says one thing on your panel and another on their account, that log answers it in seconds. Without it you are guessing, and guessing in front of a customer is how you lose one.

Getting a key

Generate one from Dashboard → API. Treat it exactly like a password: anyone holding it can spend your balance. Keep it in your server environment, never in front-end code, and regenerate it immediately if it has ever been pasted somewhere it should not have been.

No comments yet — be the first.