DEV Community: MmdNaji

An SMM API told me an order was 100% delivered a second after I placed it

MmdNaji — Tue, 06 Oct 2026 15:04:46 +0000

I work on the order routing of an SMM panel. A customer orders, say, 5,000 Telegram post views; we pass the order to an upstream provider over the standard SMM API v2 (action=add), then poll action=status every couple of minutes until the order settles.

During a test with real orders, one order showed 100% delivered about a second after it was sent. On the next poll it showed 0%. Nothing had been delivered either time.

What the API actually returned

These are the first two status replies to that order, exactly as they arrived (only the provider's order id is replaced):

+10s  {"charge":"0","order":"1234567","remains":0,"start_count":0,"status":"In progress"}
+30s  {"charge":"0.0125","order":"1234567","remains":"5000","start_count":"0","status":"In progress"}

The first reply is a placeholder. The provider had not registered the order yet and answered with zeros. Read literally, though, it says three things:

remains: 0: nothing is left, so everything was delivered;
start_count: 0: the counter started from zero;
charge: "0": the order cost nothing.

None of that is true, and twenty seconds later the same provider said so. We saw the same shape from two different upstream providers and on two different service types, so this is not one provider's bug. It is simply what these APIs do while an order is still being registered. Note also that remains arrives as an integer in one reply and as a string in the next.

The naive code

$delivered = $order['quantity'] - (int)$reply['remains'];
$cost      = (float)$reply['charge'];

It is the obvious way to write it, and the placeholder breaks it in three ways.

1. The customer sees progress jump. 100% one second after ordering, then back to 0%. To a customer that looks broken.

2. A fallback chain silently stops. Some of our services are routed through several providers in sequence: if provider A delivers only part of an order, the rest goes to provider B. "How much is still owed" is quantity - delivered, and with the placeholder that is zero. So the router decides the order is complete and never opens the second leg. Nothing throws and nothing logs an error; the order simply ends up short.

3. Your margin is wrong. We compute cost from the charge the provider returns, not from a price list, because a price list goes stale and a cancel costs nothing. A placeholder "0" reads as "this order was free".

The rules that fixed it

Only Completed may claim full delivery. In progress with remains: 0 proves nothing.
Pending means zero delivered, whatever remains says.
While an order is live, progress never goes backwards. A later reply cannot un-deliver what an earlier, real reply reported.
A final status lifts those guards. Completed, Partial, Canceled and Refunded are the provider's last word, and the refund is calculated from them, so they are taken as they come.
Store one number. Keep delivered and derive remains from it, so the two can never disagree.
Never replace a real start_count with 0.
Believe a charge only when it is above zero or the status is final. Keep "the provider has not told us yet" (null) separate from "the provider told us it was free" ("0"). A canceled order really does cost 0.

The code

<?php
const FINAL_STATUSES = ['Completed', 'Partial', 'Canceled', 'Refunded'];

function apply_status(array $leg, array $reply): array
{
    $status = (string)($reply['status'] ?? $leg['status']);
    $final  = in_array($status, FINAL_STATUSES, true);
    $qty    = (int)$leg['quantity'];
    $remains = isset($reply['remains']) && is_numeric($reply['remains'])
        ? max(0, min($qty, (int)$reply['remains']))
        : $qty;

    if ($status === 'Pending') {
        $delivered = 0;                          // nothing has started
    } elseif ($status === 'Completed') {
        $delivered = $qty;                       // the only status allowed to claim everything
    } else {
        $delivered = $qty - $remains;
        if (!$final && $delivered >= $qty) {
            $delivered = (int)$leg['delivered']; // "In progress" + remains 0 = placeholder
        }
    }
    if (!$final) {
        $delivered = max($delivered, (int)$leg['delivered']); // never run backwards while live
    }

    $start = $leg['start_count'];
    if (isset($reply['start_count']) && is_numeric($reply['start_count'])) {
        $s = (int)$reply['start_count'];
        if ($s > 0 || $start === null) $start = $s; // never replace a real count with 0
    }

    $charge = $leg['charge'];                    // null = the provider has not said yet
    if (isset($reply['charge']) && is_numeric($reply['charge'])) {
        if ((float)$reply['charge'] > 0 || $final) {
            $charge = (string)$reply['charge'];  // "0" mid-flight is a placeholder; on a cancel it is real
        }
    }

    return [
        'quantity'    => $qty,
        'status'      => $status,
        'delivered'   => $delivered,
        'remains'     => $qty - $delivered,      // derived, so the two can never disagree
        'start_count' => $start,
        'charge'      => $charge,
    ];
}

$leg is whatever you already know about the order: its quantity, last status, delivered count, start count and charge. The function never trusts a single reply on its own; it merges the reply into that state.

Test it with the replies you actually recorded

The cheapest test you can write for this is a replay. Save the raw replies your providers really send, in order, and assert what your code makes of each one:

$leg = ['quantity' => 5000, 'status' => 'Pending', 'delivered' => 0,
        'start_count' => null, 'charge' => null];

$replies = [
    ['charge' => '0',      'remains' => 0,      'start_count' => 0,     'status' => 'In progress'],
    ['charge' => '0.0125', 'remains' => '5000', 'start_count' => '0',   'status' => 'In progress'],
    ['charge' => '0.0125', 'remains' => '0',    'start_count' => '812', 'status' => 'Completed'],
];

foreach ($replies as $reply) {
    $leg = apply_status($leg, $reply);
    echo "{$leg['delivered']} delivered, charge ", var_export($leg['charge'], true), "\n";
}
// 0 delivered, charge NULL      <- the placeholder changes nothing
// 0 delivered, charge '0.0125'
// 5000 delivered, charge '0.0125'

The first two replies are the recorded ones; the third is an illustrative final reply. With the naive code, the first line would have read "5000 delivered, charge 0".

Add a canceled order (remains equal to the quantity, charge "0") and a Partial that the provider re-prices downward, and you have covered every case that bit us.

Checklist

Treat the first status reply after add as possibly fake.
Let only a final status claim completion or a final price.
Never let live progress run backwards.
Keep null ("not told yet") and 0 ("told: free") apart.
Parse numbers defensively: the same field arrives as an int and as a string.
Replay real recorded replies in your tests, not hand-written ideal ones.

Disclosure: I run TGLUX, a Telegram SMM provider, and these rules came out of building its order routing. The status format above is the standard SMM API v2 one; our reference for it is at https://smmtglux.com/api-docs.

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.