Продажа VPN через API: как продавать VPN на своём сайте, в приложении или своём боте

Продажа VPN через API — это схема, в которой ваш сайт, приложение или собственный бот сам показывает тарифы, выставляет клиенту счёт и после оплаты получает готовую ссылку подписки. Серверы, приём оплаты и выдачу доступа обслуживает платформа, а витрина, общение с клиентом и наценка остаются вам. На VARGO VPN API подключается без депозита и абонентской платы, ключ выпускается в кабинете партнёра.

Ниже — чем API отличается от готового бота, что умеет VPN API платформы VARGO по документации, как пройти путь от ключа до первой оплаты, как устроены деньги и что проверить перед запуском. Методы названы словами, а примеры запросов с ответами лежат в документации API.

VPN API: какое API для продажи VPN вам нужно

По запросу «VPN API» ищут три разные вещи, и их стоит различать до начала работы.

Что называют VPN API	Что оно делает	Кому подходит
API определения VPN по IP-адресу	Сообщает, заходит ли посетитель через VPN или прокси	Сайтам и системам защиты от мошенничества; к продаже VPN отношения не имеет
API своей VPN-панели или сервера	Заводит и удаляет пользователей на ваших серверах, отдаёт конфиги	Тем, кто сам арендует серверы и держит панель; тарифы, оплату и продления пишете вы
API платформы для продажи VPN	Отдаёт тарифы, выставляет счёт, выдаёт подписку и ссылки подключения	Тем, кто хочет продавать VPN под своим брендом без своих серверов и платёжной системы

Эта статья — о третьем варианте. Если вам ближе второй, начните с обзора панелей для VPN-сервиса: там видно, что придётся держать самому. Если вы ещё выбираете модель целиком, сравнение всех путей запуска есть в руководстве «Как создать свой VPN-сервис».

Продажа VPN через API или через бота: что выбрать

На VARGO продавать можно двумя способами, и оба работают на одних тарифах платформы: готовым Telegram-ботом под вашим брендом или через API из своего продукта. Разница — в том, кто рисует экраны и кто поддерживает код.

	Готовый бот на платформе	Продажа через API
Запуск	Без кода: подключили бота, оформили и продаёте	Нужны ваш сервер и разработчик
Где покупает клиент	В Telegram-боте и мини-приложении под вашим брендом	На вашем сайте, в приложении, своём боте или продукте
Экраны покупки	Готовые; вы задаёте название, описание, аватар, цвет и стартовый экран	Ваши: свой дизайн и своя логика
Приём оплаты	Платформа	Платформа: клиент платит по ссылке из счёта
Выдача и продление подписки	Платформа	Платформа, по вашему счёту
Напоминания о продлении	Бот пишет клиентам сам	Вы, по событиям вебхуков
Наценка	На странице бота «Цены», у каждого бота своя	Своя у API, от 0 до 1000 %
Депозит и абонентская плата	Нет	Нет
Кто поддерживает код витрины	Платформа	Вы

Когда выбирать API

• У вас уже есть продукт с аудиторией — сайт, приложение, сервис, сообщество или собственный бот, — и VPN должен стать в нём ещё одной услугой под вашим названием.
• Нужен свой сценарий покупки и свой дизайн, которые не укладываются в готового бота.
• Ваши клиенты привыкли покупать на сайте или в приложении, а не в Telegram.
• Есть разработчик, который напишет интеграцию и будет её поддерживать.

Когда лучше начать с бота

• Нет разработчика или своего сервера.
• Аудитория живёт в Telegram: канал, чат, сообщество.
• Хочется проверить спрос до того, как вкладываться в разработку.

Готовый бот и его отличия от самописных решений разобраны в статье «Бот для продажи VPN», запуск по шагам — в материале «Как создать VPN-бота в Telegram». Каналы друг друга не исключают: бот и API живут в одном кабинете партнёра, и наценка с обоих копится на балансе.

