API changes: July 20, 2026

← Changelog · July 2026

NEW-0720-1: Application responses now return the publication status

Application responses — list, app data, create, publish, and unpublish — now carry two new fields: catalogStatus (PRIVATE / PUBLISHED / UNPUBLISHED) and publishedAt (the publication date, ISO 8601, or null). Previously the publication status could not be read via V1 — you had to guess from the placements array, which is unreliable: an unpublished application may keep its previously bound codes, and PRIVATE and UNPUBLISHED are indistinguishable by placements. The fields are additive — existing calls keep working.

FIX-0720-2: chat rename no longer reports a false success to a non-participant

Before

PATCH /v1/chats/:chatId called by a Bitrix24 account administrator who is not a member of the chat returned { "success": true, "data": true } even though the chat title never changed: Bitrix24 answered such a call with a false success. The response gave no way to tell it apart from a real rename, so an integrator treated the operation as done. The caller could not even read that chat.

After

Membership is now checked before the rename. If the caller is not a member, the response is 404 CHAT_NOT_FOUND_OR_NO_ACCESS — the same as for any other non-participant — and no rename is attempted. The false success is gone. A rename by a member who has the rights works exactly as before.

NEW-0720-3: streaming chat-completions now ends a stalled upstream response with an explicit error

When a streaming call (POST /v1/chat/completions with stream: true) receives headers but the upstream model then goes silent mid-response and sends no new data for longer than the idle window, the proxy now terminates the call and emits a terminal error frame before data: [DONE]:

data: {"error":{"code":"stream_idle_timeout","type":"server_error","retryable":true,"retryAfter":<seconds>}}

Previously such a call hung indefinitely (the agent stayed in a "receiving stream response" state). The error is retryable — read the stream through to [DONE] and retry, honoring retryAfter. Normal (non-stalled) streams and reasoning models that continuously emit thinking tokens are unaffected.

NEW-0720-4: tasks: new timeSpentInLogs field

The timeSpentInLogs field (actual tracked time in seconds, summed from the time-tracking log) is now declared in the tasks schema — available in select, filter, and sort on GET /v1/tasks and POST /v1/tasks/search, and present in GET /v1/tasks/fields.

Previously the field was returned only when select contained BOTH spellings at once (timeSpentInLogs and TIME_SPENT_IN_LOGS); either one alone now works. The field is read-only — recorded via the time-tracking endpoint, not via a task update.

FIX-0720-5: GET /v1/files/:id?include=folder now returns the folder

Before

GET /v1/files/:id with ?include=folder answered 200 but without the _included block, even though GET /v1/files/fields advertised folder as includable — the include silently did nothing.

After

?include=folder attaches the folder under _included.folder, as /fields promises.

Impact on integrators

No action required. Clients reading _included.folder now get the object instead of nothing.

FIX-0720-6: /v1/me: infra block now accurate for server cap, provider id, and breakdown

Before

GET /v1/me returned infra.limits.max: 3 regardless of the enforced per-key server cap; infra.providers could return an internal provider id (disagreeing with GET /v1/infra/providers) with possible duplicates; infra.limits.breakdown counted managed-bot VMs under direct instead of bots.

After

infra.limits.max reflects the enforced per-key server cap; infra.providers returns the public provider id, consistent with GET /v1/infra/providers, with duplicates removed; infra.limits.breakdown counts bot VMs under bots. No integration change is needed — the values are simply correct now.

FIX-0720-7: deal-categories: unknown filter fields are rejected, sort by id respects direction

Before

GET /v1/deal-categories with a filter on an unknown field silently returned the WHOLE pipeline table with 200 — Bitrix24 ignores unknown filter keys of the legacy method and returns the entire list. And the sort ?sort=id&order=desc ignored the direction, always returning the same order.

After

A filter on an unknown or unsupported field (as well as operator prefixes >/>=/!/… and operator objects) is rejected before the Bitrix24 call with 400 UNSUPPORTED_FILTER; the message lists the filterable fields (id, name, sort). Exact-match and $in filters on those fields work as before. The sort ?sort=id now correctly respects asc/desc.

FIX-0720-8: openline-configs: unrecognised fields in a write body no longer vanish silently

Before

POST /v1/openline-configs (and PATCH) silently ignored unrecognised body fields — Bitrix24 drops unknown keys of the imopenlines.config.* method. A body of only unknown fields then created a configuration with default values and returned 200.

After

If the body has NO known field, the request is rejected with 400 VALIDATION_ERROR before the Bitrix24 call, and the message lists the unrecognised fields. If a known field is present but some fields are unrecognised, the write proceeds as before, and the response carries meta.warnings listing the ignored fields (previously they disappeared without a trace). Read-only fields (id, queue, dateCreate and others) in a write body are now rejected with 400 READONLY_FIELD — previously they passed as "known" and could lead to a configuration created with default values.

FIX-0720-9: GET /v1/{entity}/fields signals partial metadata on a Bitrix24 failure

Before

When the dynamic field fetch to Bitrix24 (*.fields) failed (rate limit, QUERY_LIMIT_EXCEEDED, queue timeout), the endpoint silently returned 200 with only the static schema fields — many of which have no human-readable label. The response looked complete, so a client could not tell it apart from a correct one and built non-deterministic field mappings.

After

On a field-fetch failure the response is still 200 with the static fields, but now carries meta.warnings: [{ "code": "fields_partial", "message": "..." }] so the client can detect the incomplete set and retry. The warning is an object { code, message } — the same channel and shape as meta.warnings on list/search, so a single warning.code parser works across every endpoint. The failure is now also logged on the Vibe side.