API changes: October 12, 2026

← Changelog · October 2026

FIX-1012-1: Clear guidance when the server management service is unreachable

Before

When the server management service experienced a transport failure, POST /v1/infra/servers/{id}/reboot for a galaxy host returned the GENERIC category, and GET /v1/infra/servers/{id}/repair-status could contain only fetch failed in data.error.

After

The galaxy host reboot response contains TRANSPORT_UNAVAILABLE in error.category when a transport failure has no more specific error diagnosis. The repair status contains clear English guidance in data.error: the server management service is unreachable; retry in a few minutes. The same text includes a six-character incident code.

Impact on integrators

HTTP status codes and response shapes are unchanged. Handle the new TRANSPORT_UNAVAILABLE category when processing error.category. The data.error text is intended for display to users.

NEW-1012-2: Batch reads of catalogs and storages are discoverable in OpenAPI

The existing POST /v1/catalogs/batch and POST /v1/storages/batch methods are now described in OpenAPI and the API reference so agents can discover them. Catalog batches return data for list and get; the accepted fields action returns an empty object because catalogs have no Bitrix24 field-schema method. Storage batches return data for list, get and fields.

A request selects one action and sends a non-empty calls array (up to 50 calls by default). Calls execute sequentially; each result contains data or an error. The response remains HTTP 200 when an individual call fails.

NEW-1012-3: Company connectors for an application key

A Vibecode application key with the vibe:connectors scope can call tools of the shared connections of a Bitrix24 account. GET /v1/connectors returns the connector catalog, POST /v1/connectors/mcp calls tools, GET /v1/connectors/write-tickets/{id} returns the outcome of a write confirmation, and GET /v1/me returns a data.connectorHost block for an admitted key. The scope is granted only explicitly and is not part of the default set. The application sees only company connections, under the permissions of the key owner. The owner confirms writes in the web cabinet, and paid calls are charged to the account balance. While the feature is not enabled for the Bitrix24 account, routes return 404 ROUTE_NOT_FOUND. When it is enabled, a disallowed key, route or operation receives 403 CONNECTOR_KEY_NOT_ALLOWED.

BC-1012-4: The vibe:storage scope is not granted to Partner Connect applications

Old format supported until: not provided

Before

A Partner Connect application could obtain vibe:storage the same way as vibe:search, vibe:infra and vibe:feedback: a platform administrator granted the scope to a verified application, and it then landed on the key through user consent.

After

vibe:storage is not granted to a Connect application. A key issued through Connect lands in the same storage area as the personal keys of the connecting user, so with this scope the application would see every file uploaded with that user's personal keys. Requesting the scope at application registration is still rejected with SCOPE_NOT_ALLOWED, and a platform administrator no longer grants it to a Connect application. The change is already in effect. No Connect application held this scope, so no support period is provided for the previous procedure.

What integrators should do

Do not plan file storage on a Connect key, and do not ask for vibe:storage in a verification request. Bitrix24 scopes, vibe:ai and the scopes a platform administrator grants work as before.

FIX-1012-5: A vibe:storage scope refusal on a Partner Connect key no longer suggests an administrator grant

Before

When a key issued through Partner Connect lacked vibe:storage, the 403 refusal with cause key_scope_missing advised in error.hint: if a platform administrator had not yet granted the scope to the application, the administrator grants it first, then the application requests it and walks the user through consent again. error.userMessage said the same: the developer has to request the scope and ask for the user's consent again.

After

In this case error.fix is { "action": "none", "via": "platform" }. error.hint says that vibe:storage is not available to Partner Connect applications — neither through re-consent nor from a platform administrator. error.userMessage says the scope cannot be added to this key. The refusal code, status and message are unchanged, and the other scopes of a Partner Connect key respond as before. Details are in Authorization, keys and permissions.

Impact on integrators

No action is required. If your code started a new consent round on this refusal, it no longer gets that advice for vibe:storage: the scope is not granted to a Connect key.

NEW-1012-6: refusal outcomes for COMPANY clients

Issuance for Partner Connect clients in COMPANY mode is currently closed: /v1/connect/authorize returns to the registered callback with access_denied and CONNECT_COMPANY_DISABLED or CONNECT_COMPANY_NOT_READY, without an authorization code. Authorization-code exchange at /v1/connect/token returns HTTP 403 with the same code. Starting or exchanging a device code is rejected with HTTP 400 and CONNECT_COMPANY_DEVICE_FLOW_FORBIDDEN. The existing PERSONAL mode continues to work.

