Pourquoi un timeout d’API SMM peut vous facturer deux fois — et pourquoi NotPanel ne le fait pas
Un timeout n’est pas un échec. Sur la plupart des API de panneaux SMM, un nouvel essai est une deuxième commande. NotPanel exige request_id pour que le même add ne débite pas deux fois.
Vous lancez add. Le TCP tombe. Le client timeout. Vous renvoyez la même commande — que faire d’autre ?
Sur les pages API publiques de JustAnotherPanel et CheapSMMPanel, ce second add est une seconde commande. Deux débits. Un client. Leurs docs invités ne parlent pas d’idempotence. Leurs samples PHP n’envoient pas de clé.
Chez NotPanel le second add est la même commande. Nous refusons action=add sans request_id de l’appelant. Même clé, même corps, l’id d’origine. Pas un slogan. C’est le contrat de création de commande.
La dernière fois qu’un add a timeout, qu’a fait votre client ?
Touchez une option. Enregistré uniquement sur cet appareil — ce n’est pas un sondage inventé.
L’échec que personne n’écrit
Après un timeout, trois choses peuvent être vraies à la fois. On ne sait pas laquelle. Touchez une carte.
Un timeout est un inconnu, pas un échec. Les pages v2 clonées le traitent comme un échec : add encore. C’est ainsi que les child panels se réveillent avec un double débit.
Comparaison complète : JustAnotherPanel vs CheapSMMPanel vs NotPanel.
À quoi ressemble un retry sûr
La règle qui marche vraiment
request_id=550e8400-e29b-41d4-a716-446655440000
Si le serveur émettait la clé, chaque retry en aurait une nouvelle. Du théâtre. C’est pourquoi nous ne la générons pas pour vous. Le guide d’intégration donne la forme du client.
Un timeout est un inconnu. Le seul retry sûr est celui que le serveur reconnaît comme la même requête.
Le neuf n’est pas le risque. Un contrat impossible à tester l’est.
Un panneau de dix ans avec la même page /api photocopiée n’est pas « de confiance ». Il est familier. Le familier vous débite encore deux fois quand le réseau cligne.
NotPanel est plus récent. Le contrat est public : /developers, un changelog, des codes d’erreur, des en-têtes de limite. Vous pouvez prouver le retry avec une clé de staging ce soir. Voilà à quoi ressemble la confiance quand l’argent voyage en HTTP.
Ensuite : webhooks vs polling de statut pour un child panel.
FAQ
Pourquoi l’API de mon panneau SMM m’a-t-elle facturé deux fois ?
Souvent un timeout plus un retry. Le premier add est arrivé, pas la réponse. Le second add est devenu une nouvelle commande faute de clé d’idempotence fournie par l’appelant. Les docs invités de JustAnotherPanel et CheapSMMPanel n’en documentent pas.
JustAnotherPanel prend-il en charge les commandes idempotentes ?
Pas sur cette page publique d’API. Pas de request_id (ni équivalent) sur add. Leur sample PHP officiel n’en envoie pas. Traitez un retry comme une seconde commande sauf s’ils le documentent ailleurs de façon citable.
Quelle est la meilleure API de panneau SMM si les retries comptent ?
Celle qui exige une clé de l’appelant sur add et renvoie la commande d’origine quand cette clé est rejouée. NotPanel le fait. Les pages v2 clonées du marché non. « Meilleur catalogue » et « meilleur prix » sont d’autres questions, qui changent chaque semaine.
Un nouveau panneau SMM est-il moins fiable ?
Non si vous pouvez tester le chemin de l’argent. Un contrat public, un request_id obligatoire et une clé de staging que vous pouvez envoyer deux fois ce soir battent une décennie de one-pager non signé. Familier n’est pas sûr.
Qui doit générer request_id ?
Vous. Une fois. Hors de la boucle de retry. Si le serveur le génère, chaque essai aura une nouvelle clé et vous aurez de nouveau deux commandes. NotPanel refuse add sans lui.