Что берёт на себя платформа, а что остаётся вам

Платформа	Вы
Серверы и выдача доступа	Экраны и общение с клиентом
Приём оплаты на своей странице	Название сервиса и ссылка поддержки
VPN-приложения и ссылки на установку	Наценка от 0 до 1000 %
Пользовательское соглашение и политика для клиента	Привлечение клиентов

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

Что умеет VPN API платформы VARGO

VARGO Partner API отдаёт готовым всё, что клиент видит у себя: тарифы и оплату, статус и срок подписки, подключение и устройства. Каждый экран клиента собирается одним запросом, ответы готовы к показу.

Экран клиента	Запрос API
Тарифы и цены	GET /plans
Оплата подписки или продления	POST /payments, в ответе ссылка на оплату payment_url
Подписка: активна ли, до какого числа, сколько дней осталось	GET /clients/{client_id}
Кнопка «Открыть в приложении» и QR-код	тот же ответ, блок connect
Устройства: сколько подключено и из скольких	GET /clients/{client_id}/devices
Отключить устройство	DELETE /clients/{client_id}/devices/{device_id}
Докупить устройства	POST /payments с назначением devices
Пробный период	POST /clients/{client_id}/trial
Новая ссылка подписки вместо старой	POST /clients/{client_id}/rotate-link
Где скачать VPN-приложение	GET /apps
Соглашение и политика	GET /documents

Общие правила API:

Параметр	Как устроено
Базовый адрес	https://api.vargopartners.com/api/partner/v1
Формат	REST, JSON, UTF-8
Авторизация	ключ партнёра vgo_live_… в заголовке Authorization (Bearer) на каждом запросе
Деньги	строки в рублях с двумя знаками после точки, рядом валюта RUB
Даты	ISO-8601, UTC
Язык текстов	заголовок Accept-Language: ru или en, без него — английский
Ошибки	единый конверт с полями code, message и fields
События	вебхуки на ваш сервер
Схема	OpenAPI, открыта без ключа

Ключ и авторизация

Ключ выпускается в кабинете партнёра, раздел «API». Значение показывается один раз, а платформа хранит только его хеш, поэтому сохраните ключ на сервере сразу. Ключ у аккаунта один: чтобы заменить его, отзовите прежний и выпустите новый — пока новый не встал на сервер, запросы получают отказ 401. Неверный, отозванный ключ, выключенный доступ к API и закрытый платформой аккаунт отвечают одинаково — 401 UNAUTHORIZED, так что по ответу нельзя понять, существовал ли ключ.

Первая проверка ключа — запрос GET /account: в ответе название сервиса, наценка, ссылка поддержки и включён ли пробный период.

Аккаунт, тарифы, способы оплаты и документы

• PATCH /account меняет только переданные поля: название сервиса brand_name (его видят клиенты в документах и в VPN-приложении, по умолчанию — VARGO), наценку markup_percent и ссылку поддержки support_link, которая открывается из VPN-приложения клиента. Ссылка — только https, наценка — от 0 до 1000; иначе ответ 422 VALIDATION_ERROR.
• GET /plans отдаёт тарифы и доп. устройства с тремя суммами: price — цена для клиента, platform_price — часть платформы, partner_share — ваша наценка в рублях. Номер тарифа plan_id отсюда передаётся в счёт.
• GET /payment-methods — способы оплаты, доступные клиенту прямо сейчас. Список меняется, поэтому его перечитывают перед показом, а не хранят у себя. Названия способов всегда на русском.
• GET /documents — ссылки на пользовательское соглашение и политику конфиденциальности под названием вашего сервиса. Страницы открываются без ключа, текст на них обновляет платформа, хранить копию у себя не нужно.

Счёт: подписка, продление и дополнительные устройства

