API changes: July 4, 2026

← Changelog · July 2026

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 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.