[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-10-22":3,"docs-tabs-changelog\u002F2026-10-22":6},{"content":4,"lastmod":5},"# API changes: October 22, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [October 2026](\u002Fdocs\u002Fchangelog\u002F2026-10)\n\n### FIX-1022-1: Deployment after server wake waits for readiness\n\n**Before**\n\n[POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdeploy](\u002Fdocs\u002Finfra\u002Fdeploy\u002Fdeploy) could fail with `BOOTSTRAP_PROBE_FAILED` while the server was still preparing or temporarily lost its connection.\n\n**After**\n\nFor a deployment that installs a runtime on a dedicated server, readiness checks retry after temporary unreadiness or connection loss within the existing 15-minute preparation budget. A terminal readiness failure still fails the deployment, and its message includes a diagnostic category for the cause.\n\n**Impact on integrators**\n\nRequests require no changes. JSON and SSE formats and existing error codes are preserved. Retrying readiness checks does not restart runtime installation.\n\n### NEW-1022-2: waking a server during a configuration change answers 409 RESIZE_IN_PROGRESS\n\n[POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fwake](\u002Fdocs\u002Finfra\u002Flifecycle\u002Fwake) answers `409 RESIZE_IN_PROGRESS` while the server's configuration is being changed. Such a server starts on its own once the change finishes, so there is no need to retry the call. Track readiness by polling [GET \u002Fv1\u002Finfra\u002Fservers\u002F:id](\u002Fdocs\u002Finfra\u002Fservers\u002Fget).\n\n### BC-1022-3: Black Hole tells a dropped connection to the app from app startup, new code BH_APP_CONNECTION_LOST\n\n> Old format supported until: not provided\n\n**Before**\n\nWhen the agent connected to the app and the connection dropped before a response, or the response body could not be read in full, the Gateway answered a machine client with `503 BH_APP_STARTING` and `Retry-After: 3`. The response said the app was still starting, although it was running and the request may already have run. The Gateway response carried no request ID, so a support request could not be matched to the platform log.\n\n**After**\n\nAgent version 1.3.41 and later reports the reason for its refusal to the Gateway. A dropped connection to the app or an unread response body now returns `502 BH_APP_CONNECTION_LOST` without `Retry-After`: the app is running and the request may have run, so no automatic retry is offered. A browser still sees the waiting screen. A failed connection to the app's port still returns `503 BH_APP_STARTING`. An agent older than 1.3.41 keeps the previous responses until it is updated. Any response the Gateway substitutes for the app's response now carries an `X-Vibe-Request-Id` header with the same value the app received. The app external API answers the new code the same way as `BH_APP_TIMEOUT` — `503 APP_API_UNAVAILABLE`.\n\n**What integrators should do**\n\nHandle `502 BH_APP_CONNECTION_LOST` like `504 BH_APP_TIMEOUT`: before retrying a write, check the operation's effect by a stable identifier, and expect no `Retry-After`. If your code branched only on `BH_APP_STARTING`, add the new code to your handling. When you contact support, quote the `X-Vibe-Request-Id` value from the response.\n\nMore — [App runtime](\u002Fdocs\u002Finfra\u002Fapp-runtime) and [What is safe to retry](\u002Fdocs\u002Ferrors\u002Fretry-safety).\n\n### BC-1022-4: deleting the final OAuth key deactivates the app\n\n> Old format supported until: not provided\n\n**Before**\n\nAfter [DELETE \u002Fv1\u002Fkeys\u002F:id](\u002Fdocs\u002Fmanagement-keys) for the final OAuth key, the app registration remained active and prevented issuing a new key.\n\n**After**\n\nDeleting the final OAuth key deactivates the app and allows a new key to be issued. The Bitrix24 registration is removed automatically; this may finish later. Deleting one of several keys preserves the remaining keys and the app registration. The successful response remains HTTP 204 with no body.\n\n**What integrators should do**\n\nStarting with this release, DELETE may return HTTP 409 with code `KEY_REVOCATION_RECOVERY_PENDING` or `KEY_OPERATION_IN_PROGRESS` when deletion has not completed. Update the integration to retry DELETE with a bounded delay only after these codes; the old single-request flow is no longer supported.\n\n### NEW-1022-5: Who is connected to a company key\n\nSuccessful COMPANY responses from [POST \u002Fv1\u002Fconnect\u002Ftoken](\u002Fdocs\u002Fpartner-connect)\nand the `data` object from [GET \u002Fv1\u002Fconnect\u002Fcompany\u002Fstatus](\u002Fdocs\u002Fpartner-connect)\nnow include the connected Bitrix24 account domain and name, plus the current\nconsent holder's name and email. When consent or the holder is unavailable, `user`\nis `null`. Rotation by another administrator does not change the holder. Token\nand status responses, including errors, are not cached. Route permissions and\none-time secret delivery are unchanged.\n",null,{},1794739484731]