Изменения API: 10 августа 2026

← Журнал изменений · Август 2026

NEW-0810-1: выдача ссылки-приглашения отмечается в журнале доступа портала

Ответ POST /v1/infra/servers/:id/access-tokens не изменился — меняется то, что происходит на стороне портала.

Было

Выдача ссылки с mode=share-url не оставляла следа в надзорном слое портала: администратор не видел, кто и когда открыл приложение ссылкой.

Стало

После успешной выдачи ссылки платформа записывает смену открытости в журнал портала, а если ссылка не требует входа в Битрикс24 (identityBound=false) и приложение до этого не было открыто наружу — отправляет администраторам портала сообщение в чат-бот со ссылкой на список открытых приложений.

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

Формат запроса, ответа и коды ошибок не изменились — менять клиент не нужно. Учитывайте, что каждая выдача открытой ссылки теперь видима администратору портала.

BC-0810-2: ошибка фильтра в POST /v1/{entity}/batch стала ошибкой подвызова, а не всего запроса

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

Было

Один неверный ключ фильтра в любом подвызове POST /v1/{entity}/batch отменял весь запрос: ответ 400, код в error.code, результаты остальных подвызовов отбрасывались. Глобальный POST /v1/batch вёл себя иначе — клал ошибку рядом с конкретным подвызовом и выполнял остальные.

Стало

Обе поверхности ведут себя одинаково. Ответ — 200, код отказа лежит в data[i].error.code для того подвызова, который его вызвал; остальные подвызовы выполняются и возвращают данные. Сам набор отказов и их коды не изменились — изменился только радиус: UNKNOWN_FILTER_FIELD, INVALID_FILTER_OPERATOR, INVALID_FILTER_FIELD, UNSUPPORTED_FILTER.

Прежний текст ошибки начинался с Call at index N: — теперь позиция подвызова видна по его месту в массиве data, и префикс убран.

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

Если код читает отказ фильтра как HTTP 400 с error.code, добавьте разбор 200 с data[i].error.code — иначе подвызов, у которого фильтр не принят, будет прочитан как успешный. Проверяйте наличие error у каждого элемента data, как это уже делается для глобального POST /v1/batch.

BC-0810-3: чтение через батч больше не обходит выключенную операцию сущности

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

Было

Сущность может выключать отдельную операцию — обычно потому, что универсальный обработчик для неё неверен: настоящий список живёт на собственном маршруте с другим конвертом, либо метод Битрикс24 не понимает фильтр и отдаёт таблицу целиком. Одиночные маршруты это учитывали, запись через батч — тоже, а чтение через батч — нет. Поэтому POST /v1/{entity}/batch и POST /v1/batch с action list, get, search или fields отвечали 200 там, где та же операция на своём маршруте отвечает 404 — и отдавали ровно тот результат, ради отказа от которого операцию и выключили.

Отдельно: устаревший GET /v1/{entity}/aggregate вообще не спрашивал, есть ли у сущности агрегация. У сущности, где все числовые поля — идентификаторы, POST /v1/{entity}/aggregate отвечает 404, а этот адрес отвечал 200.

Стало

Оба батча отвечают на выключенную операцию 400 с кодом ACTION_NOT_SUPPORTED до вызова Битрикс24: в per-entity батче это ответ всего запроса, в глобальном — ошибка конкретного подвызова (остальные подвызовы выполняются). Устаревший GET /v1/{entity}/aggregate регистрируется по тому же признаку, что и POST-версия, поэтому у сущности без агрегации теперь 404 на обоих адресах.

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

Затронуты только те сущности и операции, где ответ и раньше был неверным. Проверить стоит все четыре чтения — list, get, search, fields: у шести сущностей выключен именно search при работающем list, поэтому пачка, которая раньше проходила целиком, теперь вернёт ACTION_NOT_SUPPORTED на этом подвызове. Полный набор действий сущности — в operations.batch ответа GET /v1/guide и в описании OpenAPI; data.batch в GET /v1/{entity}/fields перечисляет только действия ЗАПИСИ и на вопрос про чтения не отвечает. У сущности, где выключено всё, маршрут остаётся на месте, но любое действие отвечает ACTION_NOT_SUPPORTED — отказ называет действие, чего 404 на адресе сказать не может.

BC-0810-4: `filter`, переданный не объектом, отклоняется вместо тихой потери

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

Как и в соседней записи про неизвестное имя поля, «старый формат» здесь означает неверный ответ, а не рабочий.

