API SMM-панели: как принимать заказы автоматически и стать поставщиком

API — это то, чем панель отличается от обычного интернет-магазина. Через него панель принимает заказы без участия человека, отдаёт их поставщику и возвращает статусы. И он же превращает вашу панель в поставщика для других: чужие панели начинают закупаться у вас автоматически, круглосуточно и без переписки в Telegram.

Коротко о том, что где лежит: эта статья объясняет, как API устроен и кому выдавать ключ, а готовый коммерческий ответ - панель, в которой оба API работают из коробки, - на странице SMM-панель с API.

Выдать ключ - это половина дела; вторая половина начинается, когда по нему приходит чужой скрипт с дублями заказов и опросом статусов в цикле. Что при этом ломается и какие проверки обязаны быть на сервере - в разборе про злоупотребление API панели.

Два конца одного API

Владелец панели работает сразу с двумя API, и путать их нельзя.

• API поставщика — вы клиент. Панель сама отправляет заказ дальше по цепочке, забирает статусы и следит за балансом. Это то, что называют автообработкой: заказ клиента уходит в работу за секунды, а не когда вы открыли админку.
• Ваш API — вы поставщик. Другие панели и сервисы подключаются к вам, вызывают ваши методы и перепродают ваши позиции у себя. Для них вы — обычный провайдер, ничем не отличающийся от того, у кого закупаетесь вы.

Второй конец интереснее с точки зрения денег. Реселлер, подключённый по API, приносит не разовую покупку, а поток заказов: у него свои клиенты, свой трафик и своя поддержка, а объём идёт через вас.

Точный список вызовов, их параметров и форм ответа - в отдельном справочнике: методы API SMM-панели. Эта статья про то, зачем и кому выдавать ключ, тот - про то, что именно придётся поддержать в коде.

Как устроен API SMM-панели

В этой нише сложился фактический стандарт, и почти все панели его повторяют — это удобно всем, потому что интеграция пишется один раз и подходит к десяткам панелей. Выглядит он так: одна точка входа, POST-запрос, ключ доступа в параметрах, нужное действие — в параметре action. Ответ — JSON.

• services — список позиций: идентификатор, название, категория, цена за 1000, минимальный и максимальный объём.
• add — создать заказ. Возвращает номер заказа в вашей панели.
• status и multistatus — статус одного заказа или сразу нескольких.
• refill — запрос доливки по выполненному заказу, если по позиции она доступна.
• balance — остаток средств на счёте реселлера.

Ключ — это и логин, и пароль одновременно: кто им владеет, тот тратит баланс. Поэтому ключ передаётся только по HTTPS, живёт на стороне сервера реселлера и меняется при любом подозрении.

Что передаётся в заказе — зависит от типа услуги

Самая частая ошибка в интеграциях: считать, что заказ — это всегда ссылка и количество. Для основной массы позиций так и есть, но у поставщиков есть услуги, которым нужен список комментариев, имя автора, набор хештегов или вообще не нужно количество — оно зашито в саму позицию. Если отправить не тот набор параметров, поставщик отклонит заказ, а деньги за него уже могут быть списаны у клиента.

Поэтому тип услуги стоит хранить вместе с позицией и строить форму заказа и документацию API из одного и того же справочника типов. Тогда клиент-реселлер видит в документации ровно те поля, которые панель реально примет, а позиции с неподдерживаемым типом просто не попадают в каталог.

Опрос статусов: где ломаются интеграции

Заказ создан — дальше его нужно довести до финального статуса. Здесь ломается больше интеграций, чем на создании.

• Слишком частый опрос. Дёргать status каждую секунду по каждому заказу — верный способ получить блокировку по лимиту запросов. Разумный интервал — минуты, а не секунды.
• Опрос по одному. Для тысячи активных заказов есть multistatus: один запрос вместо тысячи.
• Опрос завершённых. Заказ в финальном статусе больше не меняется — его можно не трогать вообще.
• Молчаливое проглатывание ошибок. Ответ с ошибкой — это тоже ответ: он должен попадать в лог и в уведомление, а не исчезать.

Отдельная тема — повторные отправки. Если запрос на создание заказа ушёл, а ответ не дошёл, наивная логика повторит его и создаст дубль. Спасает свой идентификатор на стороне отправителя и проверка перед повторной отправкой.

Как подключить реселлера к своей панели

Технически — выдать ключ. По делу — сначала договориться о трёх вещах: по каким ценам он закупается, что происходит при браке и как он пополняет баланс. Практика простая: реселлер работает с предоплаченного баланса, цены для него отдельные (обычно ниже витринных), а спорные заказы разбираются по номеру заказа в вашей панели, а не по скриншотам.

Полезно сразу дать ему тестовый доступ и минимальную сумму на балансе: интеграцию пишет разработчик, и ему нужно прогнать все методы, включая ошибочные сценарии. Чем меньше вопросов он задаст вам в переписке, тем быстрее пойдёт объём.

Что проверить перед выдачей ключа

• Цены и лимиты. Реселлер увидит ваш прайс целиком — убедитесь, что в нём нет позиций, которые вы продаёте себе в убыток.
• Минимальный объём. Через API легко насыпать сотню заказов по двадцать центов; минимальная сумма заказа экономит вашу поддержку.
• Отдельный ключ на каждого. Один общий ключ на всех невозможно ни отозвать, ни разобрать по логам.
• Логи запросов. Без них любой спор превращается в разговор о доверии.

Итог

API — это не «фича для технарей», а канал сбыта. Один подключённый реселлер часто даёт больше объёма, чем месяц рекламы, потому что приводит не клиента, а свой собственный поток клиентов. И начать можно без вложений: в SMMPanelRent заказы, которые панель выполняет через наш каталог, в тариф не идут вообще — панель остаётся бесплатной при любом объёме, а по сторонним поставщикам бесплатны первые сто заказов в месяц. То есть выстроить API-интеграции и посмотреть, сколько они принесут, можно раньше, чем появится первый платёж за аренду.