API changes: July 18, 2026

← Changelog · July 2026

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 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 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.