# API changes: October 29, 2026

[← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10)

### NEW-1029-1: Analytics sources and channels

The Vibecode API can read [sources](/docs/entities/crm-tracking/sources-list) and [channels](/docs/entities/crm-tracking/channels-list), create and update custom sources, archive and restore them. A built-in source is available by code even before it is configured.

The 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`.

### FIX-1029-2: workgroup list remains available without a group image

**Before**

[GET /v1/me/workgroups](/docs/me/workgroups) failed with HTTP 502 `BITRIX_UNAVAILABLE` if Bitrix24 returned `null` instead of an image URL for at least one group.

**After**

A 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.

**Integrator impact**

No response-handling changes are needed: field types are preserved. An empty image no longer prevents you from retrieving the other groups.

### FIX-1029-3: The pipeline schema describes isSystem and the missing createdDate

**Before**

The `isSystem` field of contact and company pipelines came back in responses but was not described in the [pipeline schema](/docs/entities/categories/fields), 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.

**After**

`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`.

**Impact on integrators**

No changes are needed. Do not build sorting or display on `createdDate`: the field has no value.

### FIX-1029-4: bot registration no longer promises a retry that changes nothing

**Before**

When a bot registration stopped on a state that cannot fix itself, `POST /v1/bots` 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.

**After**

That 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.

**Impact on integrators**

Treat `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.

### NEW-1029-5: Custom domain of a server through the API

A custom domain of an application can now be connected with an API key, without the cabinet. `POST /v1/infra/servers/:id/domain` attaches a domain and returns the DNS records to create at the DNS provider: type, name relative to the zone and value. `GET /v1/infra/servers/:id/domain` returns the state of the domain and the same records. `POST /v1/infra/servers/:id/domain/verify` checks the records and activates the domain, with a status for each record in the response. `DELETE /v1/infra/servers/:id/domain` detaches the domain.

Only 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`.

The 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.

### BC-1029-6: Signed resource URLs and blocked token refresh

> Old format supported until: not provided

**Before**

[POST /v1/infra/servers/:id/access-tokens/:tokenId/refresh](/docs/infra/access-tokens/refresh) 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.

**After**

Refreshing 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.

**Added**

[POST /v1/infra/servers/:id/access-tokens/:tokenId/resource-url](/docs/infra/access-tokens/resource-url) issues a GET/HEAD 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.

If the current or a recorded previous issuer is blocked, signing a resource URL returns `403 KEY_BLOCKED`.

A 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.

**What integrators should do**

Issue 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`.

### NEW-1029-7: Advertising accounts for analytics

The API can return an authorization link, read and connect advertising accounts of an [analytics source](/docs/entities/crm-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.

The 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`.

### NEW-1029-8: Manual expenses and source analytics

The Vibecode API can add, read and delete [manual expenses](/docs/entities/crm-tracking/expenses-list), and retrieve [source analytics](/docs/entities/crm-tracking/analytics-sources-list). Expense amounts use units of the selected currency. This deletion does not affect advertising integration expenses.

The 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`.

### FIX-1029-9: signing in to Cowork again keeps the previous key until the new key is confirmed

**Before**

Signing 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.

**After**

For 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 /v1/cowork/me` 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.

### FIX-1029-10: Temporary pause after repeated Bitrix24 access denials

**Before**

After repeated `401 ACCESS_DENIED` responses from Bitrix24, requests using the same key continued to receive access denials without a temporary pause.

**After**

After repeated access denials across different REST methods, requests to Bitrix24 using that key are temporarily paused. A single operation and a global `POST /v1/batch` 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 /v1/{entity}/batch` 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.

**Affected endpoints:** public operations that make a Bitrix24 REST call with this ordinary API key, including [GET /v1/users](/docs/entities/users/list), [POST /v1/batch](/docs/batch), 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.

**Impact on integrators**

No integration changes or manual key reactivation are required.