SMM Panel API Integration Guide (API v2)

The SMM panel API v2 is the industry-standard HTTP interface for ordering social media engagement programmatically: you send a POST request with form-encoded parameters — your API key plus an action such as services, add, status, balance, or refill — and receive a JSON response. Because almost every panel uses the same format, one integration can talk to many providers with little more than a base URL change. This guide walks through the endpoints, example payloads, and the habits that keep real integrations from breaking.

Why Every Panel Uses the Same API

API v2 is a de facto standard rather than a formal specification. Nearly every SMM panel exposes a single endpoint — usually POST /api/v2 — that accepts form-encoded parameters (Content-Type: application/x-www-form-urlencoded). Every request carries your key, which you generate from your account page, and an action that tells the panel what to do. Responses are JSON. There is no OAuth, no signed headers, no SDK requirement: any HTTP client in any language can integrate in an afternoon.

This uniformity exists because most panels descend from the same software lineage, and it is the most useful property of the ecosystem. A client written for one panel usually works against another after changing the base URL and key. That is how resellers connect their storefronts to upstream suppliers, and how aggregation platforms such as ZiloSMM sit behind one interface while routing to many sources. If panels themselves are new to you, read what an SMM panel is first.

The Five Core Actions

Almost everything you will build uses five actions. All of them go to the same endpoint; the action parameter decides the behavior.

ZiloSMM implements this exact contract; the full parameter reference lives in the API documentation.

Example Request and Response Shapes

Listing the catalog

Request: POST https://zilosmm.com/api/v2 with the body key=YOUR_KEY&action=services. The response is a JSON array where each item looks like this:

{"service": 1210, "name": "Instagram Followers — Provider 3", "category": "Instagram", "rate": "1.20", "min": 100, "max": 50000, "refill": true}

Two conventions to know: rate is the price per 1000 units, which is how nearly all panels price services, and min/max define the quantity range the service will accept per order.

Placing an order

An add request needs three extra parameters besides your key:

• service — the numeric service ID from the catalog
• link — the target URL (a post, video, channel, or profile, depending on the service)
• quantity — how many units you want, within the service's min/max range

A successful response is small: {"order": 987654}. Store this ID immediately — it is the only handle you have for tracking, support tickets, and refill requests.

Checking order progress

Send action=status with the order ID. A typical response: {"charge": "0.60", "start_count": 3150, "status": "In progress", "remains": 420, "currency": "USD"}. Common status values are Pending, In progress, Completed, Partial, and Canceled. The start_count field is the metric's value when delivery began, and remains is the quantity not yet delivered.

Integration Tips That Prevent Real Problems

Cache the services list

Catalogs are large — often thousands of rows — and they change without notice. Do not call action=services on every page load. Sync the catalog on a schedule, store it locally, and diff each sync so you catch price changes, new min/max limits, and removed services before your customers hit them.

Validate quantity before ordering

Every service enforces its min and max. On ZiloSMM, an order below the minimum simply will not deliver, and other panels either behave the same way or reject the request outright. Check quantity against your cached catalog before calling add, and validate the link format for the target platform too. Picking an appropriate service matters as much as clean code — see how to choose SMM services.

Poll status with backoff

Do not poll every few seconds. A sane pattern is to check about a minute after placing the order, then back off progressively — every 5 minutes, then every 15 — until the order reaches a terminal state. Many panels also accept a comma-separated orders parameter for batch status checks, which cuts request volume further. Respect rate limits: aggressive polling is the most common reason API keys get throttled.

Handle Partial correctly

Partial means delivery stopped before the full quantity, and the value in remains is normally refunded to your wallet. Your integration should read remains, credit or notify your own customer, and close the order. Note that partial and refill are different mechanisms — refill covers metric drops after completion on services that support it. The details are covered in refill, drop and partial explained.

Never retry add blindly

The add action is not idempotent. If your request times out, the order may still have been created and charged — a blind retry creates a duplicate order and double spend. Record your intent locally before calling add, and on timeout, verify through your balance or order history (or hold the order for manual review) before retrying. Only auto-retry on responses that clearly indicate the order was not created, such as a validation error.

A Simple Reseller Flow

Most reseller integrations reduce to three stages. First, sync the catalog: pull action=services on a schedule and store it as your source of truth. Second, apply markup: your pricing layer takes the upstream rate and adds your margin — a flat percentage is the usual starting point. Third, forward orders: when your customer buys, validate quantity and link, call add upstream, map the returned order ID to your local order, then mirror status updates back to the customer as you poll.

One practical note on supplier choice: with a single-source panel, an upstream outage stops your storefront. ZiloSMM routes each order across more than 30 upstream providers with health monitoring and automatic failover, shown as anonymous aliases such as "Provider 1" — so one key and one integration give you multi-supplier redundancy without maintaining thirty separate connections.

Honest Notes Before You Go Live

Two things worth saying plainly. Buying engagement can violate the terms of service of the social platforms involved, and no panel can honestly promise results are undetectable or risk-free — if you resell, be transparent with your own customers about this. And treat the upstream API as shared infrastructure: respect rate limits, batch requests where you can, and back off when you receive errors.

Ready to build? Create a free ZiloSMM account, generate an API key from your account page, and keep the API docs open while you work — the endpoint, parameters, and response shapes there match everything described above.