Comparatif des API de panels SMM : JAP, CheapSMMPanel et NotPanel
Comparaison de trois API SMM publiques selon les champs, les retries, les webhooks et les erreurs HTTP, d'après leurs contrats publiés.
J'ai ouvert trois pages API publiques : JustAnotherPanel, CheapSMMPanel et NotPanel. La comparaison porte sur le contrat, pas sur les prix ni la taille du catalogue.
Deux pages répètent la forme v2 connue. Les vraies différences commencent après le premier POST : noms de champs, identité du retry, webhooks et statut HTTP.
Qu'est-ce qui vous empêcherait de relier un panel enfant à un nouvel upstream ?
Touchez une option. Enregistré uniquement sur cet appareil — ce n’est pas un sondage inventé.
Le tableau
Les trois utilisent un POST de style v2 avec formulaire et réponse JSON. Ensuite, elles ne sont plus interchangeables.
Un client JAP doit remapper ses champs pour parler à CheapSMM. Pour créer une commande chez NotPanel, il doit aussi envoyer request_id : c'est volontaire.
La même commande d'exemple. La même photocopie.
Les pages publiques montrent la commande de démonstration et le flux list, add, status, balance. C'est suffisant pour le premier appel, mais pas pour comprendre une panne réseau.
Un exemple prouve la syntaxe, pas le comportement des retries, les événements signés ni la gestion des erreurs. Relisez le contrat public avant de publier l'intégration.
Les noms de champs ne sont pas un détail
| Fonction | JAP / NotPanel | CheapSMMPanel |
|---|---|---|
| Authentification | key | api_token |
| Catalogue | action=services | action=packages |
| ID service | service | package |
| Compteur initial | start_count | start_counter |
| États | In progress / in_progress | Title case in examples |
CheapSMM présente le changement comme simple, mais modifier auth, catalogue, service et quantité touche chaque appel. Changer l'URL de base n'est pas un plan de migration.
Les chaînes d'état comptent aussi. Un reconciler qui rembourse toute valeur autre que completed peut transformer une différence de nom en perte d'argent.
Pourquoi NotPanel est plus solide là où cela compte
Ce sont des différences de contrat vérifiables, pas une promesse sur le prix ou la taille du catalogue.
Commandes sûres lors des retries
add exige request_id. Rejouer la même clé et le même corps renvoie la commande d'origine ; un corps différent est refusé.
Voir le contrat add →Événements de statut signés
La référence webhooks décrit HMAC-SHA256 sur le corps brut, avec horodatage et événement ; les URL privées ou locales sont refusées.
Vérifier une livraison →Erreurs explicites
L'API documente les réponses HTTP 400, 403, 429 et 500 afin de distinguer entrée invalide, blocage, limite et panne du service.
Lire les erreurs et réponses →Limites visibles
Les réponses publient X-RateLimit-Limit, Remaining et Reset, ainsi que le contexte de tier et la raison du blocage si nécessaire.
Voir les limites →Chaque point peut être testé dans la référence publique avant de migrer un flux reseller.
Un timeout n'est pas un échec
Les clients d'exemple publics ne montrent pas d'identifiant fourni par l'appelant. NotPanel exige request_id pour chaque add : même clé et même corps renvoient l'ID original ; un corps différent est refusé.
Générez la clé une fois, hors de la boucle de retry. Un timeout est un résultat inconnu, pas la preuve que la commande n'a pas eu lieu.
Lisez la référence de création de commande · guide d'intégration.
Un timeout est inconnu. Le seul retry sûr est celui que le serveur peut reconnaître.
Polling ou enveloppe signée
JAP et CheapSMM ne documentent pas de webhooks sortants sur leurs pages API invitées. L'intégration implicite consiste à sonder status jusqu'au changement. Ça marche, mais consomme la limite sur les commandes immobiles.
NotPanel fournit webhook.add, list et remove. Chaque livraison contient HMAC-SHA256 du corps brut, timestamp et événement nommé. Les URL privées et link-local sont refusées ; la livraison est au moins une fois, le handler doit donc être idempotent.
Les recettes sont dans la référence webhooks · guide HMAC.
La ligne de statut, pas 200 avec erreur
Une spec clonée peut renvoyer HTTP 200 avec un objet error. Une librairie de retry qui ne regarde que le statut le prendra pour un succès.
Les limites ont des couches IP, clé et niveau. Lisez les références erreurs et rate limits avant d'écrire une boucle de retry.
C'est l'argument : automatiser avec un contrat sans inventer la moitié manquante. Lisez la documentation publique avant de déplacer le trafic. notpanel.com/developers.
Les deux fuites d'argent ont leur guide : retries après timeout et webhooks contre polling.
FAQ
JustAnotherPanel possède-t-il une API reseller ?
Oui. Sa page v2 publique montre key et action pour services, add, status, refill, cancel et balance. Elle ne documente ni webhooks, ni idempotence, ni catalogue d'erreurs HTTP, ni headers de limite.
Quelle est la différence entre les API JAP et NotPanel ?
La forme v2 de base est proche, mais NotPanel exige request_id, documente des webhooks signés, renvoie des statuts d'erreur explicites et publie les headers de limite. JAP documente davantage de champs spécialisés et cancel.
CheapSMMPanel utilise-t-il la même API que JAP ?
Non. Sa documentation invitée utilise api_token, action=packages, package et start_counter. Un client JAP ne fonctionne pas sans modification.
Les panels SMM prennent-ils en charge les webhooks ?
Certains oui, mais beaucoup de pages v2 publiques n'en parlent pas. Si la signature n'est pas documentée, considérez les POST entrants comme non fiables.
Pourquoi NotPanel exige-t-il request_id ?
Un add en timeout a un résultat inconnu. Sans clé fournie par l'appelant, le retry peut créer un deuxième débit ; même clé et même corps renvoient la commande originale.
Puis-je pointer un client JAP existant vers NotPanel ?
Les lectures demandent généralement de revoir l'URL et la casse des statuts. add exige request_id, cancel n'est pas exposé et les champs spéciaux doivent être documentés.