# API changes: October 9, 2026 [← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10) ### BC-1009-1: Order in document-template and calendar-event batch subcalls > Old format supported until: not provided **Before** In [POST /v1/batch](/docs/batch), `list` and `search` subcalls for `doc-templates` and `calendar-events` could accept `sort` or `order` and return success without preserving the requested order. **After** Such a subcall returns `INVALID_SORT_FIELD` before calling Bitrix24. If every subcall is refused, the response is HTTP 400 `INVALID_REQUEST` with the subcall code in `data.errors`. Successful subcalls still run in a mixed request. **What integrators should do** For `doc-templates`, request the full sorted set through [GET /v1/doc-templates](/docs/entities/doc-templates/list) with `sort`. For `calendar-events`, remove `sort` and `order` from the batch subcall: the list uses a fixed start-time order. ### FIX-1009-2: Deleting an absent product image returns 404 **Before** [DELETE /v1/catalog-products/:productId/images/:imageId](/docs/entities/catalog-products/images-delete) returned `422 BITRIX_ERROR` if the image was already deleted, belonged to another product or did not exist. **After** These cases return `404 ENTITY_NOT_FOUND`, as when reading the image. A successful deletion still returns `200` and `data.deleted: true`. **Impact on integrators** Handle `404 ENTITY_NOT_FOUND` when retrying a deletion after a lost response. You can check for the image's absence in the product image list. ### FIX-1009-3: Manual AI model registration reports invalid field types **Before** `POST /v1/ai/credentials/:id/models` returned `500 internal_error` when `name` was a number, `contextLength` was fractional, or `maxOutputTokens` was a string. **After** Invalid types for these fields, fractional values and integers outside the range from `-2147483648` to `2147483647` for `contextLength` and `maxOutputTokens` return `400 invalid_request`. The message identifies the field to correct. `null` and omitted optional fields keep the existing defaults. ### BC-1009-4: fields in catalog batch requests returns a field map without a wrapper > Old format supported until: not provided **Before** In `POST /v1/catalog-measures/batch`, `POST /v1/catalog-vat-rates/batch`, `POST /v1/catalog-documents/batch`, `POST /v1/catalog-document-elements/batch`, `POST /v1/catalog-skus/batch` and `POST /v1/catalog-offers/batch` with `action: "fields"`, the field map was located at `data[i].data.`, where the respective key was `measure`, `vat`, `document`, `documentElement`, `sku` or `offer`. **After** Each item returns the descriptor map directly at `data[i].data`. For example, a field previously at `data[i].data.sku.id` is now at `data[i].data.id`. **What integrators should do** Remove the intermediate key when processing `action: "fields"` in these six batch methods. Field names and descriptor contents are preserved. ### NEW-1009-5: Cowork/Code quota wall offers a limit reset with a promotion right The `402 cowork_quota_exhausted` refusal of [POST /v1/chat/completions](/docs/ai/chat/completions), [POST /v1/audio/transcriptions](/docs/ai/audio/transcriptions) and [POST /v1/images/generations](/docs/ai/images) carries a `limitReset` block when the user holds a limit reset right that can be spent right now (`seatAlreadyReset: false`). The block is the same as in [GET /v1/cowork/me](/docs/cowork/me), and the right is spent with `POST /v1/cowork/limits/reset`. The same block arrives in the `COWORK_QUOTA_FALLBACK` warning of a synchronous fallback-model response. Without such a right the key is absent and the response body is unchanged, so check for the key. ### BC-1009-6: Activity and automation rule lists reject sorting > Old format supported until: not provided **Before** `sort` and `order` in activity and automation rule list requests could return a successful response even though the code order did not change. **After** For [GET /v1/bizproc-activities](/docs/entities/bizproc-activities/list) and [GET /v1/bizproc-robots](/docs/entities/bizproc-robots/list), any `sort` or `order` returns `400 INVALID_SORT_FIELD`. In [POST /v1/batch](/docs/batch), `POST /v1/bizproc-activities/batch`, and `POST /v1/bizproc-robots/batch`, the affected sub-call receives `INVALID_SORT_FIELD` in its error field. **What integrators should do** Remove `sort` and `order` from these requests. If you need a specific order, sort the returned codes in your application. ### FIX-1009-7: The SSH password of an open server now works for the user returned by the access method **Before** After a server was switched to `OPEN` mode, [GET /v1/infra/servers/{id}/ssh](/docs/infra/access/ssh) returned an `sshUser` and `sshPassword` pair in which the password belonged to a different user. When `sshUser` was `ubuntu`, a password login as `ubuntu` was rejected. Key-based login worked. **After** The password is set for the user returned in `sshUser`, so a password login as that user succeeds. The response format is unchanged. As before, every switch to `OPEN` issues a new password and previous passwords stop working. ### FIX-1009-8: OpenAPI describes smart-invoice user fields **Before** Six working smart-invoice user field methods under `/v1/userfields/invoices` were missing from OpenAPI and the VibeCode API reference: [listing fields](/docs/userfields/smart-processes/list), [types](/docs/userfields/smart-processes/types), [creating](/docs/userfields/smart-processes/create), [reading](/docs/userfields/smart-processes/get), [updating](/docs/userfields/smart-processes/update) and [deleting](/docs/userfields/smart-processes/delete). Agents and client generators reading the specification could not discover these methods. **After** The methods are included in the full specification, the `crm` slice and both reference languages. They use the same user field contract as `/v1/items/{entityTypeId}/userfields`, with the smart-invoice type fixed to `31`. Parameters, requests, responses and refusals are described. The methods behave as before. Regenerate your client from the current specification to expose them. **Integrator impact** No action is required. ### FIX-1009-9: OpenAPI describes CRM activity bindings **Before** Four working activity binding methods were missing from OpenAPI and the VibeCode API reference: [GET /v1/activities/{activityId}/bindings](/docs/entities/activities/bindings/list), [POST /v1/activities/{activityId}/bindings](/docs/entities/activities/bindings/bind), [DELETE /v1/activities/{activityId}/bindings](/docs/entities/activities/bindings/unbind) and [POST /v1/activities/{activityId}/bindings/move](/docs/entities/activities/bindings/move). Agents and client generators could not discover them in the specification. **After** The methods are included in the full specification, the `crm` slice and both reference languages. Parameters, requests, responses and refusals are described, including deletion parameters supplied through the query or JSON body. The methods behave as before. Regenerate your client from the current specification to expose them. **Integrator impact** No action is required. ### FIX-1009-10: Strict validation of requisite preset field ids **Before** In requisite preset field routes, a nonnumeric id suffix was silently discarded: for example, `12abc` became `12`, so an update or deletion could affect a different field. **Affected endpoints:** [GET /v1/requisite-presets/{presetId}/fields](/docs/entities/requisite-presets/preset-fields/list), [GET /v1/requisite-presets/{presetId}/fields/schema](/docs/entities/requisite-presets/preset-fields/schema), [GET /v1/requisite-presets/{presetId}/fields/available](/docs/entities/requisite-presets/preset-fields/available), [POST /v1/requisite-presets/{presetId}/fields](/docs/entities/requisite-presets/preset-fields/create), [GET /v1/requisite-presets/{presetId}/fields/{id}](/docs/entities/requisite-presets/preset-fields/get), [PATCH /v1/requisite-presets/{presetId}/fields/{id}](/docs/entities/requisite-presets/preset-fields/update), [DELETE /v1/requisite-presets/{presetId}/fields/{id}](/docs/entities/requisite-presets/preset-fields/delete). **After** An invalid `presetId` or field id is rejected before calling Bitrix24: HTTP 400 with `INVALID_PRESET_ID` or `INVALID_FIELD_ID`. Only decimal integers from `1` to `9007199254740991` are accepted, without signs, leading zeros, whitespace, fractions, exponents or nonnumeric suffixes. **For integrators** Pass ids as integers within the stated range and format. ### FIX-1009-11: a Vibe+ trial started in Bitrix24 now grants access on .com **Before** If a Vibe+ trial was started on the Bitrix24 side rather than with the button in the Vibecode cabinet, the platform did not know about it. Creating a server, an agent or a bot and issuing a key were refused with `402` and the code `INT_VIBE_PLUS_REQUIRED`, even though the trial was active in Bitrix24. [GET /v1/me](/docs/keys-auth/me) with the `refresh=tariff` parameter re-read only the plan, so a trial extended on the Bitrix24 side went unnoticed as well. **After** Before answering `INT_VIBE_PLUS_REQUIRED`, the platform asks Bitrix24 about the Vibe+ trial. If the trial is active, the action runs in trial mode, with the same limits as a trial started from the cabinet. A request with `refresh=tariff` now also re-reads the trial end date. If Bitrix24 does not answer, the refusal stays as before. **Impact on integrators** No changes are needed. An agent that got `INT_VIBE_PLUS_REQUIRED` after the trial was started in Bitrix24 can retry the action. ### FIX-1009-12: wake windows: margin no lower than the platform's, outcomes by the moment the server came up **Before** A `lead` value in a window from [POST /v1/infra/servers/:id/wake-schedules](/docs/infra/wake-schedules/create) below the platform margin shortened the time allowed for the server to come up, and with such a margin the server did not make it by the `cronExpr` moment. The `WOKEN` or `LATE` outcome in the [GET /v1/infra/servers/:id/wake-schedules](/docs/infra/wake-schedules/list) response did not match the moment the server came up: a server that came up seconds before the deadline got `LATE`. If the server was already running at the window moment and went to sleep shortly afterwards, the platform woke it again for the past deadline and recorded `LATE`. **After** The platform margin is now a floor: a smaller `lead` is stored on the window as sent, but the wake starts no later than the platform margin before the `cronExpr` moment. The outcome and `firedAt` are decided by the moment the server reached `RUNNING`. A deadline the server was already running for counts as served, with no repeat wake and no entry in the window history. **Integrator impact** No action is required. A server whose `lead` is below the platform margin now comes up earlier and runs that much longer. ### NEW-1009-14: Singleton methods are discoverable in OpenAPI and the API reference `GET /v1/openapi.json` and the API reference now describe six existing methods: [POST /v1/pages/{id}/publication](/docs/entities/pages), [POST /v1/pages/{id}/unpublish](/docs/entities/pages), [GET /v1/chats/events](/docs/chats/events/poll), [POST /v1/users/invite](/docs/entities/users/invite), [POST /v1/workflows/activity-log](/docs/automation/workflows/activity-log) and [GET /v1/warehouses/fields](/docs/entities/warehouses/fields). Agents and client generators can discover these methods and read their parameters, request bodies, responses and refusals. Method behavior is preserved. ### FIX-1009-15: adding a product to a payment returns 404 in German and Kazakh Bitrix24 **Before** [POST /v1/crm-payments/:id/products](/docs/entities/crm-payments/products-add) with a product that this payment cannot pay for returned `404 ENTITY_NOT_FOUND` only when Bitrix24 used English or Russian. In German and Kazakh the same refusal came back as `422 BITRIX_ERROR` with text in the Bitrix24 language. **After** The refusal returns `404 ENTITY_NOT_FOUND` in any of these languages. For German and Kazakh the error text comes in English: `Product was not found.` **Impact on integrators** No action required. A `404 ENTITY_NOT_FOUND` handler now fires the same way in every Bitrix24 language. ### NEW-1009-16: work time settings for a specified employee [GET /v1/workday/settings](/docs/workday/settings) accepts an optional `userId` parameter and returns that employee's work time settings, including the `ufTimeman` flag (whether work time is tracked). Without the parameter the response still belongs to the user who owns the key's tokens. Bitrix24 returns another employee's settings only with the right to manage work time of all employees, otherwise the request is rejected with `422 BITRIX_ERROR`. The `admin` field is not returned in another employee's settings. A `userId` that is not a positive integer is rejected with `400 INVALID_PARAMS`. ### NEW-1009-17: Cowork extensions The API supports a separate Cowork extensions catalog: card creation, version validation and upload, publication and published archive download. Corporate extensions are available to members of their company; vendor extensions are globally available. Publication does not install or enable an extension for a user. The desktop API uses the existing `vibe:cowork` scope; issued key scopes and the applications API remain unchanged. Card mutations are protected by a revision and an idempotency key. POST `/v1/cowork/portal-rest` provides the SDK native gateway, preserving existing method scopes and READONLY policy and returning the original native result without replaying writes after uncertain outcomes. Corporate publication has no moderation workflow; the UI+Node archive is built locally. ### NEW-1009-18: Learn-more link in the AI quota 402 refusal The `402 ai_quota_exhausted` response with `reason: "wallet_off"` on model routes, such as [chat](/docs/ai/chat/completions), [embeddings](/docs/ai/embeddings) and [audio transcription](/docs/ai/audio/transcriptions), carries a `details.learnMoreUrl` field when the Bitrix24 account is confirmed to have no paid AI access, including an exhausted demo quota. It links to a page that describes the paid Bitrix24 plan that includes AI, and the `message` field names that plan in this case. For unconfirmed access status or other refusal reasons the response is unchanged. ### BC-1009-19: Bitrix24 account approval for AI access in Connect applications > Old format supported until: not provided **Before** A partner Connect application could obtain model access under the `vibe:ai` scope with employee consent, without separate approval from a Bitrix24 account administrator. **After** For a partner Connect application, model access under the `vibe:ai` scope requires active approval from a Bitrix24 account administrator. While approval is missing or revoked, model calls such as [POST /v1/chat/completions](/docs/ai/chat/completions) return `403 CONNECT_AI_NOT_PERMITTED`. The key's other scopes remain available. **What integrators should do** When an employee requests administrator approval, the current authorization attempt ends with a denial. The OAuth redirect carries `error=access_denied` and `error_description=admin_approval_requested`; device polling through `POST /v1/connect/token` returns the same values. This ends the attempt and does not instruct the client to keep polling. After an administrator approves access, start a new Connect authorization. If permission was revoked and you receive `CONNECT_AI_NOT_PERMITTED`, ask an administrator to grant permission again.