Было

filter — объект условий, но передать вместо него строку, число, булево значение или массив никто не мешал. Строка и массив уходили в Битрикс24 как есть, число и булево превращались в пустой отбор — и во всех случаях запрос отвечал 200 со ВСЕЙ коллекцией:

POST /v1/tasks/search   { "filter": [{ "responsibleId": 1 }] }   →  200, все задачи портала

Стало

Такой запрос отклоняется до вызова Битрикс24 — 400 с кодом INVALID_FILTER_SHAPE; в сообщении сказано, что именно пришло вместо объекта, и показана правильная форма.

Действует на всех сущностях и на всех поверхностях, где filter приходит в теле: поиск, агрегация и оба батча.

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

Передавайте filter объектом. В строке запроса это отдельная история: там условия пишутся скобочной формой (?filter[responsibleId]=1), а filter, закодированный в JSON одной строкой, с этой же поставки не отклоняется, а разбирается и применяется — раньше он молча терялся и возвращал всю коллекцию.

BC-0810-5: неизвестное имя поля в фильтре отклоняется ещё на пятнадцати сущностях

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

До сих пор такой фильтр отвечал 200 и всей коллекцией — то есть «старый формат» здесь означает неверный ответ, а не рабочий.

Было

Фильтр по имени, которого у сущности нет, уходил в Битрикс24. Битрикс24 такой ключ не отклоняет — он молча его выбрасывает и отвечает 200 со ВСЕЙ коллекцией. Опечатка в имени поля поэтому выглядела как успешный запрос с неправдоподобно большим результатом:

GET /v1/tasks?filter[responsable]=1     →  200, все задачи портала

Так вели себя задачи, пользователи, рабочие группы, реквизиты, банковские реквизиты, шаблоны реквизитов, адреса, сайты, страницы, комментарии таймлайна, шаблоны бизнес-процессов, настройки открытых линий и элементы универсальных списков.

Стало

Такой запрос отклоняется до вызова Битрикс24 — 400 с кодом UNKNOWN_FILTER_FIELD и списком доступных имён в сообщении — этот список и есть точный ответ на вопрос «по чему можно фильтровать».

Проверяется только имя: операторы, диапазоны, $in/$nin и логика И работают как раньше. Кроме объявленных полей принимаются пользовательские поля (UF_*, ufCrm*) и — у сущностей, где он объявлен, — ключ id.

Отдельно: у действий и роботов бизнес-процессов метод Битрикс24 не принимает фильтр ни в каком виде, поэтому там отклоняется любой ключ фильтра — код UNSUPPORTED_FILTER.

Полное описание — Фильтрация и поиск.

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

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

FIX-0810-6: нехватка места на общем хосте — отдельный повторяемый отказ деплоя, а не поломка приложения

Было

Когда на общем хосте galaxy-приложения кончалось свободное место, сборка падала, и POST /v1/infra/servers/:id/deploy отвечал 502 GALAXY_APP_BUILD_FAILED — тем же кодом, что и ошибка в исходниках самого приложения. Приложение при этом помечалось сломанным, хотя работать не переставало: отказ происходил на сборке, до подмены контейнера, поэтому предыдущая версия продолжала отвечать на запросы. Отличить нехватку места от настоящей ошибки сборки можно было только по хвосту лога в buildLog, а повтор того же деплоя давал тот же результат.

Стало

Тот же случай возвращает 502 GALAXY_LOW_DISK с признаком retryable: true и структурированным полем error.hint: причина, что сделать и предупреждение не удалять слот. Приложение не помечается сломанным — слот, контейнер и его том с данными целы, а уже работающая версия обслуживает трафик дальше. Повторять деплой имеет смысл после того, как на хосте освободили место: само оно не освобождается, поэтому немедленный повтор упирается в тот же отказ. Новый код перечислен в машинном описании контракта деплоя, которое отдают GET /v1/me и GET /v1/openapi.json.

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

Менять ничего не нужно: успешные деплои не затронуты. Ветку на GALAXY_APP_BUILD_FAILED оставьте — она по-прежнему приходит на настоящих ошибках сборки, а у нехватки места теперь есть отдельный код, по которому видно, что дело не в исходниках. Автоматический повтор бывает только там, где платформа сама пересобирает уже существующее приложение: там попытки идут без участия клиента, пока не истечёт отведённый на ожидание бюджет. При создании приложения сразу с исходниками отказ приходит сразу и не повторяется — решение о повторе остаётся за вами.

