# API changes: October 28, 2026 [← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10) ### FIX-1028-1: Neutral diagnostics for server provisioning failures **Before** [`GET /v1/infra/servers`](/docs/infra/servers/list) and [`GET /v1/infra/servers/:id`](/docs/infra/servers/get) 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](/docs/entities/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](/docs/management-keys), [POST /v1/cowork/applications](/docs/cowork/applications-create) and [POST /v1/cowork/applications/:id/key](/docs/cowork/applications-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](/docs/infra/deploy/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](/docs/keys-auth/me) reported `capabilities.apps.create.available: true` even when [POST /v1/apps](/docs/apps/create) 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](/docs/posts/comments/read) 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](/docs/keys-auth/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](/docs/lists/lists/list) and [GET /v1/lists/:iblockId/elements](/docs/lists/elements/list) 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](/docs/entities/automated-solutions/create) and [PATCH /v1/automated-solutions/:id](/docs/entities/automated-solutions/update) 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](/docs/entities/smart-processes/list), 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.