[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-07-01":3,"docs-tabs-changelog\u002F2026-07-01":6},{"content":4,"lastmod":5},"# API changes: July 1, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [July 2026](\u002Fdocs\u002Fchangelog\u002F2026-07)\n\n### FIX-0701-1: Disk file upload accepts files larger than 1 MB\n\n**Before**\n\n[POST \u002Fv1\u002Ffiles\u002Fupload](\u002Fdocs\u002Fentities\u002Ffiles\u002Fupload) 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.\n\n**After**\n\nThis 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 \u002F presigned), which is not implemented yet.\n\n### NEW-0701-2: server app icon: SVG upload, anonymous serve, favicon\n\nYou can now set an app icon for a server. `POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Ficon` (multipart\u002Fform-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 \u002Fapi\u002Fserver-icons\u002F:id` and shown in the Bitrix24 app catalog. To make it the browser-tab favicon, add `\u003Clink rel=\"icon\" type=\"image\u002Fsvg+xml\" href=\"\u003Cbase-URL>\u002Fapi\u002Fserver-icons\u002F: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](\u002Fdocs\u002Finfra\u002Fapp-icon).\n\n### NEW-0701-3: The current-user profile reports administrator rights\n\n[GET \u002Fv1\u002Fusers\u002Fme](\u002Fdocs\u002Fentities\u002Fusers) 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 \u002Fv1\u002Fusers\u002F:id` and the user list still do not expose it — the verdict is available only for the current session user.\n\n### NEW-0701-4: Extended static field contract in \u002Fv1\u002Fguide and a schema-discovery pointer in \u002Fv1\u002Fme\n\nEach entity in the [GET \u002Fv1\u002Fguide](\u002Fdocs\u002Fkeys-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.\n\nThe `GET \u002Fv1\u002Fme` 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 (`\u002Fv1\u002Fguide`) and how to get live and custom fields (a Bearer session or a personal key). The `GET \u002Fv1\u002F\u003Centity>\u002Ffields` and `GET \u002Fv1\u002Fuserfields\u002F*` endpoints are unchanged.\n\n### BC-0701-5: categoryId in the posts response is now an array of numbers\n\n> Old format supported until: 01.01.2027\n\n**Before**\n\n[GET \u002Fv1\u002Fposts](\u002Fdocs\u002Ffeed\u002Fposts\u002Flist) 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.\n\n**After**\n\n`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.\n\n**What integrators should do**\n\nRead `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.\n\n### FIX-0701-6: unified token and scope error codes across the Disk section\n\n**Before**\n\nCustom Disk operations — [POST \u002Fv1\u002Ffiles\u002F:id\u002Fmoveto](\u002Fdocs\u002Fentities\u002Ffiles\u002Fmoveto), `copyto`, [POST \u002Fv1\u002Ffiles\u002Fupload](\u002Fdocs\u002Fentities\u002Ffiles\u002Fupload), [GET \u002Fv1\u002Ffiles\u002F:id\u002Fdownload](\u002Fdocs\u002Fentities\u002Ffiles\u002Fdownload) 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\u002Fget\u002Fcreate\u002Fupdate\u002Fdelete) 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.\n\n**After**\n\nAll 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.\n\n**Impact on integrators**\n\nIf your code branched on the `NO_TOKENS` or `SCOPE_MISSING` strings on the moveto\u002Fcopyto\u002Fupload\u002Fdownload operations, switch to `TOKEN_MISSING` \u002F `SCOPE_DENIED` (or check the HTTP status). No change is needed otherwise.\n\n### FIX-0701-7: CALL_CARD placement removed from the allowed list\n\n**Before**\n\nThe `CALL_CARD` placement code was treated as valid: `POST \u002Fv1\u002Fplacements\u002Fbind` passed it through validation and forwarded it to Bitrix24, and `GET \u002Fv1\u002Fplacements\u002Favailable` 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`.\n\n**After**\n\n`CALL_CARD` is removed from the allowed list: it no longer appears in `GET \u002Fv1\u002Fplacements\u002Favailable`, and `POST \u002Fv1\u002Fplacements\u002Fbind` with it is rejected up-front with a clear `VALIDATION_ERROR`, without calling Bitrix24.\n\n**Impact on integrators**\n\nBinding `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 \u002Fv1\u002Fplacements\u002Favailable`.\n\n### FIX-0701-8: workday open\u002Fclose\u002Fpause: the userId field is now applied\n\n**Before**\n\nThe documented body field `userId` in [POST \u002Fv1\u002Fworkday\u002Fopen](\u002Fdocs\u002Fworkday\u002Fopen), [POST \u002Fv1\u002Fworkday\u002Fclose](\u002Fdocs\u002Fworkday\u002Fclose) and [POST \u002Fv1\u002Fworkday\u002Fpause](\u002Fdocs\u002Fworkday\u002Fpause) 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.\n\n**After**\n\n`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 \u002Fv1\u002Fworkday\u002Fstatus](\u002Fdocs\u002Fworkday\u002Fstatus).\n\n**Impact on integrators**\n\nCallers 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.\n",null,{},1794739469050]