Technik
Die SMM-Panel-API v2: der Branchenstandard
Zuletzt aktualisiert am von der Redaktion PanelCompare · 5 Min. Lesezeit
Was ist die SMM-Panel-API v2?
Sie ist ein einziger POST-Endpunkt, üblicherweise unter /api/v2, der einen Anfragetext im Format application/x-www-form-urlencoded entgegennimmt und JSON zurückgibt. Authentifiziert wird über einen Parameter key im Anfragetext, nicht über einen Header. Es gibt keine Versionsaushandlung, keine Signatur der Anfragen und keine Nonce (Spezifikation geprüft anhand von justanotherpanel.com/api, 6. September 2026).
Die Spezifikation stammt von den verbreitetsten Panel-Skripten und wurde so oft kopiert, dass sie heute der De-facto-Standard der Branche ist. Darauf beruht fast alles andere in diesem Markt: Ein Panel lässt sich an einem Nachmittag starten, indem man ein Skript auf die API eines Anbieters richtet. Deshalb gibt es Tausende Panels, und deshalb unterscheiden sie sich kaum.
Der Schlüssel ist ein langlebiges Bearer-Geheimnis
Weil der API-Schlüssel ohne Signatur, Nonce oder Zeitstempel im Anfragetext übertragen wird, sieht die Spezifikation weder Schutz vor Replay-Angriffen noch ein Ablaufdatum vor. Wer den Schlüssel hat, kann Ihr Guthaben ausgeben und jeden Link lesen, für den Sie bestellt haben. Erneuern Sie ihn, nachdem Sie ein Tool eines Drittanbieters angebunden haben.
Welche Aktionen stellt die API bereit?
| Aktion | Parameter | Rückgabe |
|---|---|---|
| services | key, action | Array der Katalogzeilen: service, name, type, category, rate, min, max, refill, cancel |
| add | key, action, service, link, dazu die Parameter des jeweiligen Bestelltyps | Die ID der neuen Bestellung |
| status | key, action, order | charge, start_count, status, remains, currency |
| status (mehrere) | key, action, orders (kommagetrennt, max. 100) | Ein Objekt mit der Bestell-ID als Schlüssel |
| refill | key, action, order (oder orders, kommagetrennt) | Eine Refill-ID oder ein Array aus Paaren von Bestell- und Refill-ID |
| refill_status | key, action, refill (oder refills, kommagetrennt) | Der Refill-Status |
| cancel | key, action, orders (kommagetrennt) | Stornoergebnis pro Bestellung |
| balance | key, action | balance und currency |
Quelle: Spezifikation der SMM Panel API v2, geprüft anhand von justanotherpanel.com/api, 6. September 2026.
Beachten Sie: Die maßgebliche Spezifikation kennt keine eigene Aktion multi_status. Den Status mehrerer Bestellungen liefert dieselbe Aktion status mit dem Parameter orders im Plural, begrenzt auf 100 IDs pro Anfrage – ein Detail, über das die meisten ersten Integrationen stolpern.
Wie sehen Anfrage und Antwort konkret aus?
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"
}Das Feld rate ist der Preis pro 1.000 in der Währung des Kontos, geliefert als Zeichenkette. Echte Kataloge umfassen 3.000–8.000 Zeilen, ein Aufruf von services liefert also eine einzige große Antwort statt einer seitenweisen.
Welche Fallen lassen erste Integrationen scheitern?
- Fehler kommen meist mit HTTP 200. Bei den meisten Panels liefert eine gescheiterte Anfrage 200 mit einem Fehlerobjekt im Antworttext, und manche beantworten einen ungültigen Schlüssel mit 401 und derselben JSON-Struktur. Auf den Statuscode ist also kein Verlass, und jeder Client muss den Antworttext auswerten, um Fehler zu erkennen.
- Zahlen kommen als Zeichenketten. rate, min, max, charge, start_count und remains stehen alle in Anführungszeichen; wer sie ohne Umwandlung numerisch vergleicht, bekommt stillschweigend falsche Ergebnisse.
- Der Status mehrerer Bestellungen ist der Parameter im Plural, keine eigene Aktion, und ist auf 100 IDs begrenzt.
- Die Drip-Feed-Menge gilt pro Lauf. Ein Aufruf von add mit runs=10 liefert und berechnet quantity × 10.
- Service-IDs gelten nur im jeweiligen Panel und können sich ändern. Ein Panel kann eine ID auf einen anderen Zulieferer umleiten, sodass gespeicherte IDs unbemerkt etwas anderes bedeuten.
- refill und cancel funktionieren nur, wo die Katalogzeile sie ausweist, und cancel meist nur, bevor die Lieferung beginnt.
Welche Parameter braucht welcher Bestelltyp?
Jeder Aufruf von add braucht einen service und einen link. Was sonst noch nötig ist, bestimmt das Feld type der Katalogzeile, und die Anforderungen lassen sich nicht erraten. Diese Tabelle ist die vollständige Liste.
| Bestelltyp | Zusätzliche Parameter |
|---|---|
| Default / Drip-feed | quantity, runs (optional), interval (optional, Minuten) |
| Custom Comments | comments (Liste, ein Eintrag pro Zeile) |
| Custom Comments Package | comments |
| Mentions (Nutzerliste / Hashtag / eigene Liste) | quantity, usernames, hashtags |
| Mentions Hashtag | quantity, hashtag (die zu erwähnenden Accounts werden aus dem Hashtag ausgelesen) |
| Mentions User Followers | quantity, username (die zu erwähnenden Accounts werden aus den Followern dieses Nutzers ausgelesen) |
| Mentions Media Likers | quantity, media (URL) |
| Comment Likes | quantity, username |
| Comment Replies | username, comments |
| Poll | quantity, answer_number |
| Subscriptions | username, min, max, posts (opt.), delay, expiry (opt.), old_posts (opt.) |
| Invites from Groups | quantity, groups (ein Eintrag pro Zeile) |
| Package | nur link; die Menge ist fest |
| Web Traffic | quantity, country, device, type_of_traffic, google_keyword oder referring_url |
Quelle: Spezifikation der SMM Panel API v2, geprüft anhand von justanotherpanel.com/api, 6. September 2026.
Wie sollten Sie gegen die API entwickeln?
- 1.Jede Antwort als untypisiert behandeln. Zuerst den Antworttext auswerten, auf einen Schlüssel error prüfen und dann numerische Zeichenketten ausdrücklich umwandeln.
- 2.Die Service-ID des Panels zusammen mit Ihrem eigenen Standard-Service speichern und den Katalog regelmäßig neu synchronisieren, damit eine umgeleitete ID erkannt und nicht einfach angenommen wird.
- 3.Statusabfragen mit dem Parameter orders im Plural bündeln, in Paketen zu 100, statt eine Anfrage pro Bestellung zu senden.
- 4.Partial als vollwertiges Ergebnis behandeln, nicht als Fehler. Es kommt mit einer Restmenge (remains) und einer automatischen Gutschrift aufs Guthaben.
- 5.Den Anfragetext nie protokollieren. Der API-Schlüssel steht darin.
- 6.Schlüssel regelmäßig erneuern und nach jeder Änderung an einer Integration eines Drittanbieters.
Was verrät die API über ein Panel?
Mehr als die Werbetexte. Ein Aufruf von /api/v2 ohne Schlüssel liefert eine gültige Fehlermeldung, wenn ein mit API v2 kompatibler Endpunkt existiert, und ein 404 widerlegt die Behauptung eines Panels, eine API zu haben. Das ist eine schnelle, objektive Prüfung, die jeder durchführen kann.
Sie ist auch der einzige skalierbare Weg, vergleichbare Preise zu sammeln. Die meisten Panels verstecken ihren Katalog hinter einer Registrierung und zeigen öffentlich nur Werbetexte, sodass das Auslesen öffentlicher Seiten nur einen kleinen Teil des Marktes abdeckt. Wer ein Konto anlegt und die Aktion services aufruft, erhält den gesamten Katalog als strukturiertes JSON in einer einzigen Anfrage. So baut PanelCompare seinen Preisindex auf.
Schnelle Antworten
Was ist die SMM-Panel-API v2?
Die SMM-Panel-API v2 ist ein einziger POST-Endpunkt, üblicherweise unter /api/v2, der formularkodierte Parameter entgegennimmt und JSON zurückgibt, mit den Aktionen services, add, status, refill, refill_status, cancel und balance. Fast jedes Panel setzt sie um, deshalb funktioniert ein Client bei Hunderten.
Wie authentifiziere ich mich bei der API eines SMM-Panels?
Mit einem Parameter key im Anfragetext. Es gibt keine Authentifizierung per Header, keine Signatur der Anfragen und keine Nonce. Der Schlüssel ist also ein langlebiges Bearer-Geheimnis und sollte nach jeder Änderung an einer Integration eines Drittanbieters erneuert werden.
Warum liefert die API bei Fehlern 200 zurück?
Weil die Spezifikation HTTP-Statuscodes nicht sinnvoll nutzt. Fehler kommen meist als HTTP 200 mit einem Fehlerobjekt im Antworttext zurück, und manche Panels antworten auf einen ungültigen Schlüssel mit 401 und demselben Antworttext. Deshalb muss jeder Client den Antworttext auswerten, um Fehler zu erkennen.
Wie frage ich den Status vieler Bestellungen auf einmal ab?
Mit derselben Aktion status und dem Parameter orders im Plural, der bis zu 100 kommagetrennte Bestell-IDs aufnimmt. Eine eigene Aktion multi_status gibt es in der maßgeblichen Spezifikation nicht.
Jede Zahl hier hat eine Quelle und ein Datum
Die Preise in diesem Markt ändern sich wöchentlich, eine Zahl ohne Erhebungsdatum ist also nur Dekoration. Wo dieser Ratgeber eine Zahl zitiert, nennt er die Quelle und das Prüfdatum. Ist eine davon falsch, sieht das Korrekturverfahren auf der Seite Über uns eine Antwort innerhalb von zwei Werktagen vor, und Korrekturen werden mit einem datierten Hinweis veröffentlicht, statt stillschweigend eingespielt zu werden.