FIX-0810-7: Открытие из каталога Битрикс24 предупреждает, что приложение не авторизовано

Было

Приложение, открытое из каталога Битрикс24 пользователем, который ещё не выдал ему доступ, запускалось как обычно, но шлюз не проставлял заголовок X-Vibe-Authorization. Вызовы к API отвечали 401, и приложение показывало текст, который наша же документация предписывала для 401, — «откройте приложение из меню Битрикс24». Совет был тупиковым: пользователь именно так и открыл, а открытие из каталога доступ не выдаёт.

Стало

Такой запуск платформа перехватывает и показывает экран с кнопкой «Авторизовать приложение»; второй путь — один раз открыть приложение через встройку в меню Битрикс24. Там же есть неприметная ссылка «открыть без авторизации» на тот же адрес запуска — приложение, которому сессия не нужна, открывается как прежде. Экран показывается только там, где кнопке есть куда вести: облачный портал, ключ приложения и зарегистрированное OAuth-приложение. Во всех остальных случаях запуск идёт как раньше.

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

Менять код не нужно, и ни один запуск не становится недоступным. Стоит поправить только текст своей ошибки на 401: у неё две причины — истёкшая сессия и не выданный доступ, — поэтому «откройте из меню» как единственная формулировка вводит пользователя в заблуждение. Рекомендация обновлена в разделе Среда выполнения приложения.

NEW-0810-8: список документов CRM появился в машинной схеме OpenAPI

Эндпоинт GET /v1/crm-documents теперь описан в схеме OpenAPI, которую отдаёт /v1/openapi.json. Сам вызов работал и раньше, но клиенты и ИИ-агенты, которые строят интеграцию по машинному описанию, считали его несуществующим. В описании указаны обязательный параметр entityTypeId, необязательные entityId, select, order и start, требуемый доступ crm, форма ответа с массивом документов и блоком meta с полями total, start и next, а также коды отказа MISSING_PARAMS, INVALID_ENTITY_ID, INVALID_START, TOKEN_MISSING и SCOPE_DENIED. Параметр размера страницы эндпоинт не принимает и в описании его нет: за следующей страницей идут со значением meta.next в start. Поведение самого эндпоинта не изменилось.

FIX-0810-9: при входе по прямой ссылке приложение получает имя и токен посетителя

Было

Приложение, открытое по прямой ссылке на свой адрес (а не плиткой из Битрикс24), получало имя посетителя из его учётной записи на платформе Вайбкод, а не из карточки сотрудника: участник нескольких Битрикс24 видел имя, под которым он записан в другом из них. Заголовок X-Vibe-Authorization на этом пути не приходил вовсе — приложение не могло обратиться в Битрикс24 от лица посетителя.

Стало

X-Vibe-User-Name и X-Vibe-User-Name-Encoded несут имя из карточки сотрудника того Битрикс24, которому принадлежит приложение — как и при открытии плиткой. Токен доступа X-Vibe-Authorization резолвится по номеру сотрудника, поэтому приходит и здесь.

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

Формат заголовков не изменился, менять клиент не нужно. Если карточку сотрудника прочитать не удалось, имя остаётся прежним, из учётной записи на платформе Вайбкод: пустым заголовок не приходит.

FIX-0810-10: пользовательские поля счёта

Было

Пользовательские поля счёта нельзя было прочитать или создать ни одним путём. GET /v1/userfields/invoices отвечал ошибкой UNKNOWN_ENTITY, а GET /v1/items/31/userfields — ошибкой доступа от Битрикс24, потому что счёт адресовался так же, как обычный смарт-процесс.

Стало

Оба пути работают и дают одинаковый результат: шесть операций (список, справочник типов, чтение, создание, изменение, удаление) над пользовательскими полями счёта. Путь /v1/userfields/invoices добавлен для тех, кому удобнее обращаться по имени сущности, а не по числовому идентификатору типа.

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

Менять ничего не нужно. Речь идёт о счетах в текущем виде; счета старого образца через API по-прежнему недоступны.

BC-0810-11: Справочник полей товарных позиций описывает то, что реально приходит в ответах

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

Было

GET /v1/deals/{id}/products/fields отдавал набор полей Битрикс24 как есть, и он расходился с ответами самих товарных позиций сразу в трёх местах. Сумма скидки называлась в справочнике discountSum, а в данных и при записи — discount. Внешний код позиции и цена в валюте отчёта приходили в каждой строке, но в справочнике отсутствовали. Владелец строки, тип владельца и склад, наоборот, были в справочнике, но из ответов вырезались.

