API changes: November 2, 2026

← Changelog · November 2026

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, changes, copies and 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 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 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 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 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 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 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, POST /v1/keys/{id}/rotate, POST /v1/apps

BC-1102-17: Personal server limit

Old format supported until: not provided

Before

POST /v1/infra/servers 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 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.