Главный запрос продажи — POST /payments. В теле — ваш client_id, назначение счёта (subscription с номером тарифа или devices с числом устройств), способ оплаты и, по желанию, return_url — адрес, куда клиент вернётся со страницы оплаты. Клиента заранее заводить не нужно: если его нет, он появится с первым счётом. В ответе — номер счёта payment_id, сумма, доля платформы, ваша доля и ссылка payment_url, которую вы отдаёте клиенту.

• Продление — тот же POST /payments на тот же client_id. Срок прибавляется к текущему, ссылка подписки не меняется, переподключать ничего не нужно. Если подписка уже истекла, новый срок идёт с момента оплаты.
• Доп. устройства — счёт с назначением devices. Нужна действующая подписка; больше максимума на клиента не купить; на тарифе без ограничения устройств такой счёт не выставится.
• Заголовок Idempotency-Key на этом запросе обязателен — о нём ниже.

Статус счёта	Что значит	Что делать
pending	Ждёт оплаты, ссылка действует	Ждать событие об оплате или опрашивать счёт, пока клиент на странице оплаты
succeeded	Оплачен, доступ выдан	Показать клиенту подключение
expired	Не оплачен в срок или банк отказал — но это не окончательно	Предложить новый счёт; поздняя оплата по старому всё равно пройдёт
failed	Банк вернул клиенту деньги за уже оплаченный счёт	Перечитать клиента, прежде чем выдавать что-то у себя

На оплату у клиента 30 минут. Срок в поле expires_at — ориентир: если сервис оплаты счёт не отменил, статус меняется в течение часа после срока.

Клиент и подключение

Клиент определяется вашим идентификатором client_id: номер пользователя в вашей базе, id в боте — что угодно, что не меняется. Допустимы 1–128 символов: латиница, цифры и знаки . _ : @ + -, регистр различается. Идентификатор уникален внутри вашего аккаунта.

GET /clients/{client_id} отдаёт всё о клиенте: статус и срок подписки, сколько дней осталось, ссылку подписки и готовые ссылки подключения. До первого счёта или пробного периода клиента нет — ответ 404.

Статус подписки	Что значит
active	Действует; у пробной подписки стоит признак is_trial
expired	Срок вышел; продление возобновляет подписку, ссылка та же
suspended	Срок идёт, но доступ приостановлен платформой
подписки нет	Подписки у клиента не было ни разу

Пробная подписка, которая истекла без оплаты, сохраняет признак is_trial — такому клиенту стоит предложить тариф.

Для экрана подключения у каждого приложения в блоке connect уже собраны три вещи: connect_url — https-страница для кнопки «Открыть в приложении» (Telegram и браузеры не открывают ссылки приложений напрямую), qr_payload — строка для QR-кода на другом устройстве и признак, принимает ли приложение ссылку подписки, вставленную вручную. Ссылки на установку самих приложений и рекомендованное приложение отдаёт GET /apps. Список всех ваших клиентов — GET /clients: постранично, свежие первыми, с фильтром по статусу подписки.

Устройства и перевыпуск ссылки

• GET …/devices — подключённые устройства с платформой и моделью, сколько подключено и лимит. Пустой список всегда значит «устройств нет»; если платформа не ответила, придёт 503, а не пустой список.
• DELETE …/devices/{device_id} отключает устройство и освобождает место. Действие необратимо: вернуть устройство можно, только подключив его заново.
• POST …/rotate-link — новая ссылка подписки, если старая утекла или клиент передал её посторонним. Старая перестаёт работать сразу на всех устройствах, клиент добавляет подписку в приложение заново. Не чаще раза в час на клиента и только при действующей подписке.

Пробный период

POST /clients/{client_id}/trial выдаёт пробный период — настоящий доступ со ссылкой подписки. Он включён по умолчанию, выдаётся один раз на клиента и заводит клиента, если его ещё нет. Если подписка у клиента уже была, ответ 409 TRIAL_ALREADY_USED; заранее это видно по признаку trial_available у клиента. Если платформа выключила пробный период вашему аккаунту — 403 TRIAL_DISABLED. Ответ 503 значит, что пробный период не выдан и запрос можно повторить.

