API changes: October 9, 2026

← Changelog · October 2026

BC-1009-1: Order in document-template and calendar-event batch subcalls

Old format supported until: not provided

Before

In POST /v1/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 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 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.<key>, 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, POST /v1/audio/transcriptions and POST /v1/images/generations 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, 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 and GET /v1/bizproc-robots, any sort or order returns 400 INVALID_SORT_FIELD. In POST /v1/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 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, types, creating, reading, updating and deleting. 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, POST /v1/activities/{activityId}/bindings, DELETE /v1/activities/{activityId}/bindings and POST /v1/activities/{activityId}/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, GET /v1/requisite-presets/{presetId}/fields/schema, GET /v1/requisite-presets/{presetId}/fields/available, POST /v1/requisite-presets/{presetId}/fields, GET /v1/requisite-presets/{presetId}/fields/{id}, PATCH /v1/requisite-presets/{presetId}/fields/{id}, DELETE /v1/requisite-presets/{presetId}/fields/{id}.

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 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 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 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, POST /v1/pages/{id}/unpublish, GET /v1/chats/events, POST /v1/users/invite, POST /v1/workflows/activity-log and GET /v1/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 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 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, embeddings and audio transcription, 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 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.