Comparez une API SMM selon le travail à accomplir : trouver un service, créer une commande, gérer un délai dépassé et vérifier le résultat. Une version ou des champs similaires ne sont qu'un début.
Comparaison NotPanel des références publiques de JustAnotherPanel, CheapSMMPanel et NotPanel, vérifiées le 2026-09-09. Il s'agit d'une revue documentaire, pas d'un test de livraison ou de comptes concurrents. Une fonction absente d'une page publique peut exister ailleurs.
JustAnotherPanel · CheapSMMPanel · NotPanel
Ce que documentent les références publiques
La structure key + action est familière. Avant de changer l'URL, vérifiez le catalogue cible, les identifiants, champs, prix et états. Clés, identifiants de service et soldes ne se transfèrent pas entre panels. Chez NotPanel, l'annulation ordinaire exige un état Pending, avant envoi, dans les 15 premières secondes.
Forme v2 similaire, contrat documenté différent
Authentification JAP / NotPanel: key CheapSMMPanel: api_token
Catalogue JAP / NotPanel: action=services CheapSMMPanel: action=packages
ID service JAP / NotPanel: service CheapSMMPanel: package
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 |
Centralisez la correspondance des champs et conservez des exemples de requêtes et réponses. Les deux pages concurrentes montrent des états avec majuscule initiale. NotPanel fournit status pour l'affichage et status_key stable pour l'automatisation. Un état inconnu demande vérification, il ne prouve pas un droit au remboursement.
Les noms sont du texte d’affichage ; les ID sont le contrat
Utilisez l'identifiant numérique pour commander et le nom pour afficher. services conserve le format courant ; catalog ajoute recherche et pagination. language permet des noms localisés ; canonical_name conserve l'anglais et name_language indique la langue renvoyée, dont en lors d'un retour à l'anglais.
Un timeout n'est pas un échec
Conservez le request_id initial après un délai dépassé.
Réessayez avec la même clé et les détails de commande inchangés.
Enregistrez l’ID retrouvé ou attendez si le résultat reste incertain.
2026-09-09 — request_id et idempotency_key sont facultatifs. Sans eux, le même compte et payload sont protégés 60 secondes ; un doublon volontaire dans cette fenêtre renvoie la première commande. Attendez 60 secondes ou envoyez un request_id unique pour le créer immédiatement.
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.
Utilisez les événements et les requêtes de statut ensemble
Recevez une notification de commande signée.
Vérifiez la signature et l’heure ; gérez les ID d’événements répétés.
Confirmez les états importants de la commande avec une requête status.
Les pages publiques de JAP et CheapSMM consultées le 2026-09-09 documentent les requêtes de statut des commandes. Elles ne décrivent pas de webhooks sortants ; cette absence ne prouve pas que la fonction soit indisponible ailleurs. Renseignez-vous sur les conditions propres au compte dont votre application a besoin.
NotPanel documente des webhooks signés avec nouvelles tentatives, sans garantir chaque notification. Vérifiez X-Webhook-Signature avec le corps original et X-Webhook-Timestamp ; suivez la livraison via X-Webhook-Delivery-Id. Traitez chaque identifiant d'événement une fois et rapprochez les états importants avec status. Refusez les événements hors de la fenêtre temporelle que vous avez choisie contre les répétitions anciennes. Une notification aide à vérifier la commande ; elle ne remplace pas son dossier.
Les recettes sont dans la référence webhooks · guide HMAC.
Lisez la réponse avant de réessayer
Lisez le code HTTP et le JSON. Les exemples suivants concernent NotPanel ; cette revue ne détermine pas le comportement HTTP des comptes concurrents.
NotPanel documente X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset. Les clés API d’un même compte partagent sa limite de requêtes. Consultez les références des erreurs et des limites avant de décider quoi réessayer, quand patienter ou quand demander à l’équipe d’examiner une requête.
Les fonctions NotPanel que vous pouvez vérifier
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: Les requêtes add habituelles fonctionnent sans nouveau champ et un payload identique du même compte est protégé pendant 60 secondes. request_id ou son alias idempotency_key reste facultatif pour un contrôle exact des retries ; request_id prévaut si les deux sont envoyés.
- Événements de statut signés: La référence décrit HMAC-SHA256 sur timestamp + point + corps brut, les headers exacts et les événements dans le corps ; les URL privées ou locales sont refusées.
- 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.
- Limites visibles: Les en-têtes de limite expliquent la fenêtre effective du compte ; changer de clé API ne crée pas un quota de compte distinct.
Chaque point peut être testé dans la référence publique avant de migrer un flux reseller.
Choisissez le contrat adapté au travail réel. Une intégration stable peut rester pertinente. Évaluez NotPanel lorsqu'une fonction documentée répond à un besoin précis, avant de déplacer le trafic.
Questions fréquentes
JustAnotherPanel possède-t-il une API reseller ?
Oui. La page v2 publique consultée le 2026-09-09 montre key et action pour services, add, status, refill, refill_status, cancel et balance. Les webhooks, l'idempotence, le catalogue d'erreurs HTTP et les headers de limite n'étaient pas documentés sur cette page invitée ; cette absence ne prouve pas qu'une fonction ne puisse exister ailleurs.
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.
Idempotence intégrée?
Les requêtes add habituelles fonctionnent sans nouveau champ et un payload identique du même compte est protégé pendant 60 secondes. request_id ou son alias idempotency_key reste facultatif pour un contrôle exact des retries ; request_id prévaut si les deux sont envoyés.
Puis-je pointer un client JAP existant vers NotPanel ?
La structure key + action est familière. Avant de changer l'URL, vérifiez le catalogue cible, les identifiants, champs, prix et états. Clés, identifiants de service et soldes ne se transfèrent pas entre panels. Chez NotPanel, l'annulation ordinaire exige un état Pending, avant envoi, dans les 15 premières secondes.