Вебхуки: оплата и конец подписки

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

Событие	Когда приходит
payment.succeeded	Счёт оплачен, доступ выдан; в событии — счёт и клиент со ссылкой подписки
payment.expired	Счёт истёк неоплаченным — удобный повод напомнить о брошенной оплате
subscription.expiring	До конца подписки 72 или 24 часа; у пробной — только 24
subscription.expired	Срок подписки вышел

Как подключить и принимать события:

1. В кабинете, раздел «API», блок «Адреса вебхуков», добавьте адрес. Подходит только https на порту 443 с доменным именем, IP-адрес не принимается. Адресов может быть до 10, у каждого свой набор событий.
2. Сохраните на сервере секрет адреса (whsec_…). Им проверяется подпись: адрес публичный, и отправить на него запрос может кто угодно.
3. Отправьте тест из меню адреса — придёт событие webhook.test, а кабинет покажет код ответа вашего сервера.
4. Проверяйте подпись по открытому стандарту Standard Webhooks готовой библиотекой: они есть для Python, Node.js, Go, PHP, Ruby, Java, C# и Rust. В проверку передаётся сырое тело запроса, до разбора JSON, а часы сервера должны быть точными: запрос старше 5 минут отклоняется.
5. Отсекайте дубли по заголовку webhook-id — он одинаков во всех повторах одного события.
6. Отвечайте кодом 2xx не дольше чем за 15 секунд, а долгую работу делайте после ответа.

Если ответа нет, событие приходит снова: всего 10 попыток, последняя — примерно через трое суток. Адрес, который пять суток подряд не принял ни одного события, отключается сам, и об этом приходит сообщение в бот платформы. Недошедшие события после починки сервера отправляются заново пунктом «Повторить неудачные» — за сутки, 3, 7 или 30 дней. События, случившиеся, пока адрес был выключен, не вернутся, поэтому на время работ на сервере адрес лучше не выключать.

Вебхук может прийти дважды, опоздать или прийти не по порядку. Источник истины — запросы GET: перед тем как выдать клиенту что-то у себя, перечитайте счёт или клиента. События приходят только по клиентам и счетам, заведённым через API.

Идемпотентность: повтор без второго счёта

Сеть рвётся: запрос на счёт мог дойти, а ответ — потеряться. Чтобы повтор не выставил клиенту второй счёт, POST /payments принимается только с заголовком Idempotency-Key. Удобнее всего передавать номер заказа в вашей системе; длина — до 200 символов, ключ уникален внутри вашего аккаунта.

Что пришло	Ответ API
Новый ключ	201 — счёт выставлен
Тот же ключ и те же поля	200 — тот же счёт с пометкой replayed
Тот же ключ, другие поля	409 IDEMPOTENCY_KEY_REUSE — нужен новый ключ
Тот же ключ, первый запрос ещё идёт	409 OPERATION_IN_PROGRESS — повторить тем же ключом через пару секунд
Нет ключа	400 IDEMPOTENCY_KEY_REQUIRED

«Те же поля» — это client_id, назначение, тариф, число устройств, способ оплаты и return_url. После таймаута, обрыва соединения или ответа 5xx повторяйте счёт с тем же ключом: новый ключ на повторе — это новый счёт.

Ошибки, лимиты и версии

Любая ошибка приходит в одном конверте: машиночитаемый code, текст message для логов и fields с причинами у ошибок валидации. Ветвиться нужно по code, а не по статусу и не по тексту; message клиенту не показывают — формулировки меняются. Незнакомый код трактуйте как обычный отказ: список пополняется без смены версии.

Лимит	Значение
Все запросы аккаунта	600 в минуту
Выставление счетов	60 в минуту
Перевыпуск ссылки	раз в час на клиента