Хуже того, клиент, сгенерировавший запись по этому справочнику, отправлял discountSum — обёртка это имя не распознавала, отвечала 201 Создано и молча выбрасывала скидку. То же происходило с любым другим неизвестным полем: ответ об успехе, данные не записаны.

Стало

Справочник собирается из тех же таблиц, по которым формируются сами ответы, поэтому разъехаться они больше не могут. Скидка называется discount — как в данных, при записи и в документации. Прежнее имя discountSum при этом никуда не делось: оно осталось устаревшим псевдонимом, по-прежнему приходит в справочнике и по-прежнему принимается при записи, поэтому код, написанный по старому списку полей, продолжает работать — с той разницей, что скидка теперь действительно записывается, а не теряется молча. В самих товарных позициях приходит только discount. Добавлены priceAccount и xmlId, которые Битрикс24 возвращает в строках, но в своём справочнике не описывает. Поля ownerId, ownerType и storeId теперь приходят в ответах списка и одной позиции; storeId равен null, если складской учёт выключен.

Признаки isReadOnly и isRequired описывают контракт этого API, а не контракт Битрикс24: ownerId, ownerType, customized и measureName помечены только для чтения (записать их через обёртку нельзя), а у ownerId и ownerType снят признак обязательности — они берутся из адреса запроса. У id появилось пояснение: как атрибут он только для чтения, а в элементах PUT /products он принимается. Уточнение 18.08.2026: живая проверка показала, что возврат id идентичность строки не сохраняет — позиция, поля которой не изменились, сохраняет свой id и без id в теле, а изменённая приходит с новым id. Правка позиции с сохранением идентификатора идёт через PATCH /v1/deals/:id/products/:rowId.

Запись с неизвестным именем поля больше не отвечает успехом: POST, PUT и PATCH возвращают 400 INVALID_PARAMS и перечисляют записываемые поля. Поля только для чтения по-прежнему принимаются и игнорируются, поэтому объект, прочитанный через GET, можно отправить обратно без чистки.

Поле id в теле принимается только в элементах PUT /products. При создании и правке оно отбрасывается: строку там задаёт адрес запроса, а тело с id уже существующей строки — ровно то, что получается, если отправить обратно объект, прочитанный через GET.

Признак taxIncluded при записи снова принимается булевым: true и false уходят в Битрикс24 как Y и N. Раньше булево значение отправлялось как есть, и налог по строке фактически оставался незаданным — то есть строка, прочитанная через GET и отправленная обратно, теряла этот признак. Кто обходил это, посылая "Y" и "N" строками, ничего не заметит: такая форма принимается по-прежнему.

Если Битрикс24 отдал неполные метаданные, справочник всё равно приходит полным, но ответ дополняется предупреждением meta.warnings[].code = "fields_partial" — раньше такой ответ был неотличим от нормального. Текст предупреждения различает два случая: метаданных не пришло вовсе или не описана только часть полей (тогда он их перечисляет).

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

Ломается запись с посторонним ключом в теле. Проверьте, что при создании и правке товарной позиции вы не отправляете ничего сверх записываемых полей: своих служебных пометок, остатков внутренней модели, имён Битрикс24 в верхнем регистре (PRICE_ACCOUNT, XML_ID). Раньше такой запрос отвечал 201 Создано и молча выбрасывал значение — теперь он отвечает 400 INVALID_PARAMS и перечисляет, что принимается. Окна поддержки у прежнего поведения нет намеренно: оно и было дефектом, из-за которого заявку завели, а держать его параллельно значит держать тихую потерю данных. Полный список записываемых полей приходит в ответе на отказ и в справочнике полей.

Остальное менять не нужно. discountSum продолжает и приходить, и приниматься — перейти на discount можно без спешки, это имя приходит в самих товарных позициях, тогда как псевдоним живёт только в справочнике. Ветвитесь на isReadOnly или isRequired — сверьтесь с новыми значениями у ownerId, ownerType, customized и measureName. Заменяете строки целиком — учтите, что идентификаторы изменённых позиций меняются: перечитайте набор через GET после записи.

FIX-0810-12: подбор сотрудников по серверу больше не пустует из-за свежего ключа без доступа к Bitrix24

Было