NEW-1012-7: Refusal codes for company connections

Partner Connect documents HTTP 403 codes for COMPANY connections: CONNECT_COMPANY_STORAGE_NOT_READY for storage and CONNECT_COMPANY_DERIVED_TOKEN_FORBIDDEN for derived tokens and keys. OpenAPI publishes the refusal code and HTTP status separately for COMPANY. Issuance of COMPANY connections remains closed with CONNECT_COMPANY_NOT_READY.

FIX-1012-8: Consistent refusal for closed company connection issuance

Before

Closed Partner Connect issuance in COMPANY mode returned either CONNECT_COMPANY_DISABLED or CONNECT_COMPANY_NOT_READY.

After

GET /v1/connect/authorize and POST /v1/connect/token return the single code CONNECT_COMPANY_NOT_READY for closed issuance in COMPANY mode. Issuance remains unavailable.

FIX-1012-9: a busy app upload path allows retrying the deploy

Before

When another upload owned the source path, POST /v1/infra/servers/:id/deploy returned 502 GALAXY_APP_BUILD_FAILED and marked the app error.

After

The response is 409 GALAXY_UPLOAD_BUSY, error.retryable: true, error.retryAfter: 10, error.hint and a Retry-After: 10 header. The app status is preserved. Wait at least 10 seconds and retry the same request for the same app. If the build started in the background through POST /v1/infra/servers with source, a new app initially remains provisioning, and GET /v1/infra/servers/:id shows a buildHint recommending another deploy. After 20 minutes and the next check within another 5 minutes, a stuck attempt changes to error, preserving the busy-path reason and hint. Retry the same deploy in this state too: a new attempt returns the slot to provisioning, preserving the /data contents. A source build started after server creation is not retried automatically. Hermes retries its upload no sooner than after 3 minutes; the existing 30-minute wait limit ends the attempt while retaining the busy-path reason and hint. The activity feed shows the busy-path reason. No app deletion or lock release is needed.

NEW-1012-10: Company connection status polling

GET /v1/connect/company/status returns the state of your own connection using its COMPANY credential, state and credential versions, capabilities and the next action. Responses contain no personal data, secrets or URLs and prohibit caching. STATUS_ONLY credentials can read diagnostics. Rate-limit responses include Retry-After. Bitrix24, AI and files remain closed.

NEW-1012-11: App hosting marker in app responses

GET /v1/apps, GET /v1/apps/{id} and the other responses carrying the app object, such as POST /v1/apps and POST /v1/apps/{id}/relink-oauth, return three new fields. hosting tells where the app runs: platform — on a platform server linked to the app or owned by this Bitrix24 account, or on that server's verified own domain, or the app has no address at all, platform-orphan — an address on a platform subdomain with no live server, external — any other address, including a platform server of another Bitrix24 account. externalHost is the host name for external, otherwise null; an external address without a host also gets null. externalRegistrable is the registrable domain of that host, otherwise null.

The appUrl field is unchanged.

BC-1012-12: datetime filters preserve the explicit time zone

Old format supported until: not provided

Before

Vibe API date filters removed Z or a numeric offset without adjusting the clock. An updatedAt value copied from a response into $gte could specify a different instant; batched windows also lost their zone and fractional seconds.

After

Explicit Z/offset and fractional seconds reach Bitrix24 intact, including in batched windows. 2026-10-05T19:20:22.000Z and 2026-10-05T22:20:22.000+03:00 specify the same instant. Naive values and YYYY-MM-DD keep Bitrix24 local-time semantics in automatic windows too: previously the default windows sent them as a UTC instant, and on a UTC+3 account the first hours of the range were dropped. X-Vibe-Timezone affects writes only. A range mixing a local bound and a zoned bound runs without automatic windowing. When automatic windowing is enabled, the search returns DATE_WINDOWING_SKIPPED in meta.warnings: results on Bitrix24 methods that filter after pagination may be incomplete. Use explicit zones on both bounds to enable windowing.

What integrators should do

Pass the response value without adjusting the clock; remove any manual compensation for the old suffix removal from your integration.