При превышении приходит 429, пауза до повтора — в заголовке Retry-After. Версия зашита в путь (/v1): внутри неё появляются новые поля, коды ошибок и типы событий, и интеграция не должна на них ломаться. Удаление и переименование полей — только в новой версии.

Есть ли песочница

Тестового режима нет: каждый ключ боевой, счёт настоящий, пробный период выдаёт настоящий доступ. Неоплаченный счёт ничего не стоит — он просто истекает. Интеграцию проверяют на себе: выставляют счёт своему client_id и оплачивают его.

VPN API для сайта: пошаговая схема интеграции

Схема одна для сайта, мини-приложения и мобильного приложения: клиент → ваш интерфейс → ваш сервер → VARGO Partner API. Ключ живёт только на сервере, интерфейс ходит к вашему серверу, а сервер — к API.

1. Подключитесь партнёром. Откройте @vargo_robot — откроется кабинет партнёра. Перед выпуском первого ключа вы подтверждаете согласие с условиями платформы отдельной кнопкой.
2. Выпустите ключ. Раздел «API» в кабинете, значение сразу в переменную окружения или хранилище секретов на сервере.
3. Настройте витрину. Проверьте ключ запросом GET /account и задайте через PATCH /account название сервиса, наценку и ссылку поддержки. Пока наценку не задали, она равна нулю и продажа идёт по цене платформы без вашего заработка.
4. Покажите тарифы. Возьмите цены из GET /plans и способы оплаты из GET /payment-methods. Рядом с кнопкой «Оплатить» поставьте ссылки на соглашение и политику из GET /documents.
5. Выставьте счёт. Клиент выбрал тариф — ваш сервер вызывает POST /payments с его client_id, тарифом, способом оплаты, return_url и номером заказа в Idempotency-Key. Сохраните payment_id у заказа.
6. Отдайте ссылку на оплату. Кнопка оплаты открывает payment_url. Клиент платит на странице оплаты платформы; если передан return_url, он вернётся на ваш адрес и после оплаты, и после отказа — на этой странице перечитайте счёт.
7. Дождитесь оплаты. Событие payment.succeeded придёт само, если подключены вебхуки; без них опрашивайте GET /payments/{payment_id} раз в несколько секунд, пока клиент на странице оплаты. Доступ платформа выдаёт сама — вызывать ничего не нужно.
8. Покажите подключение. Кнопка «Открыть в приложении» ведёт на connect_url, QR-код строится из qr_payload, ссылки на установку приложений — из GET /apps.
9. Ведите клиента дальше. Продление и докупка устройств — тот же POST /payments на того же клиента, напоминания — по событию subscription.expiring.

Что хранить у себя, чтобы интеграция не путалась:

Ваши данные	Что из API к ним привязать
Пользователь	client_id — один и тот же навсегда
Заказ	номер заказа как Idempotency-Key и payment_id счёта
Обработанные события	webhook-id, чтобы не обработать повтор дважды
Секреты	ключ vgo_live_… и секрет вебхука, только на сервере

Если витрина — мини-приложение в Telegram, клиента узнают на сервере по подписанным данным запуска (initData) и передают в API его id как client_id. Кнопки оплаты и подключения в мини-приложении — обычные https-ссылки payment_url и connect_url.

Деньги и наценка при продаже через API

Цена для клиента — цена платформы плюс ваша наценка. Тарифы у платформы одни на все каналы продаж, а наценка у API своя и цены ваших Telegram-ботов не меняет. Деньги идут так:

1. Ваш сервер выставляет счёт и отдаёт клиенту ссылку на оплату.
2. Клиент платит платформе на странице оплаты.
3. Платформа выдаёт доступ сама — ссылка подписки приходит в ответе API и в вебхуке.
4. Ваша наценка ложится на баланс партнёра. Баланс и вывод — в кабинете, раздел «Финансы».

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

