VPN через API: автоматизация выдачи

Когда нужна автоматизация

В самом начале ручная выдача — это нормально. Пришёл клиент, вы зашли в кабинет, заказали сервер, выпустили конфиг, отправили его в чат. Пока продаж немного, такой темп держать легко, и разбираться с кодом просто незачем — об этом мы подробно писали в гайде «Как стать реселлером VPN».

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

API решает ровно это. Ваш бот или сайт сам оформляет заказ, выпускает ключ и отдаёт его клиенту в момент оплаты — без вас. Вы перестаёте быть оператором и занимаетесь продажами и маркетингом.

Что умеет API

Партнёрский API покрывает весь жизненный цикл клиента — от сервера до продления. Основные операции:

• Заказ сервера. POST /servers — оформляет VPS нужного тарифа и локации. В ответ приходит идентификатор сервера и его статус; когда он готов — прилетает вебхук.
• Выпуск конфига / ключа. POST /configs — создаёт VPN-конфиг на сервере с нужным протоколом, квотой по трафику и лимитом устройств. Возвращает готовый файл или ссылку, которую сразу можно отдать клиенту.
• Продление. POST /configs/{id}/renew — продлевает срок ключа или сервера. Именно эту операцию чаще всего и автоматизируют первой: продлений всегда больше, чем новых продаж.
• Вебхуки о событиях. Вместо того чтобы опрашивать API в цикле, вы подписываетесь на события и получаете их сами: server.ready — сервер поднялся и готов к выпуску конфигов; config.created — ключ выпущен; deposit.paid — баланс пополнен. Ваш обработчик реагирует мгновенно.

Python SDK и пример

Дёргать REST можно на любом языке — это обычные HTTP-запросы с API-ключом в заголовке. Но для Python есть готовый SDK, который берёт на себя авторизацию, повторы и разбор ответов. Ставится одной командой:

• Установка: pip install sova-partner
• Заказ сервера: client.create_server(plan="s1", region="nl") — вернёт объект сервера с его id и статусом.
• Выпуск конфига: client.issue_config(server_id, protocol="wg", devices=1) — вернёт готовый ключ, который остаётся отправить клиенту.

Логика в коде выглядит линейно: дождались события server.ready по вебхуку, вызвали issue_config, положили конфиг в ответ клиенту. Ключ авторизации задаётся один раз при инициализации клиента, дальше SDK сам подставляет его в каждый запрос. Разбираться, дороже ли это своих VPS, не нужно — экономику мы сравнивали в статье «Агрегатор против своих VPS».

Идемпотентность и песочница

Два механизма, которые превращают «скрипт на коленке» в надёжную интеграцию.

Идемпотентность. Сеть ненадёжна: запрос может уйти повторно из-за таймаута, а вы не будете знать, дошёл ли первый. Чтобы повтор не обернулся вторым сервером и двойным списанием, вы передаёте ключ идемпотентности — уникальный идентификатор операции. Если запрос с тем же ключом придёт снова, API вернёт результат первого вызова, а новый заказ не создаст. Заказ гарантированно не задвоится, даже если ваш код перезапустился в середине.

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

Интеграция с ботом и CRM

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

• Телеграм-бот. Клиент нажал «Купить» и оплатил — бот ловит платёж, вызывает issue_config и присылает конфиг прямо в чат. Самый частый сценарий у реселлеров.
• Сайт или личный кабинет. После оплаты бэкенд заказывает сервер и выпускает ключ, а клиент видит его на странице заказа.
• CRM и биллинг. Вебхук deposit.paid обновляет статус в вашей системе; продления запускаются по расписанию через renew, без ручных действий.

Во всех случаях схема одна: ваш код принимает оплату, зовёт API на выпуск и отдаёт результат клиенту. Всё, что раньше делали руками, теперь делает обработчик события.

Когда переходить на API

Не торопитесь автоматизировать с первого дня — сначала убедитесь, что продажи идут. Практическое правило: пока выдача занимает меньше часа в день, хватит и кабинета. Как только рутина начинает съедать время, которое стоило бы тратить на привлечение, — пора подключать API. Обычно это происходит на десятках активных клиентов; посчитать, при каком обороте это окупается, помогает разбор «Сколько можно заработать на VPN».

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