# API changes: July 4, 2026

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

### BC-0704-1: Overload rejections: 429/503 instead of 504

> Old format supported until: 31.07.2026

Overload rejections changed HTTP status codes (body codes are UNCHANGED — only the status changes). Rule of thumb: **429** — the request was NOT processed, safe to retry after `Retry-After` (the header is now always set); **503** — the platform or upstream is unhealthy, retry later; for write operations verify whether the change was applied before retrying. Application-level 504 is removed from the API.

**What changed:** `QUEUE_OVERFLOW` 503→429; `QUEUE_TIMEOUT` 504→429; `BITRIX_TIMEOUT` (Bitrix24 did not respond within 15 seconds — the write may have been applied, re-read the entity before retrying) →503; `ai_provider_timeout` 504→503; `UPSTREAM_TIMEOUT` (web search `/v1/search` — the upstream provider did not respond in time) 504→503; `RUNTIME_TIMEOUT` / `GATEWAY_TIMEOUT` / `WAKE_TIMEOUT` 504→503.

### NEW-0704-2: New AI overload code: 429 ai_congested

AI requests to the platform cluster now pass through an admission gate: on pool overload the response is `429` with body code `ai_congested` and a `Retry-After` header. Retry is safe (the request never ran, no charge). BYOK keys and external providers are not affected. Disabled by default — enabled by the platform.

### BC-0704-3: read-only (READONLY) keys can no longer write on hand-written endpoints

> Old format supported until: 03.07.2026

**Before**

An APP key with the `accessMode: READONLY` access mode still reached the write to Bitrix24 on a number of hand-written endpoints (requisites and presets, user fields, timeline pin/note/bind, telephony, mail, disk, business processes, user invite and deactivation, and others) — the guard checked only the scope, not the key access mode.

**After**

Any write attempt with a read-only key returns `403` with the `WRITE_BLOCKED_READONLY_KEY` code. Read endpoints are not affected.

**What integrators should do**

If your integration was writing with a read-only key, switch the key to read and write mode on the key management page.

### FIX-0704-4: galaxy app deploy now unpacks wrapped archives correctly and reports an empty source.content clearly

**Before**

[POST /v1/infra/servers/:id/deploy](/docs/infra/deploy) for a galaxy app (`kind=GALAXY_APP`) whose `source.content` project files sat inside a single wrapping folder (a typical macOS-built zip) built the app with an empty build context and failed at runtime with `npm error enoent Could not read package.json`. When `source.content` did not unpack into any files at all (a versionId, a path, or an empty archive), the deploy raised the same confusing build error.

**After**

Such archives now deploy correctly — the app files end up at the build-context root. And when `source.content` unpacks to an empty context, the deploy returns `GALAXY_APP_BUILD_FAILED` right away with a clear empty-build-context message, hinting that `source.content` must be a base64 archive (tar.gz or zip) of your project files, not a versionId or a path.