Опубликовать приложение

POST /v1/apps/:id/publish

Переводит приложение в PUBLISHED, привязывает места встраивания к порталу и делает приложение видимым всем сотрудникам.

Параметры

Поля запроса (body)

Тело необязательное. При пустом теле берутся значения из записи приложения — это основной сценарий повторной публикации без изменений. Если передаёте тело, добавьте заголовок Content-Type: application/json — без него запрос с телом вернёт 413 PAYLOAD_TOO_LARGE.

Примеры

curl — личный ключ

curl -X POST "https://vibecode.bitrix24.tech/v1/apps/YOUR_APP_ID/publish" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "placements": ["CRM_DEAL_DETAIL_TAB"] }'

curl — OAuth-приложение

curl -X POST "https://vibecode.bitrix24.tech/v1/apps/YOUR_APP_ID/publish" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "placements": ["CRM_DEAL_DETAIL_TAB"] }'

JavaScript — личный ключ

const res = await fetch(
  'https://vibecode.bitrix24.tech/v1/apps/YOUR_APP_ID/publish',
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_API_KEY',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ placements: ['CRM_DEAL_DETAIL_TAB'] }),
  }
)
const body = await res.json()
if (!body.success) throw new Error(body.error.code)
// body.warnings — нефатальные пояснения; отказ привязки возвращает PLACEMENT_BIND_FAILED
console.log(body.data.placements)

JavaScript — OAuth-приложение

const res = await fetch(
  'https://vibecode.bitrix24.tech/v1/apps/YOUR_APP_ID/publish',
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ placements: ['CRM_DEAL_DETAIL_TAB'] }),
  }
)

Поля ответа

Пример ответа

Поле data повторяет объект приложения с заполненным массивом placements:

{
  "success": true,
  "data": {
    "id": "33c4d5e6-f7a8-49b0-1234-5c6d7e8f9012",
    "title": "Дашборд продаж",
    "description": null,
    "scopes": ["crm", "user", "placement"],
    "handlerUrl": "https://vibecode.bitrix24.tech/v1/bitrix-handler",
    "appUrl": "https://app-abc12345.vibecode.bitrix24.tech",
    "redirectUris": [
      "https://vibecode.bitrix24.tech/oauth/complete",
      "http://localhost"
    ],
    "bitrixClientId": "local.7c3d4e5f6a7b80.55556666",
    "prefix": "vibe_app_local_7c3",
    "suffix": "6666",
    "authorId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "authorBitrixUserId": 42,
    "authorBitrixUserIdSource": "member",
    "portalId": "8b1f0e2a-3c4d-5e6f-7a8b-9c0d1e2f3a4b",
    "createdAt": "2026-06-24T09:12:45.781Z",
    "updatedAt": "2026-06-24T10:03:18.204Z",
    "placements": ["CRM_DEAL_DETAIL_TAB"],
    "catalogStatus": "PUBLISHED",
    "publishedAt": "2026-06-24T10:03:18.204Z"
  }
}

Пример ответа при ошибке

400 — у OAuth-ключа нет скоупа placement:

{
  "success": false,
  "error": {
    "code": "MISSING_SCOPE",
    "message": "OAuth API key must have the placement scope to publish (catalog publishing binds placements on Bitrix24)."
  }
}

Ошибки

Полный список общих ошибок API — Ошибки.

Поля отказа `PLACEMENT_BIND_FAILED`

Проверка снятия лишних мест встраивания на стороне аккаунта сейчас раскатывается по аккаунтам, поэтому вариантов два:

• Пока возможность не включена на аккаунте — публикация отвечает 200, даже если снять лишние места на аккаунте не удалось. Неснятый код при этом ОСТАЁТСЯ в placements приложения, а причина приходит строкой Failed to unbind <код> в warnings. Это единственный признак расхождения списка с аккаунтом, поэтому сейчас warnings надо разбирать. Кодов PLACEMENT_UNBIND_FAILED и NETWORK_DEVKEY_REQUIRED у этого эндпоинта не бывает.
• После включения — неподтверждённое снятие отвечает 502 PLACEMENT_UNBIND_FAILED со списком кодов в error.placements, а приложение не публикуется вовсе. Ответа 200 с неснятым местом на этом пути не бывает — про снятие в warnings успешного ответа остаются пояснения о подтверждении: каким транспортом снятие подтверждено и отказал ли при этом второй.

