# API changes: July 1, 2026

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

### FIX-0701-1: Disk file upload accepts files larger than 1 MB

**Before**

[POST /v1/files/upload](/docs/entities/files/upload) rejected a request body larger than ~1 MB with `FST_ERR_CTP_BODY_TOO_LARGE`. The file is sent as base64 in the JSON body, and base64 inflates the size by roughly a third — so even a 1.1 MB file did not pass. There was no way to upload a larger file.

**After**

This route's body limit was raised to 70 MB — enough for a file of about 50 MB once base64 and the JSON envelope are accounted for (call recordings, typical attachments). Bitrix24 still enforces its own Disk file-size cap: exceeding it returns an error in the standard envelope. Files in the hundreds of MB need a separate upload path (multipart / presigned), which is not implemented yet.

### NEW-0701-2: server app icon: SVG upload, anonymous serve, favicon

You can now set an app icon for a server. `POST /v1/infra/servers/:id/icon` (multipart/form-data, field `file`, SVG only up to 256 KB, no scripts, event handlers or external references) uploads the icon; it is served anonymously at the stable `GET /api/server-icons/:id` and shown in the Bitrix24 app catalog. To make it the browser-tab favicon, add `<link rel="icon" type="image/svg+xml" href="<base-URL>/api/server-icons/:id">` to your app HTML at build time — after that, re-uploading the icon refreshes both the catalog and the favicon automatically. Format, requirements and procedure: [App icon](/docs/infra/app-icon).

### NEW-0701-3: The current-user profile reports administrator rights

[GET /v1/users/me](/docs/entities/users) now returns a working `isAdmin` field: `true` — the user is a Bitrix24 account administrator, `false` — not, `null` — could not be determined (a transient failure; the profile is still returned). Use it for server-side permission checks in your backend. `GET /v1/users/:id` and the user list still do not expose it — the verdict is available only for the current session user.

### NEW-0701-4: Extended static field contract in /v1/guide and a schema-discovery pointer in /v1/me

Each entity in the [GET /v1/guide](/docs/keys-auth) response gains a `data.entities[].fieldsDetailed` field — an extended static field contract: `type`, `readonly`, `required`, `createOnly`, and `enum` decoding (for example, the `status` and `priority` values on tasks). It is available with the `X-Api-Key` header alone, without a session, for mappings and code generation before a user session exists. The compact `fields` field is unchanged.

The `GET /v1/me` response for an authorization key without a user session (no `Authorization: Bearer` header) now carries a `schemaDiscovery` block — a pointer to where the static schema lives without a session (`/v1/guide`) and how to get live and custom fields (a Bearer session or a personal key). The `GET /v1/<entity>/fields` and `GET /v1/userfields/*` endpoints are unchanged.

### BC-0701-5: categoryId in the posts response is now an array of numbers

> Old format supported until: 01.01.2027

**Before**

[GET /v1/posts](/docs/feed/posts/list) returned `categoryId` with a type that depended on the number of a post's categories: `null` for none, a number (`11`) for one, a comma-separated string of IDs (`"5,7,9"`) for several. A typed client with a `categoryId: number | null` field worked on single-category posts but broke on posts with two or more.

**After**

`categoryId` is always an array of numbers `number[]`: `[]` for none, `[11]` for one, `[5, 7, 9]` for several. The type is uniform regardless of how many categories a post has.

**What integrators should do**

Read `categoryId` as an array: `post.categoryId.length` instead of a `null` check, `post.categoryId[0]` for the first category. The old "number or string" branch can be removed.

### FIX-0701-6: unified token and scope error codes across the Disk section

**Before**

Custom Disk operations — [POST /v1/files/:id/moveto](/docs/entities/files/moveto), `copyto`, [POST /v1/files/upload](/docs/entities/files/upload), [GET /v1/files/:id/download](/docs/entities/files/download) and the folder counterparts — returned `401 NO_TOKENS` when Bitrix24 tokens were missing and `403 SCOPE_MISSING` when the `disk` scope was absent. The generated CRUD operations of the same section (list/get/create/update/delete) already returned `401 TOKEN_MISSING` and `403 SCOPE_DENIED` for the same conditions — so within one section a client saw two different codes for the same error.

**After**

All Disk operations return unified codes — `401 TOKEN_MISSING` and `403 SCOPE_DENIED`, matching the rest of the V1 API. The HTTP statuses (401 and 403) are unchanged.

**Impact on integrators**

If your code branched on the `NO_TOKENS` or `SCOPE_MISSING` strings on the moveto/copyto/upload/download operations, switch to `TOKEN_MISSING` / `SCOPE_DENIED` (or check the HTTP status). No change is needed otherwise.

### FIX-0701-7: CALL_CARD placement removed from the allowed list

**Before**

The `CALL_CARD` placement code was treated as valid: `POST /v1/placements/bind` passed it through validation and forwarded it to Bitrix24, and `GET /v1/placements/available` listed it. But no Bitrix24 module registers this placement, so `placement.bind` failed with an internal error that the platform surfaced as `INTERNAL_SERVER_ERROR`.

**After**

`CALL_CARD` is removed from the allowed list: it no longer appears in `GET /v1/placements/available`, and `POST /v1/placements/bind` with it is rejected up-front with a clear `VALIDATION_ERROR`, without calling Bitrix24.

**Impact on integrators**

Binding `CALL_CARD` never worked (it returned an opaque 500 error), so no working integration breaks. For the call-card apps panel, use the current placements from `GET /v1/placements/available`.

### FIX-0701-8: workday open/close/pause: the userId field is now applied

**Before**

The documented body field `userId` in [POST /v1/workday/open](/docs/workday/open), [POST /v1/workday/close](/docs/workday/close) and [POST /v1/workday/pause](/docs/workday/pause) was silently ignored: the operation always ran against the key's token owner, even when another employee was passed. The response was `success`, but the action affected the wrong user.

**After**

`userId` is translated to the Bitrix24 `USER_ID` parameter, so the operation runs against the specified employee (given admin or manager rights). A non-existent `userId` now returns a Bitrix24 error instead of a false success. An invalid `userId` (not a positive integer) is rejected as `400 INVALID_PARAMS`. This matches the already-working [GET /v1/workday/status](/docs/workday/status).

**Impact on integrators**

Callers that did not pass `userId` see no change — the operation still applies to the token owner. Callers that passed `userId` now get the correct action against the specified employee.