[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"docs-bots\u002Fmanagement\u002Ftransfer":3,"docs-tabs-bots\u002Fmanagement\u002Ftransfer":6},{"content":4,"lastmod":5},"\n## Перенос владения ботом\n\n`POST \u002Fv1\u002Fbots\u002F:botId\u002Ftransfer`\n\nПереносит владение ботом на другой API-ключ того же аккаунта Битрикс24 и того же пользователя (или администратора аккаунта). Решает ситуацию, когда бот «осиротел» после пересоздания приложения: ключ-владелец отозван, и рантайм бота переставал работать. Перенос меняет только привязку ключа — `botId`, история чатов и подписки сохраняются. B24-вызов не выполняется; после переноса проверьте B24-привязку нового ключа через [`POST \u002Fv1\u002Fbots\u002F:botId\u002Freauth`](\u002Fdocs\u002Fbots\u002Fmanagement\u002Freauth).\n\n## Параметры\n\n| Параметр | Тип | Обяз. | Описание |\n|----------|-----|:-----:|---------|\n| `botId` | number | да | ID бота (path-параметр) |\n| `targetApiKeyId` | string | да | ID целевого API-ключа (тело запроса) |\n\nЦелевой ключ должен быть активен (`ACTIVE`), в том же аккаунте, что и бот, принадлежать тому же пользователю (или вызов делает администратор аккаунта), иметь область `imbot` и не быть служебным платформенным ключом (cowork, агент-сит, agent-maintenance) — у таких ключей жизненный цикл управляется платформой, бот снова «осиротеет» при их ротации.\n\n## Примеры\n\n### curl\n\n```bash\ncurl -X POST https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Fbots\u002F42\u002Ftransfer \\\n  -H \"X-Api-Key: YOUR_API_KEY\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{ \"targetApiKeyId\": \"ck_target_key_id\" }'\n```\n\n### JavaScript\n\n```javascript\nconst res = await fetch('https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Fbots\u002F42\u002Ftransfer', {\n  method: 'POST',\n  headers: { 'X-Api-Key': 'YOUR_API_KEY', 'Content-Type': 'application\u002Fjson' },\n  body: JSON.stringify({ targetApiKeyId: 'ck_target_key_id' }),\n})\nconst { data } = await res.json()\nconsole.log(data) \u002F\u002F { transferred: true, botId: 42, fromApiKeyId: '...', toApiKeyId: '...' }\n```\n\n## Поля ответа\n\n| Поле | Тип | Описание |\n|------|-----|---------|\n| `data.transferred` | boolean | `true`, если привязка изменилась; `false` — если ключ уже был владельцем (идемпотентный no-op) |\n| `data.botId` | number | ID бота |\n| `data.fromApiKeyId` | string | ID прежнего ключа-владельца (только при `transferred: true`) |\n| `data.toApiKeyId` | string | ID нового ключа-владельца |\n\n## Пример ответа\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"transferred\": true,\n    \"botId\": 42,\n    \"fromApiKeyId\": \"ck_old_owner\",\n    \"toApiKeyId\": \"ck_target_key_id\"\n  }\n}\n```\n\nЕсли целевой ключ уже владеет ботом, перенос не выполняется и возвращается `transferred: false` (при этом `fromApiKeyId` равен `toApiKeyId` — текущему владельцу).\n\n## Пример ответа при ошибке\n\n400 — целевой ключ не подходит (с уточнением в поле `reason`):\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"TARGET_KEY_INVALID\",\n    \"message\": \"Target API key is not eligible to own this bot.\",\n    \"reason\": \"wrong_user\"\n  }\n}\n```\n\n## Ошибки\n\n| HTTP | Код | Описание |\n|------|-----|---------|\n| 400 | `INVALID_BOT_ID` | `botId` не является числом |\n| 400 | `INVALID_PARAMS` | Не передан `targetApiKeyId` или он не строка |\n| 400 | `TARGET_KEY_INVALID` | Целевой ключ не подходит. `reason`: `not_active` · `wrong_portal` · `wrong_user` · `missing_scope` · `expired` · `system_key` (служебный платформенный ключ) |\n| 403 | `NOT_BOT_OWNER` | Вызывающий не владеет ботом (нужен тот же пользователь, что у ключа-владельца, или администратор аккаунта) |\n| 403 | `SCOPE_DENIED` | API-ключ не имеет области `imbot` |\n| 403 | `WRITE_BLOCKED_READONLY_KEY` | Ключ в режиме «только чтение» |\n| 404 | `BOT_NOT_FOUND` | Бот не найден в аккаунте |\n| 404 | `TARGET_KEY_NOT_FOUND` | Целевой ключ не найден |\n| 409 | `BOT_TRANSFER_NOT_ALLOWED` | Бот управляется агентом или управляемым ботом — переносите через соответствующий ресурс, а не напрямую |\n| 409 | `BOT_TRANSFER_CONFLICT` | Владение изменилось параллельным запросом — перечитайте текущего владельца и повторите при необходимости |\n\nПолный список общих ошибок API — [Ошибки](\u002Fdocs\u002Ferrors).\n\n## Известные особенности\n\n**Когда применять.** Бот перестал работать после пересоздания OAuth-приложения: ключ-владелец отозван, и рантайм бота больше не запускается. Перенос на активный личный ключ (`vibe_api_*`) того же аккаунта восстанавливает работу бота — рантайм не зависит от того, каким приложением был зарегистрирован бот.\n\n**Авторизация по пользователю, а не по ключу.** Перенос разрешён владельцу бота (тому же пользователю Vibe, что и у текущего ключа-владельца — даже если ключ уже отозван) или администратору аккаунта. Держать текущий ключ-владелец не требуется — именно поэтому перенос работает, когда исходный ключ отозван.\n\n**Идемпотентность.** Перенос на текущий ключ-владелец (в том числе отозванный) — безопасный no-op: возвращается `transferred: false`, привязка не меняется, запись в журнал не создаётся.\n\n**Проверка после переноса.** B24-вызов при переносе не выполняется. Чтобы убедиться, что новый ключ может управлять ботом, вызовите [`POST \u002Fv1\u002Fbots\u002F:botId\u002Freauth`](\u002Fdocs\u002Fbots\u002Fmanagement\u002Freauth) — он проверит B24-привязку нового ключа.\n\n## Смотрите также\n\n- [Повторная авторизация бота](\u002Fdocs\u002Fbots\u002Fmanagement\u002Freauth)\n- [Диагностика проблем](\u002Fdocs\u002Fbots\u002Ftroubleshooting)\n- [Бот-платформа](\u002Fdocs\u002Fbots)\n","2026-06-29",{}]