[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-07-04":3,"docs-tabs-changelog\u002F2026-07-04":6},{"content":4,"lastmod":5},"# API changes: July 4, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [July 2026](\u002Fdocs\u002Fchangelog\u002F2026-07)\n\n### BC-0704-1: Overload rejections: 429\u002F503 instead of 504\n\n> Old format supported until: 31.07.2026\n\nOverload 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.\n\n**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 `\u002Fv1\u002Fsearch` — the upstream provider did not respond in time) 504→503; `RUNTIME_TIMEOUT` \u002F `GATEWAY_TIMEOUT` \u002F `WAKE_TIMEOUT` 504→503.\n\n### NEW-0704-2: New AI overload code: 429 ai_congested\n\nAI 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.\n\n### BC-0704-3: read-only (READONLY) keys can no longer write on hand-written endpoints\n\n> Old format supported until: 03.07.2026\n\n**Before**\n\nAn 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\u002Fnote\u002Fbind, telephony, mail, disk, business processes, user invite and deactivation, and others) — the guard checked only the scope, not the key access mode.\n\n**After**\n\nAny write attempt with a read-only key returns `403` with the `WRITE_BLOCKED_READONLY_KEY` code. Read endpoints are not affected.\n\n**What integrators should do**\n\nIf your integration was writing with a read-only key, switch the key to read and write mode on the key management page.\n\n### FIX-0704-4: galaxy app deploy now unpacks wrapped archives correctly and reports an empty source.content clearly\n\n**Before**\n\n[POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdeploy](\u002Fdocs\u002Finfra\u002Fdeploy) 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.\n\n**After**\n\nSuch 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.\n",null,{},1794739469453]