Technique
L’API des panels SMM : le standard v2
Mis à jour le par La rédaction de PanelCompare, 6 min de lecture
Qu’est-ce que l’API v2 des panels SMM ?
C’est un point d’accès POST unique, placé par convention sur /api/v2, qui reçoit un corps application/x-www-form-urlencoded et renvoie du JSON. L’authentification passe par un paramètre key dans le corps, et non par un en-tête. Il n’y a ni négociation de version, ni signature des requêtes, ni nonce (spécification vérifiée sur justanotherpanel.com/api, le 6 septembre 2026).
La spécification vient des principaux scripts de panel et a été copiée si largement qu’elle est devenue le standard de fait du secteur. C’est le fait qui explique presque tout le reste de ce marché : on peut lancer un panel en un après-midi en branchant un script sur l’API d’un fournisseur, d’où les milliers de panels et le peu de choses qui les distinguent.
La clé est un secret au porteur de longue durée
Comme la clé API circule dans le corps de la requête sans signature, nonce ni horodatage, la spécification ne prévoit aucune protection contre la réutilisation et aucune expiration. Quiconque détient la clé peut dépenser votre solde et lire tous les liens sur lesquels vous avez commandé. Changez-la après avoir connecté un outil tiers.
Quelles actions l’API propose-t-elle ?
| Action | Paramètres | Renvoie |
|---|---|---|
| services | key, action | Un tableau de lignes du catalogue : service, name, type, category, rate, min, max, refill, cancel |
| add | key, action, service, link, plus les paramètres propres au type | L’id de la nouvelle commande |
| status | key, action, order | charge, start_count, status, remains, currency |
| status (multiple) | key, action, orders (séparés par des virgules, 100 au maximum) | Un objet indexé par id de commande |
| refill | key, action, order (ou orders, séparés par des virgules) | Un id de refill, ou un tableau de paires commande/refill |
| refill_status | key, action, refill (ou refills, séparés par des virgules) | Le statut du refill |
| cancel | key, action, orders (séparés par des virgules) | Le résultat de l’annulation pour chaque commande |
| balance | key, action | balance et currency |
Source : Spécification SMM Panel API v2, vérifiée sur justanotherpanel.com/api, le 6 septembre 2026.
Il n’existe pas d’action multi_status distincte dans la spécification de référence. Le statut de plusieurs commandes s’obtient avec la même action status et un paramètre orders au pluriel, limité à 100 ids par requête : un détail qui fait trébucher la plupart des premières intégrations.
À quoi ressemblent une requête et une réponse ?
POST /api/v2
Content-Type: application/x-www-form-urlencoded
key=YOUR_KEY&action=services
// 200 OK
[
{
"service": 1,
"name": "Followers",
"type": "Default",
"category": "First Category",
"rate": "0.90",
"min": "50",
"max": "10000",
"refill": true,
"cancel": true
}
]POST /api/v2
key=YOUR_KEY&action=add&service=1&link=https://example.com/p&quantity=1000
// 200 OK
{ "order": 23501 }
POST /api/v2
key=YOUR_KEY&action=status&order=23501
// 200 OK
{
"charge": "0.27819",
"start_count": "3572",
"status": "Partial",
"remains": "157",
"currency": "USD"
}Le champ rate est le prix pour 1 000 dans la devise du compte, renvoyé sous forme de chaîne. Les vrais catalogues comptent de 3 000 à 8 000 lignes : un appel services renvoie donc une seule grosse réponse, sans pagination.
Quels pièges font échouer les premières intégrations ?
- Les erreurs renvoient généralement HTTP 200. Sur la plupart des panels, une requête en échec revient en 200 avec un objet d’erreur dans le corps, et certains répondent à une clé invalide par un 401 avec le même JSON : on ne peut donc pas se fier au code de statut, et chaque client doit analyser le corps pour détecter l’échec.
- Les nombres arrivent sous forme de chaînes. rate, min, max, charge, start_count et remains sont tous des chaînes entre guillemets ; les comparer numériquement sans conversion donne des résultats faux, sans erreur visible.
- Le statut multiple passe par le paramètre au pluriel, pas par une action distincte, et il est plafonné à 100 ids.
- En drip-feed, la quantité vaut par passage. Un appel add avec runs=10 livre et facture la quantité × 10.
- Les ids de service sont propres à chaque panel et peuvent changer. Un panel peut rediriger un id vers un autre fournisseur, et des ids enregistrés peuvent discrètement se mettre à désigner autre chose.
- refill et cancel ne fonctionnent que si la ligne du catalogue les annonce, et cancel en général seulement avant le début de la livraison.
Quels paramètres chaque type de commande exige-t-il ?
Tout appel add exige un service et un lien. Le reste dépend du champ type de la ligne du catalogue, et les exigences ne se devinent pas. Ce tableau les donne toutes.
| Type de commande | Paramètres supplémentaires |
|---|---|
| Default / Drip-feed | quantity, runs (facultatif), interval (facultatif, en minutes) |
| Custom Comments | comments (liste, un commentaire par ligne) |
| Custom Comments Package | comments |
| Mentions (liste d’utilisateurs / hashtag / liste personnalisée) | quantity, usernames, hashtags |
| Mentions Hashtag | quantity, hashtag (les comptes à mentionner sont extraits du hashtag) |
| Mentions User Followers | quantity, username (les comptes à mentionner sont extraits des abonnés de cet utilisateur) |
| Mentions Media Likers | quantity, media (URL) |
| Comment Likes | quantity, username |
| Comment Replies | username, comments |
| Poll | quantity, answer_number |
| Subscriptions | username, min, max, posts (facult.), delay, expiry (facult.), old_posts (facult.) |
| Invites from Groups | quantity, groups (un par ligne) |
| Package | link seulement ; la quantité est fixe |
| Web Traffic | quantity, country, device, type_of_traffic, google_keyword ou referring_url |
Source : Spécification SMM Panel API v2, vérifiée sur justanotherpanel.com/api, le 6 septembre 2026.
Comment développer sur cette API ?
- 1.Traitez chaque réponse comme non typée. Analysez d’abord le corps, cherchez une clé error, puis convertissez explicitement les chaînes numériques.
- 2.Enregistrez l’id de service du panel à côté de votre propre service de référence, et resynchronisez le catalogue à intervalles réguliers pour détecter un id redirigé au lieu de le supposer inchangé.
- 3.Regroupez l’interrogation des statuts avec le paramètre orders au pluriel, par lots de 100, plutôt qu’une requête par commande.
- 4.Traitez Partial comme un résultat à part entière, pas comme une erreur. Il s’accompagne d’une quantité restante (remains) et d’un crédit automatique sur le solde.
- 5.N’enregistrez jamais le corps des requêtes dans vos journaux. La clé API s’y trouve.
- 6.Changez les clés à intervalles réguliers et après chaque modification d’une intégration tierce.
Que révèle l’API sur un panel ?
Plus que ses textes commerciaux. Appeler /api/v2 sans clé renvoie une réponse d’erreur valide si un point d’accès compatible API v2 existe, et une erreur 404 dément l’API annoncée par le panel : une vérification rapide et objective, à la portée de tous.
C’est aussi le seul moyen, à grande échelle, de recueillir des prix comparables. La plupart des panels réservent leur catalogue aux inscrits et ne publient que des textes commerciaux : extraire les pages publiques ne couvre qu’une minorité du marché. Créer un compte et appeler l’action services renvoie tout le catalogue en JSON structuré, en une requête : c’est ainsi que PanelCompare construit son indice des prix.
Réponses rapides
Qu’est-ce que l’API v2 des panels SMM ?
Un point d’accès POST unique, placé par convention sur /api/v2, qui reçoit des paramètres encodés comme un formulaire et renvoie du JSON, avec les actions services, add, status, refill, refill_status, cancel et balance. Presque tous les panels l’implémentent : un même client fonctionne donc sur des centaines de panels.
Comment s’authentifier sur l’API d’un panel SMM ?
Avec un paramètre key dans le corps de la requête. Il n’y a ni authentification par en-tête, ni signature des requêtes, ni nonce : la clé est un secret au porteur de longue durée, à changer après toute modification d’une intégration tierce.
Pourquoi l’API renvoie-t-elle 200 en cas d’erreur ?
Parce que la spécification n’utilise pas les codes de statut HTTP de façon significative. Les échecs reviennent généralement en HTTP 200 avec un objet d’erreur dans le corps, et certains panels renvoient un 401 avec le même corps pour une clé invalide : chaque client doit donc analyser le corps de la réponse pour détecter un échec.
Comment vérifier le statut de nombreuses commandes à la fois ?
Utilisez la même action status avec un paramètre orders au pluriel contenant jusqu’à 100 ids de commande séparés par des virgules. La spécification de référence ne comporte pas d’action multi_status distincte.
Chaque chiffre ici est sourcé et daté
Sur ce marché, les prix bougent chaque semaine : un chiffre sans date de relevé n’est qu’un décor. Quand ce guide cite un chiffre, il en donne la source et la date de vérification. Si l’un d’eux est faux, la procédure de correction décrite sur la page À propos prévoit une réponse sous deux jours ouvrés, et les corrections sont publiées avec une note datée plutôt que glissées en silence.