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

[← Журнал изменений](/docs/changelog) · [Июль 2026](/docs/changelog/2026-07)

### 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](/docs/infra/wake-schedules/list), [PATCH|DELETE /v1/infra/servers/:id/wake-schedules/:scheduleId](/docs/infra/wake-schedules/update) — теперь доступен на всех порталах для отдельных серверов (`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](/docs/infra/deploy/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](/docs/infra), а `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](/docs/infra/servers) и `GET /v1/infra/servers/:id` могли вернуть в поле `region` внутренний идентификатор **зоны размещения**, а не идентификатор региона из каталога. Значение не совпадало ни с одним `id` из [GET /v1/infra/providers/:providerId/regions](/docs/infra/providers), поэтому сопоставить сервер с регионом каталога по этому полю было нельзя, и оно раскрывало детали внутреннего размещения.

**Стало**

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

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

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