Integrating an SMM Panel API (v2): a practical guide for building reseller tools

#python #api #tutorial #webdev

AI disclosure: this article was written with the assistance of AI, then reviewed and edited before publishing.

Full disclosure: I build AutoSMO, and I use its public v2 API as the live example in this guide. The idempotency, catalogue-refresh and partial-order patterns below apply to any order API, not just this one.

If you're building a social-media growth storefront, a reseller bot, or an automation that places engagement orders, you'll almost certainly integrate an SMM panel API. Most panels — including AutoSMO, which I'll use as the live reference here — expose the same v2 API shape, so what you learn on one carries over to the rest.

This is a practical walkthrough: the core calls, working code, and the four mistakes that turn a clean integration into refunds and chargebacks.

The shape of a v2 SMM API

A v2 panel API is a single endpoint that takes a POST with your key, an action, and parameters. The actions you actually need:

services — the full catalogue: IDs, names, per-1000 rate, min/max, refill terms.
add — place an order (service ID + link + quantity).
status — poll an order (spent charge, start count, remains, state).
balance — your account balance.
refill — request a refill on an eligible order.

That's the whole surface. Everything else is your own business logic on top.

A first request, end to end (Python)

import requests

API = "https://autosmo.com/api/v2"
KEY = "YOUR_API_KEY"  # server-side only — see below

def call(action, **params):
    r = requests.post(API, data={"key": KEY, "action": action, **params})
    r.raise_for_status()
    return r.json()

# 1. Read the catalogue and pick a service
services = call("services")
service = next(s for s in services if s["service"] == "6758")

# 2. Validate against the service's own limits BEFORE ordering
qty = 1000
assert int(service["min"]) <= qty <= int(service["max"]), "quantity out of range"

# 3. Place the order
order = call("add", service=service["service"], link="https://instagram.com/p/…", quantity=qty)
print("order id:", order["order"])

# 4. Poll it to completion
status = call("status", order=order["order"])
print(status)   # {'charge': '0.72', 'start_count': '...', 'remains': '...', 'status': 'In progress'}

Node is the same three moves — services → validate → add → poll status.

The four mistakes that cost real money

1. The key is a wallet, not a config detail. It authorises spending. It belongs in server config — never in front-end JavaScript, a mobile bundle, or a public repo. Anyone holding it can place orders against your balance. Rotate it the moment it touches a browser, a chat, or a screenshot.

2. add has no idempotency key — so never auto-retry it. A timeout does not mean the order failed. If your client blindly retries, one customer order becomes two paid orders. Queue timeouts for a human to reconcile against status, don't fire them again automatically.

3. Your catalogue copy goes stale. Rates, limits and availability change when suppliers change theirs. If you cache services and forget to refresh on a schedule, you'll sell at prices you no longer have. Poll it; don't hardcode it.

4. Map remains into your refund logic. Orders come back partial when the provider delivers some but not all of the quantity. remains tells you how much didn't land. Marking a partial delivery as "complete" to your own customer is the fastest way to earn a chargeback — reflect the shortfall honestly.

Balance-aware queuing

Because there's no invoice step, add only succeeds while the balance covers the order. For any real volume, poll balance and pause your queue before it hits zero, rather than letting orders fail mid-batch:

if float(call("balance")["balance"]) < estimated_cost:
    pause_queue()   # top up, then resume

Test one real order before you switch traffic over

Place the smallest order the catalogue allows, poll it to completion, and confirm your side matches charge to the cent. That single end-to-end test teaches you more than any doc — and it's the difference between "it returns 200" and "it actually fulfils."

The full call list, parameters and example responses for the reference implementation are on the AutoSMO API page — it's a live v2 endpoint you can read your integration against.

Building reseller tooling on top of an SMM API? The gotchas above (idempotency, stale catalogue, partial mapping) are where most integrations quietly leak money — worth wiring up front.

DEV Community