Когда управляющий ключ сервера не давал доступа к Bitrix24, GET /v1/infra/servers/{id}/b24-users и подбор сотрудников в интерфейсе переходили к личным ключам владельца сервера, но проверяли только один — самый свежий подходящий. Если у него не было ни вебхука, ни токена установленного приложения, ответ приходил пустым (data: [] с подсказкой), хотя у владельца был другой активный ключ с нужными правами. Ключи, которые платформа выпускает сама под задачи без обращений к Bitrix24, всегда оказываются самыми свежими, поэтому подбор мог не работать постоянно.

Стало

Проверяются все подходящие личные ключи владельца, от свежего к старому, и используется первый, для которого действительно есть доступ к Bitrix24. Ключи без доступа пропускаются, к Bitrix24 по-прежнему уходит один запрос. Требования к ключу не смягчены: как и раньше, годится только активный неистёкший личный ключ владельца сервера в том же портале, не привязанный к приложению.

Заодно исправлена подсказка в поле hint: раньше она называла только неавторизованное приложение и отозванный ключ, из-за чего активный ключ выглядел отозванным. Теперь третьей причиной названо отсутствие доступа к Bitrix24 у ключей и подсказано действие — выпустить личный ключ с нужными правами. Форма ответа не изменилась.

FIX-0810-13: привязка места встраивания называет отказ в правах установки вместо общей ошибки шлюза

Было

Битрикс24 отказывал в установке встройки, и проверить состояние подписки в этот момент не удавалось — POST /v1/placements/bind отвечал 502 BITRIX_UNAVAILABLE и складывал код Битрикс24 в details. Названного кода в ответе не было, а вместе с ним и подсказки, что делать дальше. Отказ приходил и на аккаунт с оформленной подпиской.

Стало

Когда проверку выполнить не удалось, а аккаунт уже числится подписанным в Вайбкод, тот же отказ приходит как 403 B24_EMBEDDING_INSTALL_DENIED с details.remedy равным install-rights. Ссылка на оформление не передаётся: подписка есть, не хватает права ставить локальные приложения. Если действующей подписки нет ни по одному из источников, ответ остаётся 502 BITRIX_UNAVAILABLE.

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

Менять ничего не нужно. Ветка обработки 502 BITRIX_UNAVAILABLE продолжает работать для остальных отказов, а этот сценарий уходит из неё в 403. Повторять запрос в нём бессмысленно — нужно, чтобы ключ разработчика принадлежал пользователю с правом ставить локальные приложения и с доступом к приложению.

BC-0810-14: команды, выкладка и загрузка файлов по id машины-галактики больше не выполняются

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

Было

Галактика — это одна машина, на которой в контейнерах живут приложения нескольких ключей одного аккаунта Битрикс24. Список серверов отдаёт как сами приложения (kind=GALAXY_APP), так и несущую их машину (kind=GALAXY), и вызов POST /v1/infra/servers/:id/exec, POST /v1/infra/servers/:id/deploy или POST /v1/infra/servers/:id/upload с id несущей машины выполнялся на ней самой — то есть за пределами контейнера вызывающего.

Стало

Тот же вызов с id машины вида GALAXY отвечает отказом: команды — 403 GALAXY_HOST_EXEC_FORBIDDEN, выкладка и загрузка файлов — 400 GALAXY_HOST_NOT_A_DEPLOY_TARGET. Текст отказа называет замену: работать с приложением по его собственному id (kind=GALAXY_APP). Для машин вида STANDALONE и для приложений галактики ничего не изменилось.

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

Возьмите из списка серверов строку своего приложения (kind=GALAXY_APP) и обращайтесь по её id. Если сценарий опирался на доступ к самой машине ради свободного места, эта величина теперь доступна как данные, а не как результат команды.

Окна поддержки прежнего поведения нет: отказ действует с момента выката. Причина в том, что прежнее поведение открывало доступ к машине, на которой стоят контейнеры других ключей, — держать такой доступ полгода ради совместимости нельзя.

NEW-0810-15: занятость диска машины-галактики видна в списке серверов

Строка машины-галактики (kind=GALAXY) в GET /v1/infra/servers и в карточке сервера теперь несёт четыре поля: diskTotalMb и diskFreeMb — размер и свободное место в мебибайтах, diskState — оценка (ok, warning, critical или unknown, если замера ещё не было), diskProbedAt — время замера в ISO-8601.

