[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-11-12":3,"docs-tabs-changelog\u002F2026-11-12":6},{"content":4,"lastmod":5},"# API changes: November 12, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [November 2026](\u002Fdocs\u002Fchangelog\u002F2026-11)\n\n### NEW-1112-1: cached input price in model pricing\n\n[GET \u002Fv1\u002Fmodels](\u002Fdocs\u002Fai\u002Fmodels\u002Flist) and [GET \u002Fv1\u002Fmodels\u002F:modelId](\u002Fdocs\u002Fai\u002Fmodels\u002Fget) 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.\n\n### FIX-1112-2: OpenAPI describes streaming chat responses\n\n**Before**\n\nFor `POST \u002Fv1\u002Fchat\u002Fcompletions` and the deprecated `POST \u002Fv1\u002Fai\u002Fchat\u002Fcompletions`, the successful response schema listed only `application\u002Fjson`, although `stream: true` enables streaming.\n\n**After**\n\nThe schema declares both formats: `application\u002Fjson` for a regular response and `text\u002Fevent-stream` for `stream: true`. The regular response format is preserved. [Streaming](\u002Fdocs\u002Fai\u002Fchat\u002Fstreaming).\n\n### FIX-1112-3: MCP save_sources sends Unicode notes\n\n**Before**\n\nIn `@bitrix24\u002Fmcp-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.\n\n**After**\n\nStarting with version 3.4.2, every note is sent as UTF-8 bytes in `X-Note` when calling [`POST \u002Fv1\u002Finfra\u002Fservers\u002F:serverId\u002Fsources`](\u002Fdocs\u002Fsource-storage) or [`POST \u002Fv1\u002Fapps\u002F:appId\u002Fsources`](\u002Fdocs\u002Fsource-storage) and is stored intact. ASCII notes are sent as before. CR\u002FLF are still rejected.\n\n**Impact on integrators**\n\nUpdating the MCP package is required to receive the fix. API schemas and responses are unchanged.\n\n### NEW-1112-4: Withdraw a scheduled Cowork subscription cancellation\n\n`POST \u002Fv1\u002Fcowork\u002Fsubscription\u002Fresume` 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.\n\n### NEW-1112-5: Work report and workday comments\n\n[GET \u002Fv1\u002Fworkday\u002Fwork-reports\u002F:id\u002Fcomments](\u002Fdocs\u002Fworkday\u002Fwork-reports\u002Fcomments) and [GET \u002Fv1\u002Fworkday\u002Frecords\u002F:recordId\u002Fcomments](\u002Fdocs\u002Fworkday\u002Frecords-comments) read discussions of a report and a working day. Existing report and workday reads keep their behavior.\n\nRolling 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.\n\n### FIX-1112-6: deploy probes reach the app the way a browser does\n\n**Before**\n\nThe `healthcheck` and `app_root` steps of `POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdeploy` and the in-container probe of a galaxy app sent requests without `Accept: text\u002Fhtml`. 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.\n\n**After**\n\nAll three probes send `Accept: text\u002Fhtml,application\u002Fxhtml+xml,application\u002Fxml;q=0.9,*\u002F*;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 `*\u002F*`. The successful HTTP 200 deploy response is unchanged.\n\n### NEW-1112-7: appUserSignIn.guidance field in the \u002Fv1\u002Fme response\n\nThe `data.capabilities.appUserSignIn` group of the `GET \u002Fv1\u002Fme` response gains the `guidance` field, `{ text }` or `null`. On this platform it is always `null`. The other response fields do not change.\n\n### NEW-1112-10: knowledge base methods report their precise availability release\n\nFor 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 \u002Fv1\u002Fnote\u002Fdocuments](\u002Fdocs\u002Fnote\u002Fdocuments\u002Flist). The successful response remains HTTP 200.\n\nThese 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.\n\n### FIX-1112-11: checklist actions return 404 for access denials\n\n**Before**\n\nOn newer Bitrix24 versions, task checklist item actions and saving the tree could return HTTP 422 `BITRIX_ERROR` for a task or item access denial.\n\n**After**\n\nChecklist item actions return HTTP 404 `NOT_FOUND` for this denial. [Saving the checklist tree](\u002Fdocs\u002Fentities\u002Ftasks\u002Fchecklist-actions\u002Ftree) through `POST \u002Fv1\u002Ftasks\u002F:taskId\u002Fchecklist\u002Ftree` 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.\n\n### BC-1112-12: Bitrix24 refusal when requesting fields of an unsupported CRM entity type\n\n> Old format supported until: not provided\n\n**Before**\n\nAfter Bitrix24 refused `GET \u002Fv1\u002Fitems\u002F{entityTypeId}\u002Ffields` with `ENTITY_TYPE_NOT_SUPPORTED`, the request returned HTTP 200 with static fields and a `fields_partial` warning.\n\n**After**\n\nThis 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.\n\n**What integrators should do**\n\nHandle 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.\n",null,{},1794739487318]