API changes: July 1, 2026

← Changelog · July 2026

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

Before

POST /v1/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.

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

GET /v1/users/me 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 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 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, copyto, POST /v1/files/upload, GET /v1/files/:id/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, POST /v1/workday/close and POST /v1/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.

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.