# API changes: November 2, 2026 [← Changelog](/docs/changelog) · [November 2026](/docs/changelog/2026-11) ### FIX-1102-1: galaxy placement no longer answers 503 GALAXY_HOST_CREATING **Before** `POST /v1/infra/servers` with galaxy placement, while the application host was still being created, answered `503 GALAXY_HOST_CREATING` with a `Retry-After` header and created nothing. **After** The `503 GALAXY_HOST_CREATING` response is gone: the application is placed on the host that is still being created, and the deploy waits for it to connect, the same as for a host that is booting. There is no need to retry on `Retry-After`. When placement allows a dedicated server instead of a galaxy, a cloud refusal to create a new application host no longer redirects the application to a dedicated server: the application goes to `error`, and the platform then removes both the host and the application without waiting for scheduled cleanup. Sending the request again places the application anew. ### NEW-1102-3: deploy: the /var/lib/vibe/app-login directory is reserved by the platform For every application on a standalone server, an `extractTo` or `dataDirs` entry of `POST /v1/infra/servers/{id}/deploy` that equals or overlaps `/var/lib/vibe/app-login` fails the deploy at the `app_secrets` step with error `SECRET_DIRECTORY_RESERVED`, the same way `/var/lib/vibe/app-secrets` already did. Files and services on the machine are left untouched: choose another path and deploy again. ### NEW-1102-6: application secrets: the kind field and the SECRET_SYSTEM refusal Secret metadata in `GET /v1/applications/{id}/secrets` and `POST /v1/applications/{id}/secrets` responses now carries `kind`: `user` for a secret of the application author, `system` for a platform system secret that the platform manages itself. System secrets (`VIBE_AUTH_SECRET`, `VIBE_AUTH_SECRET_PREVIOUS`, `VIBE_AUTH_SECRET_REVOKED`) come first in the list and do not count toward the 100-name limit. Such a name cannot be created or deleted: `POST /v1/applications/{id}/secrets` and `DELETE /v1/applications/{id}/secrets/{name}` answer HTTP 409 with code `SECRET_SYSTEM`. A successful `DELETE` still returns `secret: null`. Responses for author secrets are unchanged apart from the new `kind: "user"` field. ### FIX-1102-7: API reference describes response fields per operation **Before** API reference field tables listed every field of an entity regardless of the operation. List and search cards showed fields the rows of a list never carry, and fields outside the default selection were presented as returned. The nullable marker was lost: a field that can come back as `null` was described with a plain scalar type. **After** A field table describes the same projection as the response example below it: a list or search card shows the fields of a list row, a record card shows the fields of a single answer, a creation or update card shows the fields of the re-read record. Fields an operation never returns are out of the table; they stay in the entity field metadata card with their existing flags. Nullable fields are described as `T|null`. **Impact on integrators** API behavior and response examples are unchanged. The tables describe what a particular operation returns more accurately. ### NEW-1102-8: The `.vauth/` directory of the application database is reserved The application database methods — [reads](/docs/infra/database/query), [changes](/docs/infra/database/execute), [copies](/docs/infra/database/snapshot) and [restore](/docs/infra/database/restore) — return `400 APP_DB_PATH_RESERVED` when the database path in `file` or in the container's `VIBE_DB_PATH` leads into the `.vauth/` directory inside `/data`, in any letter case. Reads and changes refuse the same way for a path through a symbolic link. The platform keeps the application's sign-in data in this directory. Paths outside `.vauth/` work as before. ### BC-1102-9: VibeCode Connect withholds a write-enabled app key when the Bitrix24 account issues new keys as read-only > Old format supported until: not provided **Before** VibeCode Connect consent issued the application a key in read-and-write mode regardless of the Bitrix24 account setting that issues new keys as read-only. An employee could connect an application that the account policy did not permit. **After** When the Bitrix24 account issues new keys as read-only, consent no longer issues a write-enabled key to a partner application. The consent page shows the refusal with code `KEY_POLICY_READONLY_REQUIRED` and asks the user to have the account administrator enable read and write. The account administrator still receives the key. The key mode is not narrowed silently: the application gets an explicit refusal instead of a reduced key. **What integrators should do** If your application runs on Bitrix24 accounts where new keys are issued as read-only, ask the administrator of that account to enable read and write. If the application only needs reads, request just the scopes it needs and agree the account policy with the administrator. ### NEW-1102-10: MCP package 3.4.0: HTTP mode, system secrets and access guidance In `@bitrix24/mcp-vibecode-api` 3.4.0, HTTP mode (`--http`) is fixed: the server rejected every request carrying the correct token with `400 Parse error`, and now handles them. The request body size limit is kept; an oversized body gets `413`. The application secrets tool shows the kind of each entry, user or system (`kind`). System secrets are created by the platform: they cannot be created or deleted through MCP, and such an attempt returns `SECRET_SYSTEM`. MCP still never accepts or returns secret values. Infrastructure access guidance explains access by Bitrix24 plan and restricted access during a trial plan. It explains the `INT_TARIFF_REQUIRED` and `TRIAL_EXPIRED` codes, separates balance top-up from plan access and clarifies when bringing your own AI key helps. The entity reference describes end-to-end analytics methods through REST v3: traces, sources, channels, manual expenses, source analytics and advertising accounts. The methods roll out with a Bitrix24 update and become available once the feature is enabled for the account; until then a call reports that the method is not yet available. The minimum version of the `undici` dependency is raised to 7.30.1. Upgrade the package and restart the MCP session to load the new guidance. ### FIX-1102-11: bot registration answers 409 instead of 502 when the connection drops after creation **Before** When Bitrix24 had already created the bot and the connection dropped on a later check of the registration, [POST /v1/bots](/docs/bots/management/create) could answer `502 BITRIX_UNAVAILABLE` with a hint that the write might not have reached Bitrix24. The registration then completed in the background, and the client did not know the bot already existed. **After** In this case the answer is `409 BOT_EFFECT_IN_PROGRESS` with a `Retry-After` header, as for any registration that is still being reconciled. A retry with the same code or a call to [POST /v1/bots/registrations/{code}/recover](/docs/bots/management/registrations-recover) returns the ID of the created bot. **Impact on integrators** A client that already handles `409 BOT_EFFECT_IN_PROGRESS` as documented changes nothing. A retry with a new code after this answer is not needed. ### FIX-1102-12: AI call statistics cost excludes calls covered by the quota or a subscription **Before** In the [GET /v1/ai/usage](/docs/ai/consumption/usage) response, `totals.cost`, `byModel[].cost` and `recentCalls[].cost` included the price of calls covered by the company AI quota or a Cowork subscription, although nothing was debited for them. Over-quota calls counted at the catalog price rather than the amount actually debited. **After** The `cost` fields show the Vibe credits charged for the calls. Calls covered by the company AI quota or a Cowork subscription count as `0`, and over-quota calls count at the amount actually debited. Calls paid from the wallet count at the catalog price, with debits made once a day. The debit can be lower when an agent free token allowance applies. BYOK counts as `0`. **Impact on integrators** Field names and types are preserved, and call and token counts are unchanged. If your integration summed `cost` as spend, the total now matches the charges. If `cost` served as an estimate of consumption volume at catalog prices, use `calls` and tokens for that. ### NEW-1102-13: partner account indicator in Cowork snapshots Successful responses from `GET /v1/cowork/me` and `GET /v1/cowork/state` include `portal.isPartner`, a boolean indicating a partner (NFR) Bitrix24 account. The field is present for free and paid seats; if the account record is missing or deleted, its value is `false`. ### FIX-1102-14: Command output truncation flag in Galaxy **Before** Synchronous [POST /v1/infra/servers/:id/exec](/docs/infra/deploy/exec) for `GALAXY_APP` returned `truncated: false` even when the agent reported truncated output. **After** The response returns `truncated: true` when the agent reports truncation. The shared `stdout` and `stderr` limit remains 1 MiB. Older agents may omit the flag; for those agents, `false` does not guarantee complete output. ### FIX-1102-15: public model self-description is hidden in AI Router reasoning **Before** In a [POST /v1/chat/completions](/docs/ai/chat/completions) response, a `bitrixgpt-*` model could name its base model in `reasoning_content`, although the name was already hidden in `content`. **After** In recognized statements where the public model describes itself, the name of its hidden base is also masked in `reasoning_content` of regular and streaming responses. Informational mentions of other models without self-description remain unchanged. **Impact on integrators** The response format and successful status are preserved; no client changes are required. ### FIX-1102-16: Key issuance refusal on a cloud RU account no longer names the plan as the cause **Before** When Bitrix24 refused key issuance with `FEATURE_NOT_AVAILABLE_ON_CURRENT_PLAN` on a cloud Bitrix24 account in region RU that is on a paid plan with an active subscription, [POST /v1/keys](/docs/management-keys/create) answered `502 CONNECTOR_PLAN_REQUIRED` with text saying the plan does not include Vibecode. That claim contradicted what the account owner saw: the plan is paid, the subscription is live, and the vendor named no cause. **After** For this refusal on any cloud account classified by the platform as region RU, the answer stays `502`, but the code is neutral — `CONNECTOR_KEY_ISSUE_FAILED` — and `userMessage` asks to retry. This branch does not depend on whether the plan is paid or on subscription status. A successful issuance remains successful. Keep the `CONNECTOR_PLAN_REQUIRED` branch: for the same refusal, `502 CONNECTOR_PLAN_REQUIRED` still applies to self-hosted installations in any region and to cloud accounts where the Vibe+ line is not offered, including accounts on a paid plan. Where the platform does offer the Vibe+ upgrade, the answer is `402 INT_VIBE_PLUS_REQUIRED` regardless of whether the plan is paid. If the region cannot be determined, the international rules apply. **Affected endpoints:** [POST /v1/keys](/docs/management-keys/create), [POST /v1/keys/{id}/rotate](/docs/management-keys/rotate), [POST /v1/apps](/docs/apps/create) ### BC-1102-17: Personal server limit > Old format supported until: not provided **Before** [POST /v1/infra/servers](/docs/infra/servers/create) checked only the account-wide servers-per-user limit for the current Bitrix24 account. **After** If an administrator sets a stricter personal limit for the API key owner and that limit is exhausted, [POST /v1/infra/servers](/docs/infra/servers/create) returns `403 MAX_SERVERS_REACHED` even when the account-wide limit still has room. Without a personal setting, the account-wide limit continues to apply. The request format and existing rejection code are unchanged; existing servers are not deleted. **What integrators should do** On `403 MAX_SERVERS_REACHED`, confirm the personal limit with the account administrator, free a server slot, or arrange a higher limit.