Пример расчёта по прайсу платформы при наценке 100 %:

Тариф	Цена платформы	Клиент платит	Ваша наценка
1 месяц	150 ₽	300 ₽	150 ₽
3 месяца	429 ₽	858 ₽	429 ₽
6 месяцев	749 ₽	1 498 ₽	749 ₽
12 месяцев	1 199 ₽	2 398 ₽	1 199 ₽
Навсегда	1 990 ₽	3 980 ₽	1 990 ₽
Доп. устройство	99 ₽	198 ₽	99 ₽

Это иллюстрация, а не прогноз дохода. В интеграции все суммы берите из ответа GET /plans: с наценкой цена для клиента округляется до целого рубля и не бывает ниже цены платформы, поэтому ваша доля может немного отличаться от точного процента, а собственный пересчёт разойдётся со счётом.

Что ещё важно о деньгах:

• наценку меняет PATCH /account: новые цены GET /plans отдаёт сразу, а уже выставленные счета остаются по прежней цене;
• наценка действует и на дополнительные устройства;
• если банк вернул клиенту деньги, счёт становится failed, а наценка по этому платежу списывается с баланса;
• заявку на вывод вы подаёте в «Финансах» с суммой и реквизитами; её рассматривают в течение 3 рабочих дней, выплата — в течение 3 рабочих дней после одобрения;
• искусственный оборот — самооплаты и оплаты аффилированных лиц ради выплаты — правила запрещают, и по таким платежам в выплате могут отказать.

Как наценка складывается в доход на продлениях, разобрано в статье «Как заработать на VPN». Прайс платформы целиком — на главной странице, формулы — в разделе документации «Тарифы и деньги».

Свой сайт для VPN-сервиса: что показать клиенту

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

• До оплаты: тарифы и цены ровно из GET /plans, способы оплаты, ссылки на соглашение и политику рядом с кнопкой «Оплатить», пробный период, если он включён.
• Оплата: кнопка, ведущая на payment_url, и страница возврата, которая перечитывает счёт.
• После оплаты: выбор приложения со ссылками на установку, кнопка «Открыть в приложении», QR-код для второго устройства, ссылка подписки для ручной вставки.
• Кабинет клиента: статус и срок подписки, сколько дней осталось, кнопка продления, список устройств с отключением лишнего и докупкой мест, перевыпуск ссылки.
• Поддержка: ваша ссылка — та же, что задана в support_link, чтобы клиент попадал к вам и из VPN-приложения.

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

Безопасность: ключ API, вебхуки и ссылки подписки

• Ключ — только на сервере. В переменных окружения или хранилище секретов, не в репозитории. В код сайта, мини-приложения или мобильного приложения он не попадает никогда: ключ в клиентском коде достанется любому, кто его откроет, вместе со всеми вашими клиентами.
• Утечка ключа. Сразу отзовите его в разделе «API» и выпустите новый.
• Подпись вебхуков. Без проверки подписи ваш обработчик примет поддельное событие об оплате. Проверяйте сырое тело и следите за точностью часов сервера.
• Секрет вебхука. Его можно перевыпустить в кабинете: следующие 24 часа события подписываются двумя секретами, новым и прежним, — за эти сутки замените секрет на сервере.
• Решения — по API, а не по событию. Перед выдачей бонуса или доступа у себя перечитайте счёт: вебхук может опоздать или прийти повторно.
• Утёкшая ссылка подписки. Перевыпуск ссылки отключает старую сразу на всех устройствах — дайте клиенту эту кнопку в кабинете.

Частые ошибки при продаже VPN через API

