API changes: October 11, 2026

← Changelog · October 2026

BC-1011-1: Interrupted key issuance retains its quota slot

Old format supported until: not provided

Before

A key from interrupted issuance could be excluded from the key limit. DELETE /v1/keys/{id} returned 204 No Content even when deletion was incomplete.

After

A key from unfinished issuance occupies a slot until successful activation or confirmed deletion. DELETE /v1/keys/{id} returns 502 BITRIX_UNAVAILABLE if deletion of that key is not confirmed. The key and its slot are retained. Confirmed deletion returns 204 No Content. Ordinary revoked keys still release their slots.

What integrators should do

Handle 502 BITRIX_UNAVAILABLE as incomplete deletion: once availability is restored, retry DELETE /v1/keys/{id}. The slot remains occupied until 204 No Content is returned. The previous successful response for unconfirmed deletion is no longer supported.

BC-1011-2: Protecting servers during an active move to a Galaxy

Old format supported until: not provided

Before

DELETE /v1/infra/servers/:id could delete the source or destination of an active move to a Galaxy. Deleting the destination during switching could destroy the custom domain and leave the application without either server.

After

DELETE /v1/infra/servers/:id returns 409 GALAXY_MOVE_ACTIVE when the server is the source or destination of an active move to a Galaxy. This refusal leaves the server and its custom domain intact. POST /v1/infra/servers with graduateFrom pointing at an active move destination also returns 409 GALAXY_MOVE_ACTIVE before creating a new VM. When another operation temporarily holds the source, the response is 409 APPLICATION_OP_IN_PROGRESS; retry shortly. The previous behavior is disabled immediately to protect data.

What integrators should do

On GALAXY_MOVE_ACTIVE, stop automatic retries of deletion or creation with graduateFrom until the active move conflict is cleared. Once it is cleared, retry the original request. APPLICATION_OP_IN_PROGRESS means a temporary operation conflict; retry later. A refusal does not confirm server deletion or VM creation.

BC-1011-3: Galaxy app builds are limited to half of the host memory

Old format supported until: not provided

Before

A galaxy app image build on POST /v1/infra/servers/{id}/deploy had no memory limit. A heavy build, such as compiling native dependencies, could take all of the galaxy host memory. The host then stopped responding together with the neighbouring apps, and the deployment ended without a result.

After

A build is limited to half of the galaxy host memory. A build that runs out of that memory ends with a 502 GALAXY_APP_BUILD_FAILED response, the category field of the error object carries the new value BUILD_OOM, and the buildHint explains the cause. The neighbouring apps on the host keep running. The category is set only when the build stopped on running out of memory: failures caused by a timeout, disk space or unavailable package catalogs keep their existing categories. The failure is terminal, the platform does not retry the deployment.

What integrators should do

If a deployment returns BUILD_OOM, reduce the memory the build uses: prepare heavy compilation ahead of time and pass ready artifacts to the deployment instead of building them on the host. Or choose a galaxy plan with more memory — the build limit grows with it.

NEW-1011-4: Application secret delivery during deployment

POST /v1/infra/servers/:id/deploy delivers configured application secrets to the runtime environment. A secret with a value takes precedence over the matching env field; a name without a value does not override env. The platform sets PORT. The install and preStart commands do not receive secrets.

The warnings array reports ignored env values and secrets whose owner has not set a value yet. Warnings contain names only, without secret values.

On a standalone server, secrets are stored outside the application directory. The extractTo and dataDirs paths must not overlap /var/lib/vibe/app-secrets: the directory itself, its parents and descendants are forbidden. See the deployment documentation for connection details, including systemd:false.

NEW-1011-5: CRM record activities are available in the API reference

Eight working methods are now published in OpenAPI and the Vibecode API reference: GET and POST /v1/deals/{id}/activities, /v1/leads/{id}/activities, /v1/contacts/{id}/activities and /v1/companies/{id}/activities. Agents can discover their contracts, parameters and examples.

New guides cover listing activities for a CRM record and creating an activity for a CRM record. The URL selects the owner, and creation returns only the ID. The main /v1/activities endpoint remains the primary entry point for filters and sorting.