Обе границы оценки платформа держит с запасом: warning означает «место кончается», critical — что свободного места меньше, чем платформа считает безопасным; обе зажигаются раньше, чем выкладке действительно перестанет хватать места. Замер обновляется сам, пока машина не спит; у спящей показывается последнее известное значение вместе с его временем.

Для машин вида STANDALONE и для приложений галактики (kind=GALAXY_APP) все четыре поля равны null: у первых диск не измеряется, у вторых своего диска нет.

NEW-0810-16: агентская модель bitrix/bitrixgpt-5.6-agent

GET /v1/models отдаёт новую агентскую модель bitrix/bitrixgpt-5.6-agent с контекстом 1 048 576 токенов. Модель поддерживает потоковую выдачу, вызов инструментов (tools) и структурированный ответ по схеме — response_format с type: "json_schema". Публичный идентификатор модели входит в список ai.structuredOutputs.models в ответе GET /v1/me.

Модель добавлена в каталог и ничего не заменяет: прежние вызовы работают без изменений.

Затронутые эндпоинты: GET /v1/models, POST /v1/chat/completions, GET /v1/me

NEW-0810-17: bitrix/bitrixgpt-5.5-agent помечена устаревшей

Ответы POST /v1/chat/completions на модели bitrix/bitrixgpt-5.5-agent теперь несут заголовки Deprecation: true, X-Model-Replacement: bitrix/bitrixgpt-5.6-agent и Link со ссылкой на преемника (rel="successor-version").

Модель продолжает работать без ограничений и остаётся в выдаче GET /v1/models. Дата отключения не назначена — заголовок Sunset не отдаётся, и менять в интеграции ничего не требуется. Преемник для новых интеграций — bitrix/bitrixgpt-5.6-agent.

FIX-0810-18: временный сбой транзакции базы больше не отдаёт 500 с внутренним кодом движка

Было

Если транзакция в базе закрывалась или истекала до конца операции, запрос отвечал 500 и клал в тело внутренний код движка — {"error":{"code":"P2028"}}. Кода нет ни на одной странице документации, заголовка Retry-After в ответе не было, и по ответу нельзя было понять, что запрос стоит повторить. Чаще всего это видели на DELETE /v1/apps/{id}: приложение оставалось на месте, а повтор выглядел бессмысленным.

Стало

Тот же класс отказа отвечает 503 с кодом DB_TRANSIENT, полем error.retryAfter и заголовком Retry-After — та же посадка на повтор, что у POOL_EXHAUSTED. Изменение при таком отказе не применяется ни частично, ни полностью, поэтому прямой повтор через несколько секунд безопасен. На маршрутах AI (/v1/ai/*, /v1/chat/*, /v1/audio/*, /v1/models) код приходит в нижнем регистре — db_transient — в конверте, совместимом с OpenAI. Внутренний код движка в теле ответа больше не встречается.

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

Менять ничего не нужно. Если ваш обработчик считал 500 окончательным отказом — теперь этот случай приходит как 503 с указанным сроком и попадает в вашу ветку повторов. Отдельная обработка кода DB_TRANSIENT не требуется: достаточно уважать Retry-After на любом 503.

FIX-0810-19: preserveEnv не теряет .env, если выкладка упала после очистки каталога

Было

При cleanDeploy: true вместе с preserveEnv: true существующий .env читался до очистки каталога, но записывался обратно только на шаге env — уже после установки рантайма и зависимостей. Если выкладка обрывалась раньше, POST /v1/infra/servers/:id/deploy отвечал DEPLOY_FAILED, а каталог оставался без .env совсем. Настройки приложения приходилось заливать заново.

Стало

Сохранённая копия возвращается на диск при любом обрыве выкладки после очистки — на установке зависимостей, на рантайме, на загрузке архива, на самой очистке, а также при разрыве связи с сервером. Восстановление идёт по мере возможности и не добавляет отдельного шага в ответ. Правило приоритета не изменилось: переданный в этом же запросе env по-прежнему побеждает, а явный пустой env: {} означает «очистить» и сохранённую копию не возвращает. Успешная выкладка работает как раньше, включая подстановку часового пояса для расписаний пробуждения. Флаг по-прежнему только для отдельной виртуальной машины (kind: "STANDALONE").

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

Менять на своей стороне ничего не нужно. Форма ответа DEPLOY_FAILED и набор шагов в data.steps не изменились. Если вы обходили этот дефект — заливали .env вручную после каждой неудачной выкладки — обходной путь больше не нужен.