API changes: October 28, 2026

← Changelog · October 2026

FIX-1028-1: Neutral diagnostics for server provisioning failures

Before

GET /v1/infra/servers and GET /v1/infra/servers/:id could return undocumented codes and technical provisioning error descriptions.

After

These errors are returned as provisionErrorCode: "GENERIC" with a neutral provisionError in owner and development-team cards. Contact support before creating another server. Public wake failure categories and creation hold reasons are preserved.

FIX-1028-2: deal counts by stage semantics answer without a pipeline number

Before

POST /v1/deals/aggregate with count and groupBy: "stageSemanticId" entered the per-stage count mode only with a scalar categoryId in the filter. Without it, or with a list of pipelines, a request over more than 5,000 deals returned 422 AGGREGATION_LIMIT_EXCEEDED or a truncated response, even on an account where that mode is enabled.

After

On an account with the per-stage count mode enabled, such a request returns exact P / S / F groups with meta.aggregatePath: "fanout" and meta.recordsProcessed: 0, with any categoryId condition or none. Grouping by stageId still needs a scalar categoryId.

Impact on integrators

No action required. An in progress / won / lost summary across all pipelines now takes one request instead of three separate count calls.

FIX-1028-3: a key is issued on a cloud Bitrix24 account connected without Bitrix24 Network

Before

A cloud Bitrix24 account connected to the platform from inside Bitrix24 (from the embedded app or by signing in to the cabinet) is not linked to Bitrix24 Network. On such an account POST /v1/keys, POST /v1/cowork/applications and POST /v1/cowork/applications/:id/key answered 400 PORTAL_NOT_LINKED, even though the Vibecode module on the account could issue the key itself.

After

The Vibecode module on such an account issues the key, and the request succeeds. 400 PORTAL_NOT_LINKED remains only for an account where the module cannot issue the key and there is no link to Bitrix24 Network.

Impact on integrators

No action is required. If you asked the user to sign in through Bitrix24 Network on PORTAL_NOT_LINKED, retry the request: it may now succeed without that step.

FIX-1028-4: deploy continues when the server is ready

Before

POST /v1/infra/servers/:id/deploy could end with BOOTSTRAP_PROBE_FAILED although the server was ready.

After

The deploy now continues in this case. A genuinely invalid readiness response still stops the deploy.

Impact on integrators

The request and response format are unchanged. No action is needed.

FIX-1028-5: apps.create reflects new-key issuance access

Before

GET /v1/me reported capabilities.apps.create.available: true even when POST /v1/apps refused new-key issuance. Application publishing and binding notes claimed creation was available regardless of the Bitrix24 plan.

After

capabilities.apps.create reflects new-key issuance access. A denied slot includes the reason; for a Cowork key it reflects the first POST /v1/apps guard and also mentions any separate restriction from the Bitrix24 plan for .com Bitrix24 accounts. Publishing and binding notes distinguish Bitrix24 requirements from server infrastructure limits.

Impact on integrators

Check capabilities.apps.create before calling POST /v1/apps and handle reason when available is false. After access or the key changes, check again or call POST /v1/apps: the slot uses a cached access snapshot, and the route makes the final decision from current state.

FIX-1028-6: Comment file IDs are returned in attach again

Before

GET /v1/posts/comments returned attach: [] for every comment, even when files were attached to it. The files came in data.files, but the response gave no way to link them to a comment.

After

attach contains the IDs of the attached files as numbers, for example [10893, 10895]. These are the keys of data.files. A comment without files still has an empty attach array.

Impact on integrators

No changes are needed. To find a comment's files, take the data.files entries whose keys are listed in attach.

NEW-1028-7: Key owner ID source

GET /v1/me returns owner.userIdSource: webhook or portal-membership when owner.userId is available. The ID is a string. A Cowork key without a webhook may receive a fixed employee ID from its Bitrix24 account membership. This does not grant data access: with b24Credentials.ready: false, calls return 401 TOKEN_MISSING.

NEW-1028-8: Next-page offset for lists

GET /v1/lists and GET /v1/lists/:iblockId/elements return an optional numeric meta.next field from Bitrix24. Pass it as the next start. The field is absent on the last page. For list elements, the documentation clarifies the 50-record step and rounding the offset down to a multiple of 50. Stop when meta.next is absent or the collected count reaches meta.total, because a request beyond the last element page returns the first page.

BC-1028-9: Workspace typeIds no longer accepts a value with no matching type

Old format supported until: not provided

Before

POST /v1/automated-solutions and PATCH /v1/automated-solutions/:id with typeIds containing a value that matched no smart process type (an entityTypeId instead of the id included) answered 200/201: Bitrix24 silently dropped that value. On PATCH, where the set is replaced in full, this unbound every type the request did not repeat from the workspace.

After

The same request answers 400 UNKNOWN_TYPE_ID before Bitrix24 is called and changes nothing. error.details.unknown lists the unknown values and error.details.knownIds the available type IDs; when an entityTypeId was sent, the error text names the id of the matching type. A value sent as an object instead of an array or a number answers 400 INVALID_PARAMS. An empty array [] still unbinds every type and is not an error. The check relies on the type list Bitrix24 returns: if it is unavailable or incomplete, the write proceeds unchecked — in that case compare typeIds in the response.

What integrators should do

Match typeIds values against the id field of the types from GET /v1/smart-processes, not against entityTypeId. The UNKNOWN_TYPE_ID response carries the available IDs, so the fix needs no separate read.

NEW-1028-10: End-to-end analytics traces through REST v3

Added trace listing and reading, creation with an explicit source, and complete deletion through REST v3. These routes are behind a feature flag and will become available with the Bitrix24 update. Until then, existing creation with trace and deletion continue to work.