Начало работы
Аутентификация
Запросы к ZennoHosting API авторизуются bearer token в заголовке Authorization. Практический bootstrap flow начинается вне этой API-поверхности: сначала выпустите или получите токен в аккаунтной части ZennoHosting, а затем передавайте его в каждом запросе API.
Текущий контракт
- Получите access token до вызова любого endpoint проекта, VM, сети, backup или public IP.
Каждый запрос должен содержать заголовок
Authorization.Значение заголовка должно соответствовать формату
Bearer <token>.- Не храните токен в исходном коде и передавайте его в клиент или runtime через безопасную конфигурацию.
Где в эту модель входит /tokens
В generated API surface есть /v1/tokens, но этот endpoint следует воспринимать как управление
токенами внутри уже доступного API-контекста, а не как первичный bootstrap login flow для новой интеграции. Если
вы начинаете с нулевого доступа, сначала получите первый рабочий токен в аккаунте ZennoHosting.
Первый аутентифицированный запрос
После получения токена выполните неразрушающий запрос. Список проектов — самый наглядный smoke test: он сразу подтверждает корректность base URL, bearer-заголовка и значения токена без изменения состояния.
curl --request GET \
--url 'https://api.zennohosting.com/projects' \
--header 'Authorization: Bearer <token>' \
--header 'Accept: application/json'Практические замечания
- Заложите в клиенте обработку истечения срока действия токена, его обновления или замены.
- Используйте один base URL на окружение и централизуйте сборку заголовков в API-клиенте.
- По возможности используйте scoped tokens, если automation не нужен полный административный доступ.
- Зафиксируйте, кто или какой сервис отвечает за ротацию токенов в долгоживущих automation pipelines.
Типичные проблемы
Отсутствующий префикс Bearer, истёкший токен или некорректный заголовок
Authorization на первом этапе интеграции часто выглядят так же, как и неправильный base URL.
Проверяйте форму заголовка и актуальность токена до того, как искать проблему в payload.