API changes: October 16, 2026

← Changelog · October 2026

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 did not mark email as required on create. GET /v1/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 and POST /v1/sites 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, 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 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.

FIX-1016-9: bot re-subscription no longer returns 500 after a Bitrix24 timeout

Before

If one call to POST /v1/bots/{botId}/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 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} for an identifier the Bitrix24 account does not have, POST /v1/activity-todos with a missing parentActivityId, and the same check before POST /v1/activities/{id}/complete, POST /v1/activities/{id}/postpone and POST /v1/activities/{id}/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 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 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-./** 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.