[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-10-29":3,"docs-tabs-changelog\u002F2026-10-29":6},{"content":4,"lastmod":5},"# API changes: October 29, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [October 2026](\u002Fdocs\u002Fchangelog\u002F2026-10)\n\n### NEW-1029-1: Analytics sources and channels\n\nThe Vibecode API can read [sources](\u002Fdocs\u002Fentities\u002Fcrm-tracking\u002Fsources-list) and [channels](\u002Fdocs\u002Fentities\u002Fcrm-tracking\u002Fchannels-list), create and update custom sources, archive and restore them. A built-in source is available by code even before it is configured.\n\nThe methods are rolling out with update `crm 26.2100.0`. The routes use the `crm-tracking-v3` flag and will be enabled together with the Bitrix24 capability. Until a method is available, the response is `422 METHOD_NOT_YET_AVAILABLE`.\n\n### FIX-1029-2: workgroup list remains available without a group image\n\n**Before**\n\n[GET \u002Fv1\u002Fme\u002Fworkgroups](\u002Fdocs\u002Fme\u002Fworkgroups) failed with HTTP 502 `BITRIX_UNAVAILABLE` if Bitrix24 returned `null` instead of an image URL for at least one group.\n\n**After**\n\nA group without an image stays in the complete list. A missing or empty URL, including `null`, is returned as `groupImage: \"\"`; an empty image ID becomes `groupImageId: 0`, and an empty extranet indicator becomes `isExtranet: false`. A nonempty image ID is preserved even without a URL.\n\n**Integrator impact**\n\nNo response-handling changes are needed: field types are preserved. An empty image no longer prevents you from retrieving the other groups.\n\n### FIX-1029-3: The pipeline schema describes isSystem and the missing createdDate\n\n**Before**\n\nThe `isSystem` field of contact and company pipelines came back in responses but was not described in the [pipeline schema](\u002Fdocs\u002Fentities\u002Fcategories\u002Ffields), and `select=isSystem` produced an `UNKNOWN_SELECT_FIELD` warning. The `createdDate` field was described in the schema as a regular field, although Bitrix24 does not return it.\n\n**After**\n\n`isSystem` is described in the schema and in OpenAPI as the string `Y` or `N`, as Bitrix24 returns it, and can be selected in `select` without a warning. The value in the response has not changed. A write of `isSystem` still goes to Bitrix24 unchanged: Bitrix24 does not allow creating a pipeline with `isSystem: \"Y\"` and does not apply the field on update. The schema and the documentation now say so explicitly. `createdDate` is marked `notReturned: true`, and `x-notReturned: true` in OpenAPI. A request with `select=createdDate` still answers HTTP 200, and `meta.warnings` carries `UNKNOWN_SELECT_FIELD`.\n\n**Impact on integrators**\n\nNo changes are needed. Do not build sorting or display on `createdDate`: the field has no value.\n\n### FIX-1029-4: bot registration no longer promises a retry that changes nothing\n\n**Before**\n\nWhen a bot registration stopped on a state that cannot fix itself, `POST \u002Fv1\u002Fbots` answered `409 BOT_EFFECT_IN_PROGRESS` with a `Retry-After` header. A repeat after that delay received the same answer again, with no limit. Such states include a `code` already taken by a bot with another id, and a key whose write access was revoked.\n\n**After**\n\nThat refusal now comes as `409 BOT_UNAVAILABLE` without the `Retry-After` header. Refusals that the platform resolves on its own still come as `409 BOT_EFFECT_IN_PROGRESS` with `Retry-After`: that branch is unchanged.\n\n**Impact on integrators**\n\nTreat `BOT_UNAVAILABLE` as requiring an action: do not repeat the request on a timer, check whether the `code` is taken by another bot and whether the key still has write access. A `BOT_EFFECT_IN_PROGRESS` answer with a `Retry-After` header is handled as before.\n\n### NEW-1029-5: Custom domain of a server through the API\n\nA custom domain of an application can now be connected with an API key, without the cabinet. `POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdomain` attaches a domain and returns the DNS records to create at the DNS provider: type, name relative to the zone and value. `GET \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdomain` returns the state of the domain and the same records. `POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdomain\u002Fverify` checks the records and activates the domain, with a status for each record in the response. `DELETE \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdomain` detaches the domain.\n\nOnly the key that manages the server may call these operations, any other key gets `404 SERVER_NOT_FOUND`. Attaching, checking and detaching require the `vibe:infra` scope. Until the feature is enabled for the server owner, attaching and checking answer `403 CUSTOM_DOMAINS_DISABLED`, for a Bitrix24 account region where custom domains are not supported — `403 CUSTOM_DOMAINS_ZONE_UNSUPPORTED`, without a commercial plan — `403 CUSTOM_DOMAINS_REQUIRE_COMMERCIAL`.\n\nThe check is limited to five calls per minute. When the records do not match it answers `422 DOMAIN_VERIFICATION_FAILED`, and the `error.details.hint` field explains when to repeat it: a DNS change is not published at once, and a repeat without a pause returns the same result.\n\n### BC-1029-6: Signed resource URLs and blocked token refresh\n\n> Old format supported until: not provided\n\n**Before**\n\n[POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Faccess-tokens\u002F:tokenId\u002Frefresh](\u002Fdocs\u002Finfra\u002Faccess-tokens\u002Frefresh) could return `200` when the current or a recorded previous issuer of an `api-bearer` token was blocked but the token itself had not yet been revoked.\n\n**After**\n\nRefreshing the token in this case returns `403 KEY_BLOCKED`. The previous successful response is no longer supported. Normal key rotation without a blocked issuer still allows an active token to be refreshed.\n\n**Added**\n\n[POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Faccess-tokens\u002F:tokenId\u002Fresource-url](\u002Fdocs\u002Finfra\u002Faccess-tokens\u002Fresource-url) issues a GET\u002FHEAD URL for one CSS file, image or font from an existing `api-bearer` token. The URL is bound to its path and application, lasts up to 30 days without outliving its parent, and stops working when the parent is revoked. For a main-page widget with PORTAL access, use a signed stylesheet URL and separately signed image URLs; renew the registration before expiry. These resources load without a user session.\n\nIf the current or a recorded previous issuer is blocked, signing a resource URL returns `403 KEY_BLOCKED`.\n\nA temporarily unavailable resource returns `503 BH_RESOURCE_UNAVAILABLE`. A revoked or invalid URL returns `401 BH_RESOURCE_URL_INVALID` without falling back to a browser session or public access.\n\n**What integrators should do**\n\nIssue a new `api-bearer` token using an unblocked management key and replace the token in your client. Refreshing the previous token again does not resolve `KEY_BLOCKED`.\n\n### NEW-1029-7: Advertising accounts for analytics\n\nThe API can return an authorization link, read and connect advertising accounts of an [analytics source](\u002Fdocs\u002Fentities\u002Fcrm-tracking), disconnect an account, read the advertising tree and build an expense report one step at a time. A cursor carries the next tree page. The `complete` field indicates report completion.\n\nThe methods are rolling out with update `crm 26.2100.0`. The routes behind the `crm-tracking-v3` flag will be enabled together with the Bitrix24 capability. Until enabled, the API returns `422 METHOD_NOT_YET_AVAILABLE`.\n\n### NEW-1029-8: Manual expenses and source analytics\n\nThe Vibecode API can add, read and delete [manual expenses](\u002Fdocs\u002Fentities\u002Fcrm-tracking\u002Fexpenses-list), and retrieve [source analytics](\u002Fdocs\u002Fentities\u002Fcrm-tracking\u002Fanalytics-sources-list). Expense amounts use units of the selected currency. This deletion does not affect advertising integration expenses.\n\nThe methods are rolling out with update `crm 26.2100.0`. The routes use the `crm-tracking-v3` flag and will be enabled together with the Bitrix24 capability. Until a method is available, the response is `422 METHOD_NOT_YET_AVAILABLE`.\n\n### FIX-1029-9: signing in to Cowork again keeps the previous key until the new key is confirmed\n\n**Before**\n\nSigning in again with a device code revoked the installation's previous key as soon as Connect approved the request. The desktop could lose its session before saving the new key.\n\n**After**\n\nFor desktop versions 14.0.94 and later that provide their version and installation ID when starting sign-in, the previous key remains valid until the first successful `GET \u002Fv1\u002Fcowork\u002Fme` with the new key. Preliminary profile requests do not confirm replacement. An unconfirmed key remains usable without a separate expiration deadline. If confirmation fails, the subscription response remains successful and the next request retries confirmation.\n\n### FIX-1029-10: Temporary pause after repeated Bitrix24 access denials\n\n**Before**\n\nAfter repeated `401 ACCESS_DENIED` responses from Bitrix24, requests using the same key continued to receive access denials without a temporary pause.\n\n**After**\n\nAfter repeated access denials across different REST methods, requests to Bitrix24 using that key are temporarily paused. A single operation and a global `POST \u002Fv1\u002Fbatch` whose refusal aborts the envelope return `429 ERROR_LOOP_DETECTED` with `reason: TEMPORARY_REST_ACCESS_DENIED`; the `Retry-After` header and `retryAfter` field contain the same number of seconds until the next check. A refused auto-paginated global-batch sub-call and a refused read action in `POST \u002Fv1\u002F{entity}\u002Fbatch` remain in that call's slot under outer HTTP `200` and carry `retryAfter`; these responses have no outer `Retry-After` header. A refused write action in an entity batch aborts the request and returns outer HTTP `429` with `Retry-After` and `retryAfter`. After the pause, the API automatically checks access on the next request. Requests resume when access is restored.\n\n**Affected endpoints:** public operations that make a Bitrix24 REST call with this ordinary API key, including [GET \u002Fv1\u002Fusers](\u002Fdocs\u002Fentities\u002Fusers\u002Flist), [POST \u002Fv1\u002Fbatch](\u002Fdocs\u002Fbatch), and entity batch operations. A single call and a global-batch refusal at the envelope level receive HTTP 429; a refused auto-paginated global-batch sub-call and a refused read action in an entity batch keep HTTP 200 and return the refusal with `retryAfter` in the operation slot, without an outer `Retry-After` header. A refused write action in an entity batch receives outer HTTP 429 with `Retry-After` and `retryAfter`. Operations that do not make a REST call with this key are unaffected.\n\n**Impact on integrators**\n\nNo integration changes or manual key reactivation are required.\n",null,{},1794739485646]