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

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

### FIX-0718-1: деплой переиспользует сервер приложения вместо создания дубликата

**Было**

`POST /v1/infra/servers` c `source` всегда создавал новый сервер, даже если у приложения, которому принадлежит ключ, уже был сервер — на счёт заводился второй, простаивающий. А `POST /v1/infra/servers/:id/deploy` отвечал `WRONG_KEY`, если ключ вызова отличался от того, которым сервер был создан (например, у приложения есть личный ключ и ключ авторизации).

**Стало**

Если ключ вызова принадлежит приложению, у которого уже есть живой сервер, `POST /v1/infra/servers` возвращает этот сервер с полем `reused: true` вместо создания нового. Если в том же запросе передан `source`, а переиспользуемый сервер — это приложение галактики (`kind: "GALAXY_APP"`), **у которого ещё нет работающего контейнера** (ни разу не деплоилось или прошлый деплой упал), исходный код сразу разворачивается в его собственный сервер (ответ содержит `reused: true` и `deploying: true`, а статус сервера на время сборки — `provisioning`) — так же, как при обычном create с `source`: опрашивайте `GET /v1/infra/servers/:id` до статуса `running`, второй вызов деплоя не нужен. Если же приложение галактики **уже работает**, ответ содержит `reused: true` и `next: "deploy"` — разверните исходный код отдельным вызовом `POST /v1/infra/servers/:id/deploy` (так живой контейнер не затрагивается на время сборки). Для обычного сервера или запроса без `source` ответ содержит `reused: true` и `next: "deploy"` — разверните исходный код отдельным вызовом `POST /v1/infra/servers/:id/deploy`. `POST /v1/infra/servers/:id/deploy` теперь принимает любой ключ этого же приложения и деплоит в его сервер.

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

Ничего менять не нужно. Дубликаты серверов больше не создаются. Раньше one-shot create с `source` на уже существующий сервер приложения возвращал `next: "deploy"` и терял переданный `source` — теперь исходный код разворачивается сразу. И деплой, и чтение статуса (`GET /v1/infra/servers/:id`) сервера приложения работают под любым ключом этого приложения — независимо от того, каким из них вы вызываете API.

### FIX-0718-2: DELETE /lock снимает зависший лок и на удалённом сервере

**Было**

[`DELETE /v1/infra/servers/:id/lock`](/docs/infra/deploy/lock) возвращал `404 NOT_FOUND`, если сервер был удалён — даже когда лок операции остался в памяти платформы и продолжал держать сервер. Из-за этого сценарий «предыдущий сервер удалён, лок завис, следующий деплой падает с `EXEC_BUSY`» не имел выхода: снять такой лок через API было нельзя.

**Стало**

`DELETE /lock` снимает зависший лок и на удалённом сервере — при условии, что он всё ещё принадлежит вашему API-ключу (владение остаётся единственной проверкой; лок не хранит данных и не держит облачных ресурсов). Успешный вызов возвращает `200` с `data.released: true`. `404 NOT_FOUND` теперь означает только «сервер не существует или принадлежит другому ключу».

### NEW-0718-3: коды ошибок коннектора при установке приложения теперь возможны и на облачных порталах (поэтапная раскатка)

[POST /v1/apps](/docs/apps) на облачном портале теперь тоже может устанавливать приложение через модуль `vibecodeconnector` и, соответственно, возвращать те же коды ошибок коннектора, что раньше были возможны только на коробочных порталах: `403 CONNECTOR_APP_INSTALL_FORBIDDEN` (администратор портала Битрикс24 запретил пользователю установку приложений), `409 CONNECTOR_MODULE_NOT_INSTALLED` (модуль `vibecodeconnector` не установлен на портале) и `502 CONNECTOR_APP_INSTALL_FAILED` (прочие сбои установки). Изменение аддитивное: ответ при успешной установке не изменился, а раскатка идёт поэтапно — на большинстве облачных порталов путь установки пока прежний. Клиентам, которые уже обрабатывают эти коды на коробочных порталах, менять ничего не нужно; клиентам, которые их не обрабатывали, стоит добавить обработку.