Изменения API: 22 июля 2026

← Журнал изменений · Июль 2026

BC-0722-1: иконка сервера отдаётся как PNG

Поддержка старого формата до: 21.07.2026

Иконка сервера теперь отдаётся как PNG 256×256 (Content-Type: image/png) — платформа рендерит её из вашего загруженного SVG. Загрузка (POST /v1/infra/servers/:id/icon) по-прежнему принимает только SVG и теперь может вернуть 400 ICON_RASTERIZE_FAILED, если файл не удаётся растеризовать в PNG.

NEW-0722-2: пробуждение по расписанию (wake-schedules) доступно на всех порталах

CRUD для окон пробуждения — GET|POST /v1/infra/servers/:id/wake-schedules, PATCH|DELETE /v1/infra/servers/:id/wake-schedules/:scheduleId — теперь доступен на всех порталах для отдельных серверов (kind: "STANDALONE"): запрос больше не отвечает 403 WAKE_SCHEDULE_DISABLED. Платформа поднимает спящий сервер к заданному моменту по cron-выражению, дальше запуск задачи делает собственный cron внутри уже поднятой машины. Galaxy-приложения (kind: "GALAXY_APP") пока не участвуют в раскрытии и по-прежнему отвечают 403 WAKE_SCHEDULE_GALAXY_DISABLED. Ответ GET /v1/infra/servers/:id и список серверов теперь содержат аддитивные поля nextScheduledWakeAt (время ближайшего пробуждения, ISO 8601 или null) и wakeScheduleCapable — прежние поля не меняются.

NEW-0722-3: 409 SERVER_NOT_READY при деплое несёт признак повторяемости

POST /v1/infra/servers/:id/deploy в ответе 409 SERVER_NOT_READY, когда на сервере уже идёт восстановление подключения (запущенное параллельным деплоем или ремонтом), теперь дополнительно возвращает поля error.retryable: true и error.retryAfter (секунды) и заголовок Retry-After. Это машинный сигнал: повтор запроса имеет смысл — подождите указанный интервал и повторите деплой. Прежние клиенты не затронуты: код и текст ошибки прежние, поля добавлены аддитивно.

NEW-0722-4: Новый эндпоинт активации триала Маркета для портала ключа

POST /v1/portals/:id/activate-market-trial активирует одноразовый триал Битрикс24 Маркета для портала, которому принадлежит вызывающий ключ. Раньше активация была доступна только из кабинета — у ключей API программного пути не было.

:id обязан совпадать с порталом ключа, иначе 403 PORTAL_MISMATCH. Тело не требуется. Лимит — 3 запроса в час на портал.

Ответ при успехе: { "success": true, "data": { "status": "activated", "trialEndsAt": "..." } } (или "status": "already_active", если триал/доступ уже есть). Ошибки: 403 WRITE_BLOCKED_READONLY_KEY (ключ только для чтения), 403 PURPOSE_KEY_FORBIDDEN (служебный ключ специального назначения не может активировать триал), 404 NOT_FOUND (портал не найден), 409 ALREADY_ACTIVATED (триал уже активирован), 409 TRIAL_ACTIVATION_UNAVAILABLE (триал недоступен для этого портала), 503 TRIAL_ACTIVATION_RETRY (временная ошибка, повторите позже).

FIX-0722-5: портал с активной подпиской Маркетплейса больше не получает ложный отказ `MARKETPLACE_REQUIRED`

Было

На портале с несколькими держателями ключа разработчика состояние подписки Маркетплейса могло не прочитаться: если первый опрошенный ключ отвечал данными о портале, но без блока подписки (урезанный набор прав), опрос на этом останавливался и до ключа, способного прочитать подписку, дело не доходило. Подписка оставалась неизвестной, и портал с реально оплаченной подпиской получал 402 MARKETPLACE_REQUIRED на POST /v1/infra/servers, а GET /v1/me отдавал capabilities.servers.create.available: false. Повторный вызов GET /v1/me?refresh=tariff отказ не снимал.

Стало

Опрос продолжается до ключа, который вернёт блок подписки. Порталу с оплаченной подпиской создание сервера разрешается, capabilities.servers.create.available становится true. Формат ответов не изменился, действий со стороны клиента не требуется. Состояние обновляется при очередном обновлении тарифа портала (не позже часа) либо сразу по GET /v1/me?refresh=tariff.

Влияние на интеграторов

Действий не требуется. Клиент, который ветвился на 402 при создании сервера, продолжает работать: на затронутых порталах этот ответ просто перестаёт приходить.

FIX-0722-6: поле `region` в ответах об инфраструктуре всегда возвращает идентификатор региона

Было

У сервера, созданного и запущенного на международном сегменте, GET /v1/infra/servers и GET /v1/infra/servers/:id могли вернуть в поле region внутренний идентификатор зоны размещения, а не идентификатор региона из каталога. Значение не совпадало ни с одним id из GET /v1/infra/providers/:providerId/regions, поэтому сопоставить сервер с регионом каталога по этому полю было нельзя, и оно раскрывало детали внутреннего размещения.

Стало

region всегда содержит нейтральный идентификатор региона из того же пространства имён, что и каталог, — например bc-eu-central. Значение совпадает с id соответствующей записи GET /v1/infra/providers/:providerId/regions, поэтому сервер сопоставляется с регионом каталога напрямую. Зона размещения — внутренняя деталь: при создании сервера указывается регион, конкретную зону внутри него платформа выбирает сама.

Что делать интеграторам

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