BC-1012-13: Application deletion requires confirmed container removal

Old format supported until: not provided

Before

DELETE /v1/infra/servers/:id for an application on a host reporting GUEST_NOT_BOOTING could succeed by deleting only the record and binding, leaving its container on the unavailable host.

After

unconfirmed container removal returns 502; the record and binding remain available for retry. Confirmed host deletion also permits cleanup of its applications. The previous behavior is removed without a support window because it allowed a running container to survive application deletion.

What integrators should do

treat 502 as incomplete deletion. Retain the application ID, restore host availability and retry DELETE, or contact support for confirmed host deletion. Do not treat the resource as deleted until a successful response.

NEW-1012-14: Retryable refusal while a server binding is busy

DELETE /v1/infra/servers/:id can return 409 REISSUE_IN_PROGRESS while the application key or its server binding is busy, for example with key rotation or secret delivery. This request deleted nothing; retry shortly. The same code from POST /v1/infra/servers means that no new machine was created and the request can be retried after the concurrent operation finishes.

NEW-1012-15: Management keys are available in OpenAPI

OpenAPI and the VibeCode API reference now describe seven existing management key operations: GET /v1/keys, POST /v1/keys, GET /v1/keys/{id}, PATCH /v1/keys/{id}, DELETE /v1/keys/{id}, POST /v1/keys/{id}/rotate and GET /v1/portals.

Agents and client generators can discover parameters, responses, refusals and the calling key's required scopes. The operations are available in the vibe:mgmt:keys and vibe:mgmt:portals slices. The secret is returned once during creation or rotation, while reads and lists contain only safe metadata. Key issuance timeouts now return 503 instead of 504, like other platform timeouts, and you should still avoid retrying immediately. Regenerate your client from the current specification to add these methods.

NEW-1012-16: Scheduled HTTP calls

Server jobs can now call an application's HTTP handler on a schedule: GET /v1/infra/servers/:id/jobs lists jobs, POST /v1/infra/servers/:id/jobs creates a job, PATCH /v1/infra/servers/:id/jobs/:jobId replaces settings, DELETE /v1/infra/servers/:id/jobs/:jobId deletes a job, POST /v1/infra/servers/:id/jobs/:jobId/run starts a manual run, GET /v1/infra/servers/:id/jobs/:jobId/runs lists run history, and POST /v1/infra/servers/:id/jobs/:jobId/rotate-secret replaces the secret.

Handler calls are signed; retries of one run keep the same runId, and the history shows the result and attempts. Configuration is also available through the MCP tool manage_server_jobs. Documentation.

NEW-1012-17: Clear chat history for the caller or everyone

POST /v1/chats/:dialogId/history/clear requires scope: self clears history for the caller, all for everyone. The chat is retained. The im scope and write access are required. Bitrix24 authorizes the operation.

Clearing history returns data.result: true only after explicit confirmation. Missing confirmation produces 502 BITRIX_UNAVAILABLE.

FIX-1012-18: Confirmation of chat deletion

Before

DELETE /v1/chats/:dialogId could report success without explicit deletion confirmation from Bitrix24.

After

The response to a confirmed deletion still has status 200 and contains data.result: true. Missing confirmation produces 502 BITRIX_UNAVAILABLE. The request is not replayed automatically after a 503 response from Bitrix24.

Impact on integrators

Check the chat state before retrying manually after 502: the operation may already have changed data. The successful response to a confirmed deletion is unchanged.

FIX-1012-19: application files stay available after a key reissue and an application transfer

Before

An application key saw in storage only the files written by the owner of that key. After the application's authorization key was reissued or the application was transferred to another employee, the new key answered 404 STORAGE_OBJECT_NOT_FOUND for previously uploaded files, and the object list did not show them. Uploading again under the same key answered 409 STORAGE_KEY_OWNED_ELSEWHERE.

After

Files belong to the application. An application key reads, lists and overwrites every file of its application, whoever uploaded it, including after a key reissue and an application transfer. GET /v1/storage/objects/{key} again answers with a redirect to such a file. An employee's files inside the application remain available only with that employee's token. Personal developer keys work as before.

Impact on integrators

No action is needed. After an application transfer the earlier files are visible right away, including for transfers made before. Files are kept across a reissue for keys reissued after this fix.