API changes: July 24, 2026

← Changelog · July 2026

FIX-0724-1: activities: an unrecognized filter field name is now rejected with 400 UNKNOWN_FILTER_FIELD

Before

GET /v1/activities and POST /v1/activities/search silently dropped an unknown filter key: the request returned 200 success with the filter trimmed to empty — that is, it returned the whole (owner-scoped or entire) activity set. For example {"filter":{"ownerTypeId":2,"ownerId":3,"bogusField":123}} ignored bogusField and returned every activity of the parent deal. This diverged from the documentation and from other CRM entities (companies, invoices), where such a filter was already rejected.

After

A filter field name that is not in the activity schema — and is not a UF_* custom field, the id key, or a special token — is now rejected before the Bitrix24 call with 400 UNKNOWN_FILTER_FIELD and a list of available fields, the same as companies/quotes/contacts already do. The full list of filterable fields is returned by GET /v1/activities/fields.

Impact on integrators

Filtering by real activity fields (in camelCase or the native Bitrix24 UPPER case), by UF_* fields, operators (>=, <, !, etc.), ranges, and AND/NOT all work as before. If you relied on the silent drop of an unrecognized key, remove it from the filter.

NEW-0724-2: bizproc activities and robots /fields now return field labels and descriptions

Before

GET /v1/bizproc-activities/fields and GET /v1/bizproc-robots/fields described each field only by its type and the readonly flag, with no human-readable labels.

After

Each of the 12 fields now carries a label and a description in English, which makes building forms and hints easier. Field types are unchanged.

FIX-0724-3: Downloading your own storage objects no longer returns 403

Before

GET /v1/storage/objects/:key could return 403 for an object the key owner legitimately owns but that physically lives under a different storage "family" prefix (for example, server files visible in a developer's listing). The object appeared in the listing, yet downloading it, minting a presigned URL or issuing a HEAD failed.

After

The scoped credentials account for the object's actual family (the Bitrix24 account stays bound to the caller's context), so download (?download), streaming (?inline) and HEAD work for your own objects regardless of family. Ownership checks are unchanged — someone else's object still returns 404.

FIX-0724-4: GET /v1/workflows honours the limit parameter

Before

GET /v1/workflows accepted limit but silently ignored it — the whole page of running workflows (up to 50) was always returned regardless of the requested size.

After

limit is respected: the response holds at most the requested number of records. Values above 50 are gathered page by page (capped at 500); meta.total still reports the total number of running workflows.

FIX-0724-5: deploy: an app wrapped in a single archive folder no longer fails with ENOENT package.json

Before

Deploying (POST /v1/infra/servers/:id/deploy) to a standalone server an archive that wraps the project in a single top-level folder (e.g. myapp/package.json instead of package.json at the root) failed at the install step:

npm error enoent Could not read package.json ... open '/opt/app/package.json'

The uploaded archive was left beside the extracted content, so the auto-flatten of a single wrapping directory did not fire (the root held two entries — the archive and the folder) and package.json stayed nested.

After

The uploaded archive is removed before the flatten step, so a single wrapping directory collapses, package.json lands at the deploy root, and the install proceeds normally.

Impact

No client action required. Flat archives (files at the archive root) work as before; to be safe you can package flat: tar -czf build.tar.gz -C <project_dir> ..

FIX-0724-6: /v1/users* endpoints no longer return 403 and 500 on keys with user access

Before

On a read-only (READONLY) key with user access, GET /v1/users/me returned 403 WRITE_BLOCKED_READONLY_KEY even though it is a read endpoint. Separately, GET /v1/users, GET /v1/users/:id, POST /v1/users/search and GET /v1/users/fields returned 500 INTERNAL_ERROR on accounts where one of the user fields (UF_*) had an empty definition.

After

GET /v1/users/me works on a read-only key. The other /v1/users* endpoints return data and skip the field with an empty definition instead of failing.

Impact on integrators

No action required — existing calls keep working, and the previously failing scenarios now respond correctly.

NEW-0724-7: bizproc activity and robot callback delivery to a Black Hole app

Registering a bizproc activity or robot whose handler points at your Black Hole deploy server now reliably delivers the execution callback (event token, auth block, code and properties) to the app. Previously that callback could be lost: Bitrix24 online events are not retried, and a sleeping or waking server dropped the call. The platform intercepts the handler at registration, queues the call durably, and retries delivery with a server wake-up and backoff.

Affects POST /v1/bizproc-activities and POST /v1/bizproc-robots (and their update). New error code SERVER_APP_MISMATCH (400): the Black Hole server behind the given handler must belong to the same app that registers the activity. Registering such a handler through /v1/batch is not supported — use a single request (BIZPROC_CALLBACK_BATCH_UNSUPPORTED). Additionally, POST /v1/bizproc-robots now requires code, name and handler upfront — omitting any returns 400 MISSING_REQUIRED_FIELDS instead of a raw Bitrix24 error (as activities already did).

The capability is rolling out gradually and is enabled per account: until it is on for your account, registration behaves as before, without managed delivery. Once it is on, batch registration behaviour changes: an attempt to register a BH handler via /v1/batch starts being rejected (BIZPROC_CALLBACK_BATCH_UNSUPPORTED) — move such registrations to a single POST /v1/bizproc-activities or /v1/bizproc-robots.