Техническое
Стандарт API SMM-панелей v2
Обновлено . Автор: Редакция PanelCompare. 5 мин чтения
Что такое API SMM-панели v2?
Это один POST-эндпоинт, по соглашению по адресу /api/v2, который принимает тело application/x-www-form-urlencoded и возвращает JSON. Аутентификация — параметр key в теле запроса, а не заголовок. Нет согласования версий, нет подписи запросов и нет nonce (спецификация сверена с justanotherpanel.com/api, 6 сентября 2026 г.).
Спецификация появилась в самых распространённых скриптах панелей и была скопирована так широко, что стала фактическим стандартом отрасли. Этот факт стоит почти за всем остальным на рынке: панель можно запустить за полдня, направив скрипт на API поставщика, — поэтому панелей тысячи и поэтому они так мало отличаются друг от друга.
Ключ — долгоживущий секрет
API-ключ передаётся в теле запроса без подписи, nonce или метки времени, поэтому в спецификации нет ни защиты от повторного использования, ни срока действия ключа. Любой, у кого есть ключ, может потратить ваш баланс и прочитать все ссылки, на которые вы делали заказы. Меняйте ключ после подключения любого стороннего инструмента.
Какие действия есть в API?
| Действие | Параметры | Что возвращает |
|---|---|---|
| services | key, action | Массив позиций каталога: service, name, type, category, rate, min, max, refill, cancel |
| add | key, action, service, link плюс параметры, зависящие от типа заказа | Номер нового заказа (id) |
| status | key, action, order | charge, start_count, status, remains, currency |
| status (несколько заказов) | key, action, orders (через запятую, не больше 100) | Объект, где ключи — номера заказов |
| refill | key, action, order (или orders через запятую) | Номер рефилла или массив пар «заказ — рефилл» |
| refill_status | key, action, refill (или refills через запятую) | Статус рефилла |
| cancel | key, action, orders (через запятую) | Результат отмены по каждому заказу |
| balance | key, action | balance и currency |
Источник: Спецификация SMM Panel API v2, сверено с justanotherpanel.com/api, 6 сентября 2026 г.
Обратите внимание: в канонической спецификации нет отдельного действия multi_status. Статус нескольких заказов — это то же действие status с параметром orders во множественном числе, не больше 100 номеров за запрос; на этой детали спотыкается большинство первых интеграций.
Как на самом деле выглядят запрос и ответ?
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"
}Поле rate — цена за 1000 в валюте аккаунта, возвращается строкой. В реальных каталогах 3000–8000 позиций, поэтому вызов services возвращает один большой ответ, а не постраничный.
На чём ломаются первые интеграции?
- Ошибки обычно возвращаются с кодом HTTP 200. На большинстве панелей неудачный запрос приходит как 200 с объектом ошибки в теле, а некоторые отвечают на неверный ключ кодом 401 с тем же JSON, поэтому на код ответа полагаться нельзя, и любой клиент должен разбирать тело, чтобы обнаружить сбой.
- Числа приходят строками. rate, min, max, charge, start_count и remains — всё это строки в кавычках; сравнение их как чисел без преобразования незаметно даёт неверный результат.
- Статус нескольких заказов — это параметр во множественном числе, а не отдельное действие, и не больше 100 номеров.
- Количество в drip-feed указывается на один повтор. Вызов add с runs=10 доставляет и списывает оплату за quantity × 10.
- Номера услуг локальны для панели и могут меняться. Панель может перенаправить номер на другого поставщика, так что сохранённые номера могут незаметно начать означать другое.
- refill и cancel работают только там, где позиция каталога их заявляет, а cancel — обычно только до начала доставки.
Какие параметры нужны каждому типу заказа?
Любому вызову add нужны service и link. Что ещё нужно, определяет поле type у позиции каталога, и угадать требования нельзя. Эта таблица — полный список.
| Тип заказа | Дополнительные параметры |
|---|---|
| Default / Drip-feed | quantity, runs (необязательно), interval (необязательно, в минутах) |
| Custom Comments | comments (список, по одному на строку) |
| Custom Comments Package | comments |
| Mentions (список пользователей / хештег / свой список) | quantity, usernames, hashtags |
| Mentions Hashtag | quantity, hashtag (аккаунты для упоминания собираются из хештега) |
| Mentions User Followers | quantity, username (аккаунты для упоминания собираются из подписчиков этого пользователя) |
| Mentions Media Likers | quantity, media (URL) |
| Comment Likes | quantity, username |
| Comment Replies | username, comments |
| Poll | quantity, answer_number |
| Subscriptions | username, min, max, posts (необяз.), delay, expiry (необяз.), old_posts (необяз.) |
| Invites from Groups | quantity, groups (по одной на строку) |
| Package | только link; количество фиксировано |
| Web Traffic | quantity, country, device, type_of_traffic, google_keyword или referring_url |
Источник: Спецификация SMM Panel API v2, сверено с justanotherpanel.com/api, 6 сентября 2026 г.
Как правильно строить интеграцию?
- 1.Считайте любой ответ нетипизированным. Сначала разберите тело, проверьте ключ error, затем явно преобразуйте числовые строки.
- 2.Храните номер услуги панели рядом со своей типовой услугой и синхронизируйте каталог по расписанию, чтобы перенаправленный номер обнаруживался, а не предполагался.
- 3.Опрашивайте статусы пачками через параметр orders, по 100 штук, а не одним запросом на заказ.
- 4.Обрабатывайте «Частично выполнен» (Partial) как полноценный исход, а не ошибку. Вместе с ним приходят остаток и автоматический возврат на баланс.
- 5.Никогда не записывайте тело запроса в логи. В нём API-ключ.
- 6.Меняйте ключи по графику и после каждого изменения в сторонних интеграциях.
Что API говорит о самой панели?
Больше, чем рекламные тексты. Запрос к /api/v2 без ключа возвращает корректный ответ с ошибкой, если эндпоинт, совместимый с API v2, существует, а ответ 404 опровергает заявление панели о наличии API. Это быстрая объективная проверка, доступная каждому.
Кроме того, это единственный масштабируемый способ собрать сопоставимые цены. Большинство панелей закрывают каталог регистрацией и публично показывают только рекламные тексты, поэтому парсинг открытых страниц охватывает меньшинство рынка. Регистрация аккаунта и вызов действия services возвращает весь каталог в виде структурированного JSON за один запрос — так PanelCompare и строит свой индекс цен.
Быстрые ответы
Что такое API SMM-панели v2?
Это один POST-эндпоинт, по соглашению по адресу /api/v2, который принимает параметры в форме form-encoded и возвращает JSON; действия — services, add, status, refill, refill_status, cancel и balance. Его реализует почти каждая панель, поэтому один клиент работает с сотнями панелей.
Как проходить аутентификацию в API SMM-панели?
Параметром key в теле запроса. Нет ни аутентификации через заголовок, ни подписи запросов, ни nonce, поэтому ключ — долгоживущий секрет, и его стоит менять после любого изменения в сторонних интеграциях.
Почему API возвращает 200 при ошибках?
Потому что спецификация не использует коды статуса HTTP по назначению. Ошибки обычно приходят с кодом HTTP 200 и объектом ошибки в теле, а некоторые панели при неверном ключе отвечают кодом 401 с тем же телом, поэтому любой клиент должен разбирать тело ответа, чтобы обнаружить сбой.
Как проверить статус многих заказов сразу?
Используйте то же действие status с параметром orders во множественном числе, в котором до 100 номеров заказов через запятую. Отдельного действия multi_status в канонической спецификации нет.
У каждой цифры здесь есть источник и дата
Цены на этом рынке меняются каждую неделю, поэтому число без даты — просто украшение. Где это руководство приводит цифру, оно называет источник и дату проверки. Если какая-то из них неверна, по процедуре исправлений со страницы «О нас» мы стараемся ответить в течение двух рабочих дней, а исправления публикуем с датированной пометкой, а не вносим молча.