[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-10-18":3,"docs-tabs-changelog\u002F2026-10-18":6},{"content":4,"lastmod":5},"# API changes: October 18, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [October 2026](\u002Fdocs\u002Fchangelog\u002F2026-10)\n\n### FIX-1018-1: a late wake cancellation does not stop a ready server\n\n**Before**\n\n[POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fwake](\u002Fdocs\u002Finfra\u002Flifecycle\u002Fwake) with `wait=true` could report an error and stop an already ready server if its state changed at the end of the wait. The same affected the automatic wake of a sleeping server before [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdeploy](\u002Fdocs\u002Finfra\u002Fdeploy\u002Fdeploy), [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fexec](\u002Fdocs\u002Finfra\u002Fdeploy\u002Fexec), [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fupload](\u002Fdocs\u002Finfra\u002Fdeploy\u002Fupload) and [GET \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Flogs](\u002Fdocs\u002Finfra\u002Fdeploy\u002Flogs).\n\n**After**\n\nIf cancellation no longer applies to the server's current state, it does not stop the server. A ready server in the `running` state with a connected tunnel and no wake block returns success. If readiness cannot be confirmed, the response is `502 WAKE_FAILED`. If startup has already been refused for lack of capacity, `503 WAKE_NO_CAPACITY` is preserved. An ordinary timeout that returns the server to `sleeping` still gives `503 WAKE_TIMEOUT`.\n\n**Impact on integrators**\n\nThe response shape and request parameters are unchanged. After `WAKE_FAILED`, check the current state through [GET \u002Fv1\u002Finfra\u002Fservers\u002F:id](\u002Fdocs\u002Finfra\u002Fservers\u002Fget) before taking the next action.\n\n### FIX-1018-2: Creating departments in a batch\n\n**Before:** `POST \u002Fv1\u002Fhumanresources\u002Fnodes\u002Fbatch` with `action: \"create\"` returned `ERROR_METHOD_NOT_FOUND` for every item, although individual creation worked.\n\n**After:** creation uses REST 3.0 with a separate result and node ID for each successful item. The response remains HTTP 200; partial failure preserves the other items' results. Each item requires a separate Bitrix24 call; creation within a list is sequential to avoid conflicts on the shared structure. An uncertain write carries `details.outcome: \"unknown\"` and `details.retryable: false`: check the Bitrix24 account before trying again. An incomplete response without a node ID receives `WRITE_OUTCOME_UNKNOWN`. Batch update is outside this correction.\n",null,{},1794739484244]