• Счёт без Idempotency-Key — запрос не пройдёт, а повтор с новым ключом после таймаута выставит второй счёт.
• Ответ 200 на POST /payments принимают за ошибку. И 201, и 200 — успех: 200 значит, что это повтор того же счёта.
• Статус expired считают окончательным. Поздняя оплата всё равно проходит и переводит счёт в succeeded, поэтому к истёкшему счёту стоит вернуться, когда клиент снова придёт.
• Цену пересчитывают по проценту у себя — сумма расходится со счётом. Показывайте price из ответа как есть.
• Наценку забыли задать — продажи идут по цене платформы без вашего заработка.
• JSON вебхука разбирают и собирают заново до проверки подписи — проверка не проходит.
• Вебхук обрабатывают дольше 15 секунд до ответа — платформа считает доставку сбоем и шлёт событие снова.
• Показывают клиенту текст message из ошибки — формулировки меняются, клиенту нужен ваш понятный текст.

Чек-лист перед запуском продаж через API

• [ ] Название сервиса, наценка и ссылка поддержки заданы через PATCH /account
• [ ] Цены на сайте берутся из GET /plans без своего пересчёта
• [ ] Ссылки на соглашение и политику стоят рядом с кнопкой оплаты
• [ ] Вы купили подписку на себя: счёт своему client_id, оплата, статус succeeded
• [ ] Подключение проверено с телефона и компьютера — кнопкой и по QR-коду
• [ ] Продление и докупка устройств работают тем же POST /payments
• [ ] Повтор счёта после таймаута или 5xx идёт с тем же Idempotency-Key
• [ ] Ключа нет в коде сайта, мини-приложения и в репозитории
• [ ] Вебхуки проверяются по подписи, дубли отсекаются по webhook-id, тест из кабинета проходит
• [ ] Незнакомые поля, коды ошибок и типы событий не ломают интеграцию

Подробный список — на странице документации «Перед запуском». Вопросы по интеграции принимает менеджер платформы в Telegram @vargo_support: в обращении укажите метод и путь запроса, время в UTC и code из ответа.

Документация и с чего начать

• Обзор возможностей и быстрый старт — документация VPN API.
• Все методы одной таблицей — «Все эндпоинты».
• Ключ, client_id и повторы — «Начало работы».
• События и проверка подписи — «Вебхуки».
• Коды ошибок и лимиты — «Ошибки и лимиты».
• Что умеет API и кому подходит — страница VPN API.

Схема OpenAPI открыта без ключа — файл openapi.json. Её можно отдать нейросети вместе с задачей, чтобы она писала интеграцию по настоящим полям, а не по догадкам.

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

Что такое white-label VPN API?

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

Сколько стоит продажа VPN через API и нужен ли депозит?

Подключение бесплатное, депозита и абонентской платы нет. Клиент платит платформе по ссылке из счёта: цена платформы остаётся ей, ваша наценка ложится на баланс партнёра. Ваши расходы — сервер, разработка и привлечение клиентов.

Есть ли у VPN API тестовый режим?

Нет, каждый ключ боевой. Неоплаченный счёт ничего не стоит и просто истекает, а интеграцию проверяют, купив подписку себе.

Можно ли принимать оплату на своём сайте своей кассой?

Нет. Клиент оплачивает на странице оплаты платформы, после оплаты доступ выдаётся сам, а ссылку подписки вы получаете в ответе API и в вебхуке. Принимать оплату за подписки мимо платформы правила запрещают.

Под каким названием клиент видит сервис?

Под вашим: название задаётся через API и стоит в документах клиента и в VPN-приложении. Пользовательское соглашение и политику конфиденциальности ведёт платформа, ссылки на них отдаёт API.

Можно ли продавать и через бота, и через API?

Да. Бот и API живут в одном кабинете партнёра, тарифы платформы у них одни, а наценка у API своя и цены бота не меняет. Наценка с обоих каналов копится на балансе.

Нужно ли уметь программировать, чтобы продавать VPN через API?

Да, нужен свой сервер и разработчик или нейросеть, которой вы отдадите открытую схему OpenAPI. Если писать и поддерживать код некому, начните с готового бота: он подключается без кода в @vargo_robot, а к API можно перейти позже.