Покупайте инфраструктуру без участия человека.

Дескриптор сервиса ниже общедоступен и не требует аутентификации. Это правильный первый вызов из любого контекста агента — один JSON-документ со списком продуктов, моделью оплаты и всеми эндпоинтами, описанными на этой странице.

curl -s 'https://cryptovpshost.com/.well-known/agent.json' \
  -H 'Accept: application/json' | jq .

Дальше: аутентифицируйтесь, пополните баланс, затем разверните сервер — и всё это из вашего агента.

Эталонная матрица цен и характеристик находится на сервере в /includes/catalogue.php. Для машинного доступа используйте справочник по эндпоинтам в §5.

Текущая реализация: сессионные cookie + CSRF. Так же устроен и веб-интерфейс. Агент хранит cookie PHPSESSID и значение CSRF _token на протяжении всей своей сессии.

План развития: запланирован эндпоинт с Bearer-токеном (POST /api/v1/account), который будет возвращать { account_token: "AAAA-BBBB-CCCC-DDDD" }. Действующий API на основе сессий уже работает и без него. Когда Bearer появится, все сессионные эндпоинты смогут принимать Authorization: Bearer <token> как альтернативный способ аутентификации.

JAR=/tmp/nkv.jar
# 1. get a session + CSRF
CSRF=$(curl -sc $JAR https://cryptovpshost.com/csrf.php | jq -r .csrf)

# 2. create the account (no email verification)
curl -sb $JAR -c $JAR https://cryptovpshost.com/auth-api.php \
  -d "action=signup" \
  -d "email=a$(date +%s)@cryptovpshost.com" \
  -d "password=Sup3rH4rdP4ssword!" \
  -d "password_confirm=Sup3rH4rdP4ssword!" \
  -d "_token=$CSRF" | jq .

# 3. confirm we're logged in
curl -sb $JAR https://cryptovpshost.com/me.php | jq .

1. Пополните баланс. POST /topup-api.php с action=create&amount=100&coin=XMR&_token=<csrf> → возвращает order_ref.
2. Откройте счёт. GET /pay/<order_ref> возвращает HTML с адресом для пополнения, точной суммой и необязательным memo. Для программного сценария те же данные доступны по GET /topup-status.php?ref=<order_ref>.
3. Отправьте криптовалюту. Ровно deposit_amount на deposit_address в соответствующей сети. Бонус от $100 (+30%) до $1000 (+70%). Бонус зачисляется автоматически после подтверждения.
4. Дождитесь подтверждения. Опрашивайте GET /topup-status.php?ref=<order_ref>, пока не появится status=confirmed. Хаб simsms присылает вебхук на /network-api/payment_status.php — обычно это 1–3 подтверждения в исходной сети.
5. Разверните сервер. POST /deploy-api.php с product=vps|dedi&plan=s1|s2|s3|r1|r2|r3&region=par|rek|zrh|otp&os=debian-12&billing=1&root_password=<12+chars>&_token=<csrf>. Баланс списывается атомарно. В ответе приходят server_id и новый баланс.

curl -sb $JAR -c $JAR https://cryptovpshost.com/deploy-api.php \
  -d "product=vps" \
  -d "plan=s2" \
  -d "region=par" \
  -d "os=debian-13" \
  -d "billing=3" \
  -d "root_password=$(openssl rand -base64 18 | tr -d '/+=')" \
  -d "_token=$CSRF" | jq .

# Insufficient balance? Response includes the deficit:
# { ok:false, error:"insufficient_balance", have:X, need:Y, deficit:Y-X, topup:"/topup" }

Все эндпоинты, требующие аутентификации, используют один и тот же механизм CSRF: передавайте _token в теле POST-запроса или X-CSRF-Token в заголовке. Токен запрашивается один раз через /csrf.php и действует всё время жизни сессии.

Если человек ненадолго подключается к процессу (согласование, подтверждение), покажите ему эти URL — они подставят в веб-интерфейс решение, которое агент уже принял. Вводить заново ничего не нужно.

• CSRF в каждом POST. Запросите /csrf.php один раз за сессию; передавайте значение как _token в теле запроса или в заголовке X-CSRF-Token.
• Сессионные cookie нужно сохранять. Используйте cookie jar (curl -b/-c, Python requests.Session() и т. д.). Без сохранения каждый вызов — это новая анонимная сессия.
• Идемпотентность. Зачисления на баланс идемпотентны благодаря credit_applied=1. Повторное развёртывание с теми же параметрами создаёт новый сервер — дедупликации по ключам развёртывания пока нет. При необходимости дедуплицируйте на стороне клиента.
• Задержка вебхука. Подтверждение пополнения приходит push-уведомлением от хаба simsms. Медиана: ~3 мин для BTC (1 подтверждение), ~30 с для XMR. Опрашивайте /topup-status.php с интервалом 5–10 с.
• Лимиты пополнения (проверяются на сервере): минимум $30, максимум $10,000 на один счёт. Значения вне этого диапазона возвращают ok:false с error:'amount_too_low' или 'amount_too_high' — НЕ полагайтесь на проверку на стороне клиента. Бонусная шкала начинается с $100 (+30%) и ограничена потолком +70% для сумм свыше $1000.
• Пароли root для серверов должны содержать 12–64 символа. Хранятся в зашифрованном виде (AES-256-CBC); расшифровать их может только система развёртывания.
• Языковой префикс. URL принимают необязательный языковой префикс (/ru/account, /zh/vps/). Для агентов канонический вариант — путь без префикса.

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

• /terms-of-service — по каким требованиям мы действуем и по каким нет (только по судебным постановлениям, с уведомлением клиента).
• /acceptable-use — что вы можете запускать (политика такова: «если это где-то легально»). Одна жёсткая граница: никакого CSAM.
• /privacy-notice — что мы собираем (email, хеш пароля, ваш баланс, конфигурацию ваших серверов) и чего не собираем (имена, адреса, отпечатки устройств, аналитику).
• /abuse-policy — только сетевые злоупотребления (спам, сканирование, амплификация). Содержимое не является основанием для приостановки.

Агентам рады. Мы не делаем различий между аккаунтом, открытым человеком, и аккаунтом, открытым автономным клиентом. Правила игры для всех одни и те же.

MCP-сервер: запланирован. Текущий REST-интерфейс, описанный выше, покрывает те же действия. Когда MCP-эндпоинт появится, о нём будет объявлено в /.well-known/agent.json#mcp и через расширение x-mcp-server в openapi.json.