# API changes: October 16, 2026 [← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10) ### BC-1016-1: File access after an application transfer > Old format supported until: not provided **Before** The previous application owner could read files they had written using a personal developer key after transferring the application. **After** Application files are accessible through a personal key only to the current application holder. The previous owner receives 404 and no longer sees these files in listings. Employee files retain the additional file-owner restriction. Personal developer files remain accessible. **What integrators should do** After transferring an application, access its files with the current holder’s personal key or the application key. The previous access is removed immediately to enforce authorization. ### FIX-1016-2: a catalog launch offers authorization for a personal-key server too **Before** The "Authorize the app" screen on a Bitrix24 catalog launch appeared only when the server ran on an app key. A server on a personal key started without a session even though the platform found its app by the server address: the gateway did not set `X-Vibe-Authorization`, and API calls answered `401`. The same user opened the app from a menu placement without errors. **After** When a personal-key server has exactly one app of the key owner pointing at this server and that app has a registered OAuth application, a user without access sees the same "Authorize the app" screen as on an app key. After authorizing, the app opens with a session. When there are several such apps or nothing to authorize against, the launch behaves as before, without a session. **Impact on integrators** No code changes are required. A personal-key app that does not need the session now asks the user to authorize it once, on the first catalog launch. ### FIX-1016-3: server prices reflect the current platform price list **Before** Server catalogs and cards could show the standard plan price without the payer's individual pricing terms. **After** Catalog and card prices now come from the current platform price list, including individual pricing terms. An existing server's card shows its owner's price. A fallback price applies when the plan has no price-list entry. **Impact on integrators** Requests require no changes. Response fields and the `currency` unit are preserved. ### FIX-1016-4: User and site creation field metadata corrected **Before** [GET /v1/users/fields](/docs/entities/users/fields) did not mark `email` as required on create. [GET /v1/sites/fields](/docs/entities/sites/fields) did not mark `title` or `code`. The OpenAPI request schemas also omitted these requirements. **After** The `/fields` responses mark these fields with `required: true`. The [POST /v1/users](/docs/entities/users/create) and [POST /v1/sites](/docs/entities/sites/create) schemas require their presence. The site creation schema allows an empty string or `null` for `code`. PATCH schemas remain partial. **Impact on integrators** Working requests need no changes. Client and form generators can now read the creation requirements from machine metadata. ### FIX-1016-5: Replacement authorization keys follow the application owner **Before** An authorization key could belong to another user while the application kept its previous owner. Requests using the key were attributed to that user; the key's permissions and lifecycle depended on that account. **After** An authorization key issued as a replacement belongs to the active application owner. Requests using it follow that owner's permissions, including access to ERP. The new key's lifecycle is tied to the application owner. After the key is replaced, the previous secret no longer authorizes new requests. Previously issued keys are not migrated automatically. ### BC-1016-6: Public storage rejects executable MIME types with parameters > Old format supported until: not provided **Before** `/v1/storage/objects/multipart/create` could accept a public object with `Content-Type: text/html; charset=utf-8` and return a successful response. The object could then be served through a public link. **After** Public uploads with executable MIME types return HTTP 415 even when the MIME type has parameters. Reads of previously stored unsafe public objects return HTTP 404. Private objects and safe MIME types continue to work. **What integrators should do** Use a safe MIME type for public objects. If an executable type is required, keep the object private. ### FIX-1016-7: CRM document download no longer returns the Bitrix24 response text instead of the file **Before** When Bitrix24 answered the document link with JSON instead of a file, `GET /v1/crm-documents/{id}/download`, `GET /v1/crm-documents/{id}/pdf` and `GET /v1/crm-documents/{id}/image` passed that JSON to the client as the document content. **After** A JSON answer without an error is returned as `502 DOWNLOAD_FAILED`. When the PDF or image of the document has not been generated yet, the response is `409 DOCUMENT_NOT_READY`, the same as for an empty representation link. **Impact on integrators** A saved file can no longer turn out to be response text. On `409 DOCUMENT_NOT_READY`, retry the request later. ### NEW-1016-8: Applying application secrets without a deploy When the application owner or a Bitrix24 account administrator saves a secret value on the application card, and after [DELETE /v1/applications/:id/secrets/:name](/docs/applications/app-secrets), the platform restarts the running application in the background with the new set of secrets. No deploy is needed. On a standalone server the application's service restarts, and in Galaxy the container is recreated from the current image. The application does not respond while it restarts. Creating a name without a value restarts nothing. A sleeping machine is not woken by the change: the current set is applied after it wakes up. The `state` field in the [GET /v1/applications/:id/secrets](/docs/applications/app-secrets) response shows how applying is going. The `status` field is `PENDING` while the set waits to be applied, including while the machine sleeps, `APPLYING` during an attempt, `APPLIED` once applying is confirmed, and `FAILED` when applying did not succeed. The failure reason arrives in `failureCode`, and `appliedRevision` becomes equal to `desiredRevision` once the set is applied. The platform retries a failed attempt on its own, at most once a minute, while the machine is running, and the application card can start a retry right away. The `failureCode` values and what to do about each are in the [application secrets guide](/docs/applications/app-secrets). ### FIX-1016-9: bot re-subscription no longer returns 500 after a Bitrix24 timeout **Before** If one call to [POST /v1/bots/{botId}/resubscribe](/docs/bots/management/resubscribe) timed out waiting for Bitrix24, every later re-subscription call for that bot returned `500 INTERNAL_ERROR`, and retrying did not help. **After** A timeout on one call no longer blocks the next ones: a repeated re-subscription goes through as usual. When the bot cannot be changed right now, the method returns `409`, and the error code tells whether retrying helps: - `BOT_EFFECT_IN_PROGRESS` — another change to the bot is in progress, retry after the time given in the `Retry-After` header; - `BOT_RECOVERY_IN_PROGRESS` — automatic bot recovery is running, retry after the time given in `Retry-After`; - `BOT_UNAVAILABLE` — the bot's state needs attention, there is no `Retry-After` header, retrying will not help, contact support. **Impact on integrators** No action required. A client that handles `409` retries only when `Retry-After` is present. ### FIX-1016-10: Deployments to a new server wait for initial setup **Before** [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) with a `runtime` could fail on a package lock on a new standalone server; retrying a few minutes later could fail again. **After** Before installing the runtime, deployment waits up to 15 minutes for initial setup to finish. Progress is reported through `runtime:running` and `elapsedSeconds`, without interrupting system package installation. If setup does not finish or its state cannot be checked, deployment returns an explicit error before stopping the application. JSON and SSE retain their existing response formats. ### FIX-1016-11: a missing to-do activity answers 404 instead of 422 **Before** [PATCH /v1/activity-todos/{id}](/docs/entities/activities/todos/update) for an identifier the Bitrix24 account does not have, [POST /v1/activity-todos](/docs/entities/activities/todos/create) with a missing `parentActivityId`, and the same check before [POST /v1/activities/{id}/complete](/docs/entities/activities/complete), [POST /v1/activities/{id}/postpone](/docs/entities/activities/postpone) and [POST /v1/activities/{id}/deadline](/docs/entities/activities/deadline) answered `422` with code `BITRIX_ERROR` and the text `Bitrix24 API error: 400`. Nothing was written. The create and update reference described that answer as `422`. **After** The same missing identifier answers `404` with code `ENTITY_NOT_FOUND`: the message is `Activity does not exist` for the activity itself and `Parent activity does not exist` for the parent. A refusal that carries a Bitrix24 error code (access denial, request limit, validation error) stays as it was. The successful create response remains HTTP 201, and the successful update or action response remains HTTP 200. ### NEW-1016-12: agent model bitrix/bitrixgpt-6.0-agent [GET /v1/models](/docs/ai/models/list) now lists a new agent model, `bitrix/bitrixgpt-6.0-agent` (BitrixGPT 6.0 Agent 1M), with a 1,048,576-token context. Pass it in the `model` field of a [POST /v1/chat/completions](/docs/ai/chat/completions) request: the model supports streaming, tool calls (`tools`) and reasoning control, with the available steps listed in the `reasoning` field of its entry in the listing. The model is added to the catalog and replaces nothing: existing calls keep working unchanged. ### NEW-1016-13: Manually stopped Black Hole apps For ordinary machine requests to the app at [ANY https://app-./**](/docs/infra/app-runtime) that reach the availability check, when the app was stopped manually, has no connection, and waking is not blocked, the gateway returns `409 BH_APP_STOPPED` without the `Retry-After` header or the `retryAfter` field. The request is not forwarded to the app. There is no automatic wake or retry of this refusal. A wake ban takes priority: `PUBLIC` keeps the neutral `409 BH_APP_UNAVAILABLE`, an identified private-app user receives `402 BH_WAKE_BLOCKED` with recovery instructions, and an unidentified visitor receives the usual authentication response without disclosure of the ban reason. With an active connection, normal access checks and request forwarding remain in effect. Separate gateway responses retain their own rules: service routes `/_gw/*`, `/tunnel`, `/tunnel/session-v1`, `/robots.txt`, link-preview cards on any path, an access-denied login callback, and redirects that remove `__gw_token` or an invalid, expired or replayed `__init` from the URL. A successful `__init` exchange goes through the app availability check. Idle sleep still allows automatic waking.