# API changes: July 16, 2026

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

### BC-0716-1: json_object on a reasoning model recovers JSON; the 422 body is refined

> Old format supported until: 15.01.2027

**Before**

A [POST /v1/chat/completions](/docs/ai/chat/completions) request with a `json_object` `response_format` on a reasoning model (e.g. `bitrix/bitrixgpt-5.5-agent`) consistently returned `422 structured_output_truncated`, even when the model finished on its own (`finish_reason: "stop"`) and placed a complete valid JSON into the service `reasoning_content` channel — the answer was lost. Every such error body carried `error.suggestedMaxTokens` and `error.param`, and the text claimed "finish_reason=length" regardless of the real stop reason.

**After**

If a model on `json_object` finished on its own and valid JSON sits in `reasoning_content`, the platform recovers it and returns `200` with that JSON in `content` (in streaming mode — as a `content` chunk before the terminal `finish_reason` chunk). The `422` body is now truthful: `error.suggestedMaxTokens` and `error.param` are present **only** on a genuine truncation (`finish_reason: "length"`); on any other stop reason (`stop`, etc.) those fields are **omitted** and the text names the actual `finish_reason`. `json_schema` behaviour is unchanged — there the strict schema is enforced model-side.

**What to do**

Nothing, if you handle `422` by `error.code`. If your code **unconditionally** reads `error.suggestedMaxTokens` or `error.param` on a `structured_output_truncated` error, make the read optional: those fields are now absent when `finish_reason !== "length"`. Streaming clients using `response_format` should accumulate `content` across all deltas up to `data: [DONE]`.

### FIX-0716-2: env sent as a file in a multipart deploy is no longer silently ignored

**Before**

In `multipart/form-data` for [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy), an `env` field sent as a file or Blob was silently ignored — the deploy reported success but the app started without environment variables.

**After**

Such a request returns 400 with code `VALIDATION_ERROR` and a hint to send `env` as a text field containing a JSON string.

**Impact on integrators**

The correct approach (a text `env` field with a value like `{"KEY":"value"}`) is unaffected. Anyone who sent `env` as a file or Blob now gets an explicit error instead of a false success.

### FIX-0716-3: large source.content deploys no longer fail with Gateway HTTP 413

**Before**

On some accounts [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) with `source.content` (a base64 archive) failed at the `download` step with `{ "code": "DEPLOY_FAILED", "message": "Gateway HTTP 413", "step": "download" }` whenever the base64 body exceeded ~1 MB (about 768 KB of raw `tar.gz`) — despite the documented 500 MB limit. The workaround was uploading via `source.url`.

**After**

The 500 MB inline-upload limit (`source.content` and `multipart`) applies on all accounts. `source.url` keeps working as before.

### BC-0716-4: POST /v1/infra/servers rejects unknown body fields

> Old format supported until: 15.01.2027

**Before**

An unknown field in the request body was silently ignored. A request with `deployMode: "STANDALONE"` (a non-existent field) returned `201` and created a galaxy app instead of the expected dedicated server — the real field is `placement: "dedicated"`.

**After**

[POST /v1/infra/servers](/docs/infra/servers/create) rejects a body that carries an unknown field with `400 UNKNOWN_PARAM`. `details.unknownFields` lists the extra fields, `details.suggestions` proposes the correct name (`deployMode` → `placement`), and `details.validParams` is the full list of accepted fields.

**What integrators should do**

Remove fields that are not in the create parameter list, or fix the typo using `details.suggestions`. The placement model is set via the `placement` field (`auto` by default, `dedicated` for a dedicated virtual machine).

### NEW-0716-5: /v1/sites/fields now describes the allowed values of the type field

`GET /v1/sites/fields` now returns the allowed values of the `type` field in `type.enum` with labels: `PAGE` (landing), `STORE` (online store), `KNOWLEDGE` (Knowledge Base 2.0), plus `VIBE` (a site from the constructor) and `SMN` (a link with the "Site Management" module). The `VIBE` and `SMN` values appear in responses only and are read-only — a site of that type cannot be created through the API.

### NEW-0716-6: Task favorite and pin without edit permission

Four new endpoints for per-user task actions that Bitrix24 allows with read access only (not edit): `POST /v1/tasks/:taskId/favorite` adds the task to favorites, `DELETE /v1/tasks/:taskId/favorite` removes it, `POST /v1/tasks/:taskId/pin` pins the task in the current user's task list, and `DELETE /v1/tasks/:taskId/pin` unpins it. Previously the only way to change a task was `PATCH /v1/tasks/:id`, which requires edit permission and returned "No access to edit the task", so an allowed per-user action was unreachable.

### NEW-0716-7: preemptible-plan advisory in scheduled-wake responses

The [POST /v1/infra/servers/:id/wake-schedules](/docs/infra/wake-schedules/create) and [PATCH /v1/infra/servers/:id/wake-schedules/:scheduleId](/docs/infra/wake-schedules/update) responses now also carry two additional top-level fields: `preemptibleAdvisoryCode` and `preemptibleAdvisory`. When the server runs on a preemptible plan, `preemptibleAdvisoryCode` is `"PREEMPTIBLE_BEST_EFFORT"` and `preemptibleAdvisory` is a short English explanation of the same fact: waking such a server by the window's moment is not guaranteed, and the window may be skipped when no free capacity is available. For a server on a non-preemptible plan, both fields are `null`. The advisory does not block window creation or updates — it follows the same non-blocking pattern already used by the `tzWarning`/`tzWarningCode` fields. Existing integrations that don't read the new fields keep working unchanged.