# API changes: July 18, 2026

[← Changelog](/docs/changelog) · [July 2026](/docs/changelog/2026-07)

### FIX-0718-1: deploy reuses the application's server instead of creating a duplicate

**Before**

`POST /v1/infra/servers` with `source` always created a new server even when the application that owns the key already had one — a second, idle server was billed. And `POST /v1/infra/servers/:id/deploy` returned `WRONG_KEY` when the calling key differed from the one that created the server (for example, an application has both a personal key and an authorization key).

**After**

When the calling key belongs to an application that already has a live server, `POST /v1/infra/servers` returns that server with `reused: true` instead of creating a new one. If the same request carries `source` and the reused server is a galaxy app (`kind: "GALAXY_APP"`) **that has no running container yet** (never deployed, or its previous deploy failed), the source is deployed to its own server right away (the response carries `reused: true` and `deploying: true`, and the server's status is `provisioning` while the build runs) — just like an ordinary create with `source`: poll `GET /v1/infra/servers/:id` until status is `running`, no second deploy call is needed. If the galaxy app is **already serving**, the response carries `reused: true` and `next: "deploy"` — deploy your source with a separate `POST /v1/infra/servers/:id/deploy` call (so the live container is untouched while the build runs). For a plain server, or a request without `source`, the response carries `reused: true` and `next: "deploy"` — deploy your source with a separate `POST /v1/infra/servers/:id/deploy` call. `POST /v1/infra/servers/:id/deploy` now accepts any key of the same application and deploys to its server.

**Integrator impact**

No changes required. Duplicate servers are no longer created. Previously a one-shot create with `source` against an application's existing server returned `next: "deploy"` and dropped the supplied `source` — now the source is deployed right away. Both a deploy and a status read (`GET /v1/infra/servers/:id`) of the application's server work under any of the application's keys, regardless of which one you call the API with.

### FIX-0718-2: DELETE /lock now releases a stuck lock even on a deleted server

**Before**

[`DELETE /v1/infra/servers/:id/lock`](/docs/infra/deploy/lock) returned `404 NOT_FOUND` when the server had been deleted — even though the operation lock remained in the platform's memory and kept the server busy. So the "previous server deleted, lock stuck, next deploy fails with `EXEC_BUSY`" scenario had no way out: such a lock could not be released via the API.

**After**

`DELETE /lock` releases a stuck lock even on a deleted server — as long as it still belongs to your API key (ownership remains the only check; the lock holds no data and no cloud resources). A successful call returns `200` with `data.released: true`. `404 NOT_FOUND` now means only "the server does not exist or belongs to another key".

### NEW-0718-3: connector app-install error codes are now also possible on cloud portals (phased rollout)

[POST /v1/apps](/docs/apps) on a cloud portal can now also install the application through the `vibecodeconnector` module and therefore return the same connector error codes that were previously only possible on self-hosted portals: `403 CONNECTOR_APP_INSTALL_FORBIDDEN` (the Bitrix24 portal administrator forbade the user from installing applications), `409 CONNECTOR_MODULE_NOT_INSTALLED` (the `vibecodeconnector` module is not installed on the portal), and `502 CONNECTOR_APP_INSTALL_FAILED` (other install failures). The change is additive: the successful-install response is unchanged, and the rollout is phased — on most cloud portals the install path is unchanged for now. Clients that already handle these codes on self-hosted portals need no change; clients that did not should add handling.