The SMM API returns HTTP 200 when it fails, and three other traps

MmdNaji — Mon, 07 Sep 2026 02:35:31 +0000

Social media marketing panels almost all speak the same HTTP interface. Nobody wrote a spec for it, everybody copied it from everybody else, and it is universally called "API v2". Five form fields, seven actions, JSON out.

I wrote a PHP client for it recently. The protocol is small enough to read in ten minutes and has four traps that will each cost you an afternoon. Here they are, so they cost you nothing.

1. Every response is HTTP 200, including the failures

This is the big one.

POST /api/v2
key=WRONG&action=balance

HTTP/1.1 200 OK
{"error":"Invalid API key"}

Not 401. Not 400. 200 OK, with the failure in the body.

So the first thing every integration does — check the status code — tells you nothing at all:

$res = json_decode($body, true);
if ($http === 200) {
    $orderId = $res['order'];   // undefined index, and you already charged the customer
}

The check you actually need is whether error is the whole answer:

if (isset($data['error']) && count($data) === 1) {
    throw new ApiException($data['error']);
}

That count($data) === 1 matters, which brings us to the second trap.

2. In a batch, an error is data — not a failure

The batch endpoints let you ask about up to 100 orders at once:

action=status&orders=1,2,3

and the reply mixes successes and failures in the same object:

{
  "1": {"charge":"1.50","status":"Completed","remains":"0","currency":"USD"},
  "2": {"error":"Incorrect order ID"},
  "3": {"charge":"0.62","status":"In progress","remains":"380","currency":"USD"}
}

If your error check is "does the response contain the key error anywhere", one bad id throws away ninety-nine good rows. Order 2 being wrong is a fact about order 2, not about the request.

3. Use the batch endpoints, or the rate limit will find you

Panels rate-limit per API key. The one I built against allows 120 requests a minute; others are tighter.

Polling a hundred orders in a loop is a hundred requests. The same hundred orders in one status call is one. If you are syncing order state on a cron — and you are, that is what this API is for — this is the difference between a job that works and a job that starts returning Rate limit exceeded at 2am when your order volume grows.

// no
foreach ($orders as $id) { $status[$id] = $smm->status($id); }

// yes
$status = $smm->multiStatus($orders);          // up to 100 per call

4. Money has seven decimal places. Keep it a string.

Rates are per 1000 units, and cheap services genuinely cost fractions of a cent:

{"service":1706,"name":"Seen Post","rate":"0.0025","min":"100","max":"1000000"}

An order of 1000 at 0.0025 charges you a quarter of a cent. The panels store money at seven decimals precisely so that arithmetic like this stays exact.

The moment you (float) that on the way in and format it on the way out, you have introduced a rounding step into the one part of your application where rounding is not allowed. Keep the string the API gave you, and do arithmetic in integers or a decimal type.

One security note, because the key is in the body

The API key is a POST field, not a header. That means a redirect will re-POST your key to whatever host the redirect names. Turn redirect-following off:

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);

It is one line, and it is the difference between an API key that stays yours and one that does not.

And one thing that is not a bug

cancel is a request. The response {"order":123,"cancel":1} means the cancellation was asked for, not that it happened and not that you were refunded — the upstream provider decides, and a partially delivered order usually cannot be cancelled at all. Poll status for the outcome instead of treating the 1 as done.

The client

I put the PHP implementation on GitHub under MIT: SmmTGlux/smm-api-php.

composer require smmtglux/smm-api

use Tglux\Smm\Client;

$smm = new Client('YOUR-API-KEY');                      // any panel, not just one
$smm = new Client('YOUR-API-KEY', 'https://other.panel/api/v2');

$services = $smm->services();
$order    = $smm->add(1706, 'https://t.me/yourchannel/12', 1000);
$status   = $smm->multiStatus([$order, 41, 42]);

No dependencies beyond ext-curl and ext-json, PHP 8.1+, and the HTTP layer is swappable — the fourth constructor argument takes a callable(string $url, array $fields, int $timeout): string, which is also how the test suite runs entirely offline.

It is deliberately not tied to one panel. The default endpoint is the panel I built it against, whose API documentation lists every action and parameter, but point it anywhere that speaks v2 and it works the same.

If your panel does something the client does not handle, open an issue — the interface is a de-facto standard, which is a polite way of saying every implementation differs slightly, and I would rather know.

DEV Community: MmdNaji