# API changes: October 12, 2026 [← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10) ### 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](/docs/infra/lifecycle/reboot) for a galaxy host returned the `GENERIC` category, and [GET /v1/infra/servers/{id}/repair-status](/docs/infra/lifecycle/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](/docs/connectors-host) returns the connector catalog, [POST /v1/connectors/mcp](/docs/connectors-mcp) calls tools, `GET /v1/connectors/write-tickets/{id}` returns the outcome of a write confirmation, and [GET /v1/me](/docs/keys-auth/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](/docs/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](/docs/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](/docs/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](/docs/errors/auth). **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](/docs/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](/docs/partner-connect#company-connection-polling) 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](/docs/apps/list), [GET /v1/apps/{id}](/docs/apps/get) and the other responses carrying the app object, such as [POST /v1/apps](/docs/apps/create) and [POST /v1/apps/{id}/relink-oauth](/docs/apps/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](/docs/management-keys) operations: [GET /v1/keys](/docs/management-keys), [POST /v1/keys](/docs/management-keys), [GET /v1/keys/{id}](/docs/management-keys), [PATCH /v1/keys/{id}](/docs/management-keys), [DELETE /v1/keys/{id}](/docs/management-keys), [POST /v1/keys/{id}/rotate](/docs/management-keys) and [GET /v1/portals](/docs/management-keys). 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](/docs/infra/jobs/list) lists jobs, [POST /v1/infra/servers/:id/jobs](/docs/infra/jobs/create) creates a job, [PATCH /v1/infra/servers/:id/jobs/:jobId](/docs/infra/jobs/update) replaces settings, [DELETE /v1/infra/servers/:id/jobs/:jobId](/docs/infra/jobs/delete) deletes a job, [POST /v1/infra/servers/:id/jobs/:jobId/run](/docs/infra/jobs/run) starts a manual run, [GET /v1/infra/servers/:id/jobs/:jobId/runs](/docs/infra/jobs/runs) lists run history, and [POST /v1/infra/servers/:id/jobs/:jobId/rotate-secret](/docs/infra/jobs/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](/docs/infra/jobs). ### NEW-1012-17: Clear chat history for the caller or everyone [POST /v1/chats/:dialogId/history/clear](/docs/chats/management/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](/docs/chats/management/delete) 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](/docs/storage/objects/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}](/docs/storage/objects/get) 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.