Reselling in the SMM sector means connecting to a panel's API and selling those services through your own site, bot or application. The customer never sees the panel; they order from you, and your system passes the order on behind the scenes. This guide covers how that integration works and what has to be handled for it to run reliably.
What the API v2 standard covers
Most panels expose what the industry calls an API v2. It is not a formal specification but a convention that has settled over time, and the practical benefit is portability: code written against one panel usually needs only small changes to work against another.
The endpoint set is small and predictable. You send a request with an API key and an action parameter, and you get JSON back. Five actions cover almost everything.
- services — pulls the full catalogue with IDs, names, prices, minimum and maximum quantities.
- add — creates an order with a service ID, a target link and a quantity; returns an order ID.
- status — reports an order's state, charge, start count and remaining quantity.
- balance — returns your current balance.
- refill — raises a replacement request on services that support it.
Most panels also support a multi-status call that takes several order IDs at once. Using it matters: polling a hundred orders one at a time is both slow and likely to hit rate limits.
Service mapping: the part that decides everything
The single most important design decision in a reseller system is how you map panel services to your own products. The naive approach — showing the panel catalogue as-is — causes problems quickly. Panel service IDs can change, services get retired, and names carry technical tags your customers do not need to read.
The sound approach is an intermediate layer. You define your own products with your own names and descriptions, and each of your products points to one or more panel service IDs. When a panel service is retired you repoint your product to a different ID, and your customers notice nothing.
That layer also lets you define a fallback. If a product maps to two service IDs and the first returns an error, your system tries the second. This is exactly the redundancy that good panels build internally, and building it at your layer too makes your service noticeably more reliable.
Margin and pricing logic
Margin is usually applied one of two ways. A percentage markup adds a fixed percentage over the panel price — simple, and it adapts automatically when panel prices move. A fixed markup adds a set amount per thousand, which protects margin on cheap services but can make expensive ones uncompetitive.
In practice a hybrid works best: a percentage markup with a minimum floor, so very cheap services still cover their transaction cost. Whichever you choose, the important part is recalculating when panel prices change. A system that caches panel prices and never refreshes them will eventually sell below cost.
Refreshing the catalogue on a schedule handles this. Pulling the service list once or twice a day, comparing prices and updating your own is enough for most operations. Flagging services whose price moved sharply for manual review is a worthwhile safeguard.
Handling order states properly
An order does not finish when you create it. It moves through states, and your system has to reflect that to the customer honestly. The common states are pending, in progress, completed, partial, cancelled and, on some panels, processing.
Partial is the state that needs the most care. It means some of the quantity was delivered and the rest could not be. The panel refunds the undelivered portion to your balance — and your system has to pass that refund on to your customer. A reseller system that does not handle partials correctly either loses money or shortchanges customers, and both damage trust.
Cancelled needs similar handling: the full amount returns to your balance and has to return to your customer too. Automating both cases is far better than handling them by hand, because at volume manual reconciliation stops being feasible.
Validation before you send
The cheapest error to fix is the one that never reaches the panel. Validating on your side before creating an order saves both money and support time.
Check the quantity against the service's min and max, which the services call returns. Check the link format matches the service type — a post service needs a post URL, a profile service a username. Check your balance covers the order. And normalise the link: strip tracking parameters, expand shortened URLs, remove a leading @ where the panel expects a bare username.
These checks take little code and remove the majority of failed orders. They also let you show the customer a clear message instead of a generic API error.
Rate limits and polling
Panels apply rate limits, and a reseller system that ignores them gets throttled at exactly the wrong moment. Two habits keep you inside the limits.
First, do not poll completed orders. Once an order reaches completed, cancelled or partial, its state is final; keep checking only the ones still open. Second, use multi-status calls and batch open orders together rather than requesting them individually.
Polling frequency should also match reality. Most orders take hours, so checking every thirty seconds achieves nothing beyond burning your quota. Checking every few minutes at the start and backing off as an order ages is both gentler and perfectly adequate.
Keeping the API key safe
An API key gives full access to your balance. Anyone holding it can place orders and drain it. Three precautions cover the realistic risks.
Keep the key server side only — never in front-end code, never in a mobile app bundle. Read it from configuration or an environment variable rather than hard-coding it, so rotating it does not mean a code change. And rotate it if you suspect exposure; panels generally let you regenerate a key from the account settings.
Keeping a modest balance is a further safeguard. Holding one to two months of spend rather than a year's keeps your exposure bounded if something does go wrong.
Frequently asked questions
What does the API v2 standard include?
Five core actions cover almost everything: pulling the service list, creating an order, checking order status, reading the balance, and raising a refill request. Most panels also support a multi-status call for several orders at once.
Why should I not show the panel catalogue directly?
Panel service IDs change and services get retired. An intermediate layer lets you define your own products pointing at one or more panel IDs, so you can repoint them without your customers noticing.
How should I handle a partial order?
The panel refunds the undelivered portion to your balance, and your system has to pass that refund on to your customer. Automating it is important; manual reconciliation stops being feasible at volume.
How do I avoid hitting rate limits?
Stop polling orders that have reached a final state, batch open orders into multi-status calls, and back off the polling interval as an order ages.