[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-10-27":3,"docs-tabs-changelog\u002F2026-10-27":6},{"content":4,"lastmod":5},"# API changes: October 27, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [October 2026](\u002Fdocs\u002Fchangelog\u002F2026-10)\n\n### BC-1027-1: List writes reject empty fields and tighten required schema keys\n\n> Old format supported until: not provided\n\n**Before**\n\nThe following operations forwarded `fields: {}` to Bitrix24:\n\n- [POST \u002Fv1\u002Flists](\u002Fdocs\u002Flists\u002Flists\u002Fcreate)\n- [PATCH \u002Fv1\u002Flists\u002F:iblockId](\u002Fdocs\u002Flists\u002Flists\u002Fupdate)\n- [PATCH \u002Fv1\u002Flists\u002F:iblockId\u002Ffields\u002F:fieldId](\u002Fdocs\u002Flists\u002Ffields\u002Fupdate)\n- [POST \u002Fv1\u002Flists\u002F:iblockId\u002Fsections](\u002Fdocs\u002Flists\u002Fsections\u002Fcreate)\n- [PATCH \u002Fv1\u002Flists\u002F:iblockId\u002Fsections\u002F:sectionId](\u002Fdocs\u002Flists\u002Fsections\u002Fupdate)\n- [POST \u002Fv1\u002Flists\u002F:iblockId\u002Felements](\u002Fdocs\u002Flists\u002Felements\u002Fcreate)\n- [PATCH \u002Fv1\u002Flists\u002F:iblockId\u002Felements\u002F:elementId](\u002Fdocs\u002Flists\u002Felements\u002Fupdate)\n\nFor an element update, this request could clear all of its fields. The OpenAPI schemas for list-field operations accepted requests without keys required by Bitrix24.\n\n**After**\n\nThese operations with `fields: {}` return `400 MISSING_REQUIRED_FIELDS` before calling Bitrix24. This also applies when updating a list with `messages` or `rights`. Non-empty objects are forwarded as before, including explicit empty field values.\n\nIn OpenAPI, [creating a list field](\u002Fdocs\u002Flists\u002Ffields\u002Fcreate) now requires non-empty strings `NAME`, `TYPE`, and `CODE` inside `fields`, while [updating a list field](\u002Fdocs\u002Flists\u002Ffields\u002Fupdate) requires a non-empty `TYPE` string. Clients and validators generated from the new schema may reject incomplete non-empty objects before sending a request. Bitrix24 already required these keys.\n\n**What integrators should do**\n\nSend at least one field that you intend to write. If no update is needed, do not send the request. For an element update, send the complete desired field set: it remains a full overwrite, and omitted fields are cleared. Explicit empty values valid for a field keep their prior behavior, for example `{\"NAME\":\"\"}`.\n\nWhen creating a field, send, for example, `{\"fields\":{\"NAME\":\"Priority\",\"TYPE\":\"S\",\"CODE\":\"PRIORITY\"}}`. When updating a field, always send its current `TYPE`, for example, `{\"fields\":{\"TYPE\":\"S\"}}`: an existing field's type cannot be changed. Check these keys and their non-empty values when regenerating OpenAPI clients.\n\n### NEW-1027-2: Retry a server replacement without a second purchase\n\n[POST \u002Fv1\u002Fapplications\u002F:id\u002Freplace-server](\u002Fdocs\u002Fapplications\u002Freplace-server) accepts an optional `Idempotency-Key` header when creating a new server. A retry with the same API key, header value and request body within 24 hours of the first call does not create a second paid server. If the replacement completed and the application still points to that server, the response carries the original result, `Idempotent-Replayed: true` and an empty `warnings` array.\n\nIf the previous outcome is unknown, the retry returns `409 IDEMPOTENCY_KEY_ALREADY_USED`. Check the application card and the servers in the cabinet before another purchase. Duplicate protection may expire after 24 hours. The `{ serverId }` form ignores the header. Calls without the header keep their existing behaviour.\n\n### FIX-1027-3: Cowork tier recommendations account for seat windows\n\n**Before**\n`GET \u002Fv1\u002Fcowork\u002Fstate` recommended the next tier even when it did not increase the seat's available windows.\n\n**After**\n`recommendation.upgrade.nextTier` and `tiers[].isNext` identify the first higher tier that increases at least one window without reducing the others. Partner windows and live demos are included; temporary boosts do not affect selection. No upgrade is recommended when no tier qualifies.\n\n### BC-1027-4: HEAD no longer runs the GET operation on three routes\n\n> Old format supported until: not provided\n\n**Before**\n\nAutomatic `HEAD` could run the `GET` handler at the task comment attachment download, server SSH credentials, and app blueprint spec addresses. It had a separate request limit and could succeed after the `GET` limit was exhausted.\n\n**After**\n\n`HEAD` at these addresses returns HTTP `404` without running the handler. `GET` behavior is unchanged.\n\n**What integrators should do**\n\nDo not use `HEAD` to check these addresses. Call `GET` only when you need the content: it returns file bytes for an attachment and secret connection data for the SSH route. Do not store the SSH response in ordinary check logs.\n\n**Affected endpoints:** [GET \u002Fv1\u002Ftasks\u002F:taskId\u002Fcomments\u002F:id\u002Ffiles\u002F:fileId\u002Fdownload](\u002Fdocs\u002Fentities\u002Ftask-comments\u002Ffile-download), [GET \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fssh](\u002Fdocs\u002Finfra\u002Faccess\u002Fssh), [GET \u002Fv1\u002Fapp\u002Fblueprints\u002F:slug](\u002Fdocs\u002Fapp-blueprints).\n\n### NEW-1027-5: Exhausted AI quota period in the response\n\nFor companies with daily, weekly and monthly AI limits, the `402 ai_quota_exhausted` response includes `error.window` (`DAY`, `WEEK` or `MONTH`) and the renewal time in `error.resetAt`. The `window_exhausted` reason means requests pause until the window resets; `unknown_reaction` requires contacting an administrator. Configured wallet usage retains the `wallet_empty`, `wallet_off` and `breaker` reasons.\n\nAffected endpoints: `POST \u002Fv1\u002Fchat\u002Fcompletions`, `POST \u002Fv1\u002Fembeddings`, `POST \u002Fv1\u002Fimages\u002Fgenerations` and `POST \u002Fv1\u002Faudio\u002Ftranscriptions`.\n\n`GET \u002Fv1\u002Fai\u002Fquota` also returns `data.scheme` (`NEW` or `LEGACY`). For `NEW`, `data.windows` contains the company’s day, week and month: `kind`, `sizeVibes` (null means unlimited), `usedVibes`, `resetAt` and `reaction`. Existing fields and breakdowns remain available.\n\n### NEW-1027-6: actions on a server being moved to another zone answer 409 SERVER_ZONE_MOVING\n\nThe platform can move a server to another availability zone together with its disk. During the move, usually 10–20 minutes, the server sleeps and is not woken. `POST \u002Fv1\u002Finfra\u002Fservers\u002F{id}\u002Fstart`, `\u002Fstop`, `\u002Fsleep-now`, `\u002Freboot`, `\u002Fwake` and `\u002Frepair` on such a server answer `409 SERVER_ZONE_MOVING` and change nothing: the status, billing and machine stay as they were. `error.userMessage` carries text for a person. Retry the action after the move finishes.\n\n### BC-1027-7: creating a standalone machine responds immediately, without SSH credentials\n\n> Old format supported until: not provided\n\n**Before**\n\n`POST \u002Fv1\u002Finfra\u002Fservers` for a standalone machine waited for a prepared machine when one was available and answered `running` with `ip`, otherwise it answered `provisioning`. Every first response carried the platform's `ssh.privateKey` once (and `ssh.password` when present), and the documentation told you to save it. A cloud refusal answered `502 PROVIDER_ERROR`. Without an `Idempotency-Key` header the server record was removed and the quota was not spent; with one the record stayed with `status: \"error\"`. An account hold set during creation answered `403 SERVER_WAKE_BLOCKED`.\n\n**After**\n\nThe answer always comes right away with `status: \"provisioning\"` and `ip: null`. `ssh.password` and `ssh.privateKey` are always `null`. A cloud refusal arrives later as `status: \"error\"` with the reason in `provisionError`. A hold set before the machine is ordered ends the same way: `status: \"error\"` with the reason in `provisionError`. A hold set after the machine was ordered leaves the server as `status: \"sleeping\"` (machine stopped) with an empty `provisionError`. An `error` record stays and counts toward the per-user server limit until it is deleted.\n\n**What integrators should do**\n\nPoll `GET \u002Fv1\u002Finfra\u002Fservers\u002F:id` until the status is `running`, `error` or `sleeping`. On `error`, read `provisionError`, `DELETE` the record and create the server again. SSH access exists only once the server is in `OPEN` mode, which a person switches on in the cabinet (`PATCH \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fmode` to `OPEN` answers `403 DIRECT_NETWORK_CHANGE_REQUIRES_HUMAN` for any API key). After that `GET \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fssh` returns the credentials. With an API key alone there is no SSH; to work with a Black Hole server use the Deploy API (`exec`, `upload`, `logs`).\n\n### BC-1027-8: Publishing a post requires explicit recipients\n\n> Old format supported until: not provided\n\n**Before**\n\n[POST \u002Fv1\u002Fposts](\u002Fdocs\u002Ffeed\u002Fposts\u002Fcreate) published to all employees when `recipients` was omitted or contained an empty array.\n\n**After**\n\nThe `recipients` field is required. An omitted or empty array returns `400 MISSING_PARAMS`; an invalid type or recipient code returns `400 INVALID_PARAMS`. No post is published until the request is corrected. Accepted codes are `U\u003Cid>`, `SG\u003Cid>`, `D\u003Cid>`, `DR\u003Cid>` with a positive integer ID without leading zeros. `UA` is allowed only without other recipients. At most 100 distinct recipients and 1000 input array entries are accepted.\n\n**What integrators should do**\n\nSend the approved audience in every request. To publish to all employees, explicitly send `recipients: [\"UA\"]`. The response returns the post `id` and the supplied `recipients` array. If the dispatch outcome is unknown, check the Feed before publishing again.\n",null,{},1794739485315]