# API changes: October 11, 2026

[← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10)

### 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}](/docs/management-keys) 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`](/docs/infra/servers/delete) 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`](/docs/infra/servers/delete) 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`](/docs/infra/servers/create) 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](/docs/infra/deploy/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](/docs/infra/deploy/deploy#application-secrets) 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](/docs/entities/activities/owner-list) and [creating an activity for a CRM record](/docs/entities/activities/owner-create). 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.