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

← Журнал изменений · Сентябрь 2026

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 с 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 закрывает сетевую политику сервера ещё одним слоем — снаружи гостевой машины, поверх уже существующей защиты внутри неё. Если переключить сетевую политику сервера не удалось, ручка отвечает 503 SECURITY_GROUP_ATTACH_FAILED; режим сервера при этом не меняется, и повтор запроса имеет смысл. Отказ возможен только там, где этот дополнительный слой поддержан для конкретного сервера; там, где поддержки нет, поведение ручки не изменилось.

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

Было

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

Стало

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

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

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

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

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