API changes: July 16, 2026

← Changelog · July 2026

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 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, 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 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 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 and PATCH /v1/infra/servers/:id/wake-schedules/:scheduleId 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.