Проверка API SMM-панели

Как выглядит запрос к API SMM-панели?

Рынок работает на нескольких скриптах панелей, поэтому запросы почти одинаковы: один POST-адрес, поля формы, ответ в JSON. Ключ определяет аккаунт, действие задаёт операцию, остальные поля — аргументы действия. Почти везде есть действия services, balance, add, status и refill.

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

Частые вопросы

Этот инструмент отправляет мой API-ключ на ваши серверы?

Нет. Запрос отправляет ваш браузер напрямую на адрес панели. За этой страницей нет ни обработчика, ни прокси, ни логов. Это можно проверить во вкладке «Сеть» инструментов разработчика: там будет ровно один запрос — на домен самой панели. API-ключ панели позволяет тратить пополненный баланс, и сайту-сравнению незачем держать его у себя даже на время передачи.

Почему запрос падает с сетевой ошибкой?

Почти всегда из-за CORS. API панелей рассчитаны на запросы между серверами и не отправляют заголовок Access-Control-Allow-Origin, без которого браузер не отдаст странице ответ с другого домена, — поэтому браузер отбрасывает ответ, хотя сам запрос, как правило, дошёл. Инструмент это распознаёт и даёт эквивалентную команду curl, которую можно запустить в своём терминале, где политика CORS не действует.

Что общего у API разных панелей?

Больше, чем кажется: рынок работает на небольшом числе скриптов панелей. Типичная схема — один POST-адрес, который принимает ключ, действие и параметры действия в виде полей формы и возвращает JSON. Обычные действия — services, balance, add, status и refill. Между панелями никогда не переносятся ID услуг: у каждой панели свои, поэтому интеграция, где они зашиты в код, ломается при переезде.

Безопасно ли проверять действие add?

Оно оформляет реальный заказ и тратит реальный баланс, поэтому относитесь к нему как к настоящей операции. Берите минимальное количество, которое допускает услуга, и ссылку, которой вы управляете, а потом проверьте заказ действием status, а не считайте, что заказ прошёл, раз вызов вернул 200: некоторые панели отвечают кодом 200 со строкой ошибки в теле.