Отказ запрошенной привязки не зависит от этого флага: на обеих сторонах раскатки он отвечает 502 PLACEMENT_BIND_FAILED и не переводит приложение в PUBLISHED. Если в том же запросе не подтверждено и снятие старого места, внешний код всё равно остаётся PLACEMENT_BIND_FAILED, а старое место попадает в error.failedUnbinds. Если ключ разработчика отклонён с HTTP 401 только из-за учётных данных, а у приложения есть OAuth-токен, публикация сначала повторяет привязку по OAuth; успешный отход остаётся ответом 200 и фиксируется в аудите. Явная неавторизационная причина — например, подписочный гейт или нехватка прав — остаётся окончательной при любом HTTP-статусе и никогда не повторяется по OAuth.

Отказ 502 здесь не означает «ничего не изменилось». Поле placements приложения записывается ДО того, как выносится отказ, и уже отражает фактическое состояние аккаунта: успешно снятые коды из него ушли, а неподтверждённые остались. Поэтому перед повтором перечитайте приложение через данные приложения. Повторный запрос без поля placements опубликует ровно тот набор, который лежит в приложении сейчас, — вместе с местом, которое вы считали снятым. Чтобы снять его, повторите запрос с явным placements без этого кода.

Известные особенности

• OAuth-авторизация даёт основной или резервный транспорт. На аккаунте без ключа разработчика привязку выполняет OAuth-токен. Если выбран ключ разработчика и Битрикс24 отклоняет его с HTTP 401 только из-за учётных данных, тот же OAuth-токен становится резервным каналом. Явные коды подписочного гейта окончательны при любом HTTP-статусе и в этот fallback не попадают. Без доступного транспорта публикация возвращает NO_USER_TOKEN или NETWORK_DEVKEY_REQUIRED. Порядок авторизации — Авторизация пользователей приложения.
• Вход на странице самого приложения токен приложения не создаёт. Кнопка «Войти через Bitrix24» на адресе вашего приложения выдаёт доступ к приложению — это другая поверхность, и на NO_USER_TOKEN при публикации она не влияет. Токен появляется только на согласии OAuth на стороне портала: авторизация по ссылке выше, установка приложения на портал или первое открытие встроенного места. Если после входа на странице приложения публикация всё ещё отвечает NO_USER_TOKEN — авторизации на портале не было.
• Токен живёт долго и продлевается сам. Авторизация нужна один раз, а не перед каждой публикацией: платформа обновляет токен по refresh-токену. Повторная авторизация требуется, только если доступ отозвали на портале или OAuth-приложение пересоздали.
• autoSaved: true у деплоя не всегда закрывает проверку публикации. Автосейв деплоя сохраняет исходники у того сервера, на который вы деплоили. Если этот сервер принадлежит не OAuth-ключу публикуемого приложения (например, вы деплоили личным ключом vibe_api_), снапшот хранится у сервера — проверка публикации по умолчанию смотрит снапшоты приложения и его не видит. Передайте sourceServerId того же сервера, и публикация возьмёт исходники оттуда — повторно сохранять их через POST /v1/apps/:id/sources не нужно. Идентификатор сервера — тот же, что в адресе деплоя. Список снапшотов сервера — GET /v1/infra/servers/:serverId/sources.
• Заголовок места встраивания — это название приложения. Пункт левого меню и вкладки CRM подписываются итоговым catalogTitle, отдельного названия для меню нет. Переименование приложения через обновление меняет и подписи мест встраивания.
• Пункт левого меню у приложения уже есть. Приложение появляется в меню аккаунта сразу после создания, без публикации и без мест встраивания. Место LEFT_MENU добавляет к нему второй пункт меню со своим адресом на аккаунте. В Вайбкод приложение при этом одно, и привязанные места показывают одну запись LEFT_MENU. Если второй пункт не нужен, не передавайте LEFT_MENU в placements. У опубликованного приложения лишний пункт снимается отвязкой кода LEFT_MENU или обновлением с placements без этого кода. Пункт, появившийся при создании, при этом остаётся.
• Снятые с публикации приложения публикуются повторно. Публикация принимается и в статусе UNPUBLISHED — приложение возвращается в PUBLISHED с теми же или новыми местами встраивания. Метаданные каталога при снятии с публикации сохранялись, поэтому при пустом теле каталог восстанавливается без повторного заполнения.
• Каждое запрошенное место должно привязаться. Коды привязываются отдельно, поэтому часть из них может успеть записаться на аккаунте. Если хотя бы одна привязка не подтверждена, публикация отвечает 502 PLACEMENT_BIND_FAILED, приложение не становится PUBLISHED, а успешно привязанные коды уже остаются в его поле placements.

Смотрите также

• Приложения
• Авторизация пользователей приложения
• Снять с публикации
• Обновить приложение
• Данные приложения
• Хранилище исходников
• Подписки на события портала