If you run a reseller store, an agency dashboard, or any automation that orders social media services at volume, doing it by hand does not scale. That is what the SMM panel API is for: a programmatic interface that lets your own systems place orders, check status, request refills, and sync service lists without touching a browser.
Most panels in this industry expose a similar API shape — often called "SMM API v2" — because so many panels are built on shared software. The action names and general flow below describe that common pattern. Exact endpoint URLs, parameter names, and response fields vary from panel to panel, so always read the specific panel’s API documentation before you write a line of code.
The standard API pattern
The typical SMM panel API is a single HTTP endpoint that accepts POST requests. You tell it which action you want with an action parameter, pass your credentials, and get back a simple JSON response. There is usually no OAuth dance, no SDK, and no sandbox — just a key and a handful of actions.
Authentication: your API key
Access is granted through an API key tied to your panel account. You generate it in your dashboard (usually under an API or settings page) and include it with every request. Treat it like a password: anyone holding your key can spend your balance. Never commit it to a public repository, never put it in client-side JavaScript, and rotate it immediately if it leaks.
The core actions
Across most panels, the same six actions cover nearly everything a reseller needs. Names differ slightly between panels, but the concepts are consistent:
- services — returns the panel’s service list with IDs, names, rates, and min/max quantities. Sync this regularly; services change.
- add — places an order. You pass the service ID, the target link, and the quantity, and get back an order ID.
- status — checks one order (or several) by order ID. This is how you track Pending, In progress, Partial, Completed, or Canceled states.
- balance — returns your remaining wallet balance. Poll this before placing large batches so orders do not fail mid-run.
- refill — requests a refill on an eligible order within its refill window.
- cancel — cancels a pending order where the panel allows it.
That is the whole vocabulary. Everything else — your storefront, your pricing, your customer dashboard — is built on top of these primitives.
Placing an order, step by step
A typical integration follows the same loop. First, sync the service list and map the panel’s service IDs to the products in your own catalog. When a customer orders from you, your backend calls the add action with the mapped service ID, the customer’s link, and the quantity. Store the returned order ID against your own order record immediately — that ID is your only handle on the order from here on.
- Validate the customer’s link and quantity against the service’s min/max before calling add.
- Check your balance first on large orders; a failed add mid-batch creates reconciliation headaches.
- Store the panel’s order ID with your internal order the moment it returns.
- Deduct or reserve the cost from the customer’s balance in your own system at the same time.
Polling order status
Order status is the action you will call most. After placing an order, poll the status action on a schedule — every few minutes for fresh orders, less often as they age — and mirror the state into your own system so customers see progress. Typical statuses include Pending (accepted, not started), In progress (delivering), Partial (finished short of the full quantity — common enough that your code must handle it), Completed, and Canceled.
Partial completion deserves special attention: if a customer paid for 1,000 and the panel delivered 850, your system needs a policy — partial refund, automatic reorder of the remainder, or manual review — before it happens, not after.
Webhooks: convenient when offered
Some panels can push order updates to a URL you provide (a webhook) instead of making you poll. Webhooks reduce latency and API calls, but not every panel offers them, and the ones that do vary in reliability. Build polling as your baseline and treat webhooks as an optimization, not a dependency. If a panel’s docs do not mention webhooks, assume they do not exist.
Error handling basics
- Retry with backoff on network failures and 5xx responses — never hammer a failing endpoint.
- Treat "insufficient balance" as a normal business error: alert yourself, pause the queue, top up.
- Log every request and response with timestamps; when a customer disputes an order, these logs are your evidence.
- Validate service IDs on each sync — panels retire and renumber services, and a stale ID means failed orders.
- Keep your API key in server-side environment variables, never in frontend code or mobile apps.
Common mistakes
- Hardcoding service IDs without re-syncing — services change and orders start failing silently.
- No handling for Partial status — the most common source of reseller-customer disputes.
- Polling every few seconds — you will hit rate limits; poll on a sensible schedule instead.
- Exposing the API key in client-side code — equivalent to publishing your wallet password.
- Promising customers delivery speeds the panel never promised you — pass through honest timelines.