# API changes: July 24, 2026

[← Changelog](/docs/changelog) · [July 2026](/docs/changelog/2026-07)

### 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](/docs/entities/bizproc-activities) and [POST /v1/bizproc-robots](/docs/entities/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`.