API changes: October 29, 2026

← Changelog · October 2026

NEW-1029-1: Analytics sources and channels

The Vibecode API can read sources and channels, 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 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, 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 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 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, 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, and retrieve source analytics. 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, POST /v1/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.