If you sell social media services, at some point you stop placing orders by hand. The API is how that happens. The good news is that the SMM industry converged on a single de facto standard years ago — API v2 — so the integration you write for one supplier works almost unchanged for the next.
This is a practical walkthrough: what the endpoints do, what the failure modes are, and the decisions that actually cost money if you get them wrong.
Everything is a POST to a single endpoint with an action parameter and your API key. There are no REST paths, no JSON request bodies, and no OAuth. It is form-encoded and boring, which is why it works everywhere.
The actions you need:
| Action | What it does |
|---|---|
services | Returns the full catalogue: service ID, name, category, rate per 1000, min, max, and which features the service supports |
add | Places an order. Takes a service ID, link and quantity, plus extra fields for drip-feed or custom comments |
status | Returns charge, start count, remaining and status. Pass order for one, or orders with up to 100 comma-separated IDs for a batch |
refill | Requests a refill, single or up to 100 at once. refill_status checks how it went |
cancel | Requests cancellation, where the service supports it |
balance | Returns your remaining balance and currency |
Order placement has three shapes: a default order (service, link, quantity), a custom-comments order (a newline-separated comment list instead of a quantity), and a subscription (a username plus min/max, which watches for new posts and creates orders automatically).
This is the most common mistake and it is expensive in both rate limit and wall-clock time. Use the orders parameter instead of order: it accepts a comma-separated list of up to 100 order IDs and returns them all in one response, with per-order errors for any ID that is wrong. Polling 500 orders individually every five minutes means 500 requests; polling them in batches of 100 means five.
Also: stop polling completed orders. Once an order reaches a terminal state, it does not change. Keeping finished orders in your polling loop is the single biggest source of wasted API calls in most reseller integrations.
Supplier catalogues change constantly. Services get disabled, prices move, minimums and maximums change. If you cached the list a month ago and you are still pricing from it, you are quoting numbers that no longer exist — and when a service is removed upstream, your orders start failing with errors your customers see.
Refresh the catalogue on a schedule, and diff it. What you want to catch is: services that disappeared, services whose rate moved enough to break your margin, and services whose maximum dropped below order sizes you already sell.
Every order costs you money at the supplier and earns you money from your customer. Those two numbers drift apart quietly — partial deliveries, cancellations, refunds and rate changes all cause it. Pull balance on a schedule and reconcile it against what your own system thinks you spent. A mismatch is the earliest signal that something is wrong in your order pipeline.
Your markup is applied to the supplier rate, and the temptation is to apply one flat percentage across the catalogue. That is a mistake, because the catalogue is not homogeneous.
Cheap, high-volume services — views, low-tier likes — are the ones customers price-compare, often down to the third decimal. Margins there have to be thin. Expensive, targeted or guaranteed services are bought on trust and specificity, and they carry a much larger markup comfortably.
A workable structure is a percentage markup with a floor, so tiny-rate services do not end up priced at fractions of a cent, and a lower percentage on the handful of services you compete on directly. Whatever you choose, apply it programmatically from the supplier rate rather than typing prices in by hand — otherwise a supplier price rise silently turns into a loss.
Two features worth exposing to your customers because they are easy to support and genuinely useful.
Drip-feed splits one order into runs delivered at intervals: quantity per run, number of runs, and delay between them. It is how you make growth look gradual instead of arriving in a single spike. Through the API it is the same add action with extra parameters.
Mass order is a batch submission — a list of orders in one request. If your customers are agencies handling many accounts, this is the feature they will ask for first.
Two ways to resell, and they suit different people.
An API integration means you run your own panel and point it at a supplier. You control the front end, the pricing, the customer accounts and the support. It requires you to build and maintain something.
A child panel is a ready-made panel on your own domain, provisioned by the supplier. No development work, much less control. It is the faster path if you want to start selling this week rather than this quarter.
The API route is worth it if you plan to differentiate — on interface, on service selection, on support quality. If you plan to compete purely on price, the child panel gets you there with less overhead.
Price is the obvious criterion and the least reliable one, because the cheapest rate on a service that does not deliver costs you a refund plus a customer. What to check instead:
Our API is standard v2 — if you have integrated with any SMM supplier before, the only thing that changes is the endpoint and the key. The full parameter reference is on the API page. Every service exposes the same measured delivery data through the catalogue that the services page shows: average completion time, orders delivered in the last 24 hours, and drop rate, refreshed every ten minutes.
Child panels are available if you would rather not build. Create an account to get an API key and start against the live catalogue.