# Изменения API: 6 сентября 2026

[← Журнал изменений](/docs/changelog) · [Сентябрь 2026](/docs/changelog/2026-09)

### FIX-0906-1: бесплатный тариф Битрикс24 при выписке ключа отвечает терминально, а не «повторите позже»

**Было**

Облачный аккаунт на бесплатном тарифе Битрикс24 получал на выписку ключа 502
`CONNECTOR_REST_UNAVAILABLE` с `details.retryable: true`, если по данным аккаунта его
доступ к Маркетплейсу действовал. Ответ обещал, что поможет повтор. Битрикс24 на
бесплатном тарифе закрывает REST целиком, поэтому повтор не помогал никогда.

Аккаунт без подписки Маркетплейса на том же тарифе получал 403
`B24_MARKET_SUBSCRIPTION_REQUIRED`, а с уже израсходованным пробным периодом — 403
`B24_MARKET_TRIAL_USED`. Оба ответа продавали средство, которое бесплатный тариф не
снимает.

Признак `activation.marketTrial.available` в `GET /v1/cowork/state` отдавал `true`
такому аккаунту, и `POST /v1/cowork/activate-market-trial` расходовал его одноразовый
пробный период Маркетплейса впустую.

**Стало**

Тот же случай отвечает терминальным отказом, который называет средство — платный тариф
Битрикс24: `B24_PAID_TARIFF_REQUIRED` (402) с полем `userMessage`. Код не новый,
изменился набор состояний, при которых он приходит: раньше только «доступ оплачен, но
не действует», теперь — любое состояние доступа на прочитанном бесплатном тарифе.
Повтор без смены тарифа вернёт то же самое. В этом случае коды 403
`B24_MARKET_SUBSCRIPTION_REQUIRED` и `B24_MARKET_TRIAL_USED` уже не приходят — их клетки
перехватывает тарифный отказ. При других отказах выписки они по-прежнему возможны, в том
числе на бесплатном тарифе.

Всё сказанное про подписку относится к аккаунтам, где она продаётся, — Россия и
Беларусь. В Казахстане и Узбекистане подписки как продукта нет: там та же стена отдаёт
свой терминальный отказ — 403 `INT_TARIFF_REQUIRED`, — а подписочные коды к таким
аккаунтам не приходили и раньше.

`activation.marketTrial.available` для такого аккаунта теперь `false` с причиной
`not_supported`, а `POST /v1/cowork/activate-market-trial` и
`POST /v1/portals/{id}/activate-market-trial` отвечают отказом, не расходуя пробный
период. Аккаунт на тарифе «Демо» Битрикс24 не затронут: этот тариф REST не закрывает,
и ответ у него прежний. Аккаунт, тариф которого прочитать не удалось, ведёт себя как
раньше.

### BC-0906-2: PATCH /v1/infra/servers/:id/mode отклоняет открытие для серверов с запечатанной ролью

> Поддержка старого формата до: не предусмотрена

**Было**

Для сервера, которому по его роли (участник пула, служебная машина) полагается закрытая сетевая политика, [PATCH /v1/infra/servers/:id/mode](/docs/infra/access/mode) с `mode: "OPEN"` отвечал `200`: сервер действительно переходил в открытый режим, а выданный SSH-пароль работал.

**Стало**

Такой запрос отклоняется с `409 MODE_SWITCH_SEALED_ROLE`; режим сервера не меняется, пароль не выдаётся. Отказ применяется там, где сетевая политика сервера поддержана дополнительным слоем для этого сервера; там, где такой поддержки нет, поведение не изменилось.

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

Клиенты, которые ожидали `200` для серверов с запечатанной ролью, обязаны обрабатывать `409 MODE_SWITCH_SEALED_ROLE` как терминальный отказ: открытый режим для такого сервера недоступен, повторять запрос бессмысленно. Для остальных серверов (не запечатанной роли) `200` и выдача пароля не изменились.

### NEW-0906-3: PATCH /v1/infra/servers/:id/mode может отдать отказ переключения сетевой политики

[PATCH /v1/infra/servers/:id/mode](/docs/infra/access/mode) закрывает сетевую политику сервера ещё одним слоем — снаружи гостевой машины, поверх уже существующей защиты внутри неё. Если переключить сетевую политику сервера не удалось, ручка отвечает `503 SECURITY_GROUP_ATTACH_FAILED`; режим сервера при этом не меняется, и повтор запроса имеет смысл. Отказ возможен только там, где этот дополнительный слой поддержан для конкретного сервера; там, где поддержки нет, поведение ручки не изменилось.

### FIX-0906-4: PATCH /v1/infra/servers/:id/mode закрывает фаервол сервера, если связь с ним оборвалась посреди переключения

**Было**

[PATCH /v1/infra/servers/:id/mode](/docs/infra/access/mode) выполняет переключение режима командами на самом сервере. Если связь с сервером терялась посреди этой последовательности — таймаут, обрыв туннеля, недоступный агент, — ручка отвечала ошибкой, но сервер мог остаться с уже открытым фаерволом при неизменённом режиме `BLACKHOLE`: команда открытия успевала исполниться, а закрыть её обратно было некому. Ошибка при этом сообщала, что переключение отменено.

**Стало**

Такой обрыв теперь запускает закрытие фаервола обратно до того, как ошибка уедет клиенту: раньше на этом пути не делалось ничего, и открытый сервер при режиме `BLACKHOLE` оставался так до следующего вмешательства.

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

Один случай остаётся исключением и описан здесь намеренно: если сервер уже успел закрыться, а сорвалась запись режима, фаервол НЕ открывается обратно — снимать выполненное закрытие из-за сбоя записи было бы опаснее. Сервер тогда закрыт, а режим по нему отдаётся как `OPEN`.

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

Коды ответов не изменились, и повтор запроса по-прежнему имеет смысл. В исключении, описанном выше, повтор с `mode: "OPEN"` отклоняется как `400 SAME_MODE` — режим по строке уже `OPEN`; доступ возвращается переключением в `BLACKHOLE` и обратно в `OPEN`.