API changes: November 12, 2026

← Changelog · November 2026

NEW-1112-1: cached input price in model pricing

GET /v1/models and GET /v1/models/:modelId return a new cachedPrompt field in the pricing object: the cost of 1M cached input tokens in Vibe credits. The field is always present: null means there is no separate price. The cached part of the input (usage.prompt_tokens_details.cached_tokens) is charged at cachedPrompt when it is set, otherwise at prompt. Writing to the cache is not charged separately.

FIX-1112-2: OpenAPI describes streaming chat responses

Before

For POST /v1/chat/completions and the deprecated POST /v1/ai/chat/completions, the successful response schema listed only application/json, although stream: true enables streaming.

After

The schema declares both formats: application/json for a regular response and text/event-stream for stream: true. The regular response format is preserved. Streaming.

FIX-1112-3: MCP save_sources sends Unicode notes

Before

In @bitrix24/mcp-vibecode-api, save_sources failed locally with NETWORK_ERROR when note contained characters above U+00FF, such as Cyrillic. No snapshot upload request was sent. A note with characters in the U+0080–U+00FF range, such as "é", was stored with garbled characters.

After

Starting with version 3.4.2, every note is sent as UTF-8 bytes in X-Note when calling POST /v1/infra/servers/:serverId/sources or POST /v1/apps/:appId/sources and is stored intact. ASCII notes are sent as before. CR/LF are still rejected.

Impact on integrators

Updating the MCP package is required to receive the fix. API schemas and responses are unchanged.

NEW-1112-4: Withdraw a scheduled Cowork subscription cancellation

POST /v1/cowork/subscription/resume with the vibe:cowork scope withdraws the scheduled cancellation of an active Cowork subscription for the user and account bound to the key. Nothing is charged, and the paid period, next charge date and quotas stay the same. On success, state.subscription.cancelAtPeriodEnd is false. Call this method only after the user confirms the action.

NEW-1112-5: Work report and workday comments

GET /v1/workday/work-reports/:id/comments and GET /v1/workday/records/:recordId/comments read discussions of a report and a working day. Existing report and workday reads keep their behavior.

Rolling out: the target version is timeman 26.600.0. The new reads require separate enablement in Vibecode and an update on the account. Until enabled, or when the method is unavailable, calls return 422 METHOD_NOT_YET_AVAILABLE; the source version alone does not mean that the update is available on the account.

FIX-1112-6: deploy probes reach the app the way a browser does

Before

The healthcheck and app_root steps of POST /v1/infra/servers/:id/deploy and the in-container probe of a galaxy app sent requests without Accept: text/html. An app that serves a browser a page but answers an API request without a session with 503 got DEPLOY_FAILED at the healthcheck step even though the page worked.

After

All three probes send Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 — the way Bitrix24 opens the app. The app is judged by its answer to the browser. An endpoint that serves only JSON is not affected: the header includes */*. The successful HTTP 200 deploy response is unchanged.

NEW-1112-7: appUserSignIn.guidance field in the /v1/me response

The data.capabilities.appUserSignIn group of the GET /v1/me response gains the guidance field, { text } or null. On this platform it is always null. The other response fields do not change.

NEW-1112-10: knowledge base methods report their precise availability release

For 14 later note.* methods, the API reports the precise availability release through error.release if the method is not yet available on the account. Releases: note 26.200.0 for writes, collection retrieval and files, note 26.500.0 for moving collections and documents, note 26.700.0 for GET /v1/note/documents. The successful response remains HTTP 200.

These methods are rolling out. Until the account's module is updated, 422 METHOD_NOT_YET_AVAILABLE means the method has not reached the account yet, rather than an integration error.

FIX-1112-11: checklist actions return 404 for access denials

Before

On newer Bitrix24 versions, task checklist item actions and saving the tree could return HTTP 422 BITRIX_ERROR for a task or item access denial.

After

Checklist item actions return HTTP 404 NOT_FOUND for this denial. Saving the checklist tree through POST /v1/tasks/:taskId/checklist/tree returns HTTP 404 TASK_NOT_FOUND for the same denial, including a denial caused by an invalid item ID or NODE_ID in the request body. The exact denial messages in Russian, English, German and Kazakh are recognized.

BC-1112-12: Bitrix24 refusal when requesting fields of an unsupported CRM entity type

Old format supported until: not provided

Before

After Bitrix24 refused GET /v1/items/{entityTypeId}/fields with ENTITY_TYPE_NOT_SUPPORTED, the request returned HTTP 200 with static fields and a fields_partial warning.

After

This refusal reaches the standard error handler. The standard business refusal returns 422 BITRIX_ERROR, the original Bitrix24 code in error.b24Code and message in error.message. Existing handling priorities for other combinations of Bitrix24 code, message and status are preserved. A successful fields response is no longer returned after this refusal. Other field metadata errors retain the existing partial response.

What integrators should do

Handle HTTP 422 when requesting fields and check error.b24Code. Do not treat static fields as proof that the CRM entity type is available. Batch and import handling is unchanged.