AiHummer
Русский▾
ВойтиЛичный кабинет
v1.4.x▾
{ }Swagger

Плагин Bitrix24

v1.4.x · обновлено 2026-10-14

Поддерживаются внутренние чаты Bitrix24. Открытые линии, очередь клиентских обращений и передача оператору не поддерживаются.

Плагин Bitrix24 подключает вашего агента к Bitrix24 как внутренний мессенджер для сотрудников. Сотрудники пишут агенту так же, как написали бы коллеге, а агент отвечает прямо в чате Bitrix24.

[!WARNING] Bitrix24 здесь — это внутренний мессенджер для сотрудников, как Telegram или Slack для персонала. Это не клиентский омниканал: нет Открытых линий, нет очереди клиентских обращений и нет передачи диалога оператору. Не используйте этот плагин как фронт клиентской поддержки.

Плагин работает напрямую в Linux (без контейнеров) и общается со шлюзом по контракту aihummer.connector.v1. Поведение канала для конечного пользователя — на странице канала Bitrix24; эта страница про сам плагин.

Описанные ниже медиа и общее OAuth-подключение требуют подписанного Core 1.4.15 и отдельно подписанного коннектора 1.1.1 после публикации в каталоге и обновления. Установленный коннектор 1.1.0 не подтверждает доступность этих возможностей.

Факты

Поле Значение
Версия 1.1.1
Порт 8810
Среда без контейнеров (systemd)

Что это такое

Двусторонний мост между чатом Bitrix24 и AiHummer. Каждый агент аутентифицируется своей отдельной OAuth-учётной записью, а не общим bot-аккаунтом, поэтому в Bitrix24 агент отображается как отдельный коллега, а не как общий бот. Доступ следует ACL по дереву подразделений организации, так что доступ агента соответствует организационной структуре в Bitrix24.

Укажите отдельных пользователей портала в BITRIX24_AGENT_USER_IDS, а портал — в BITRIX24_PORTAL. Маршрутизация по отделам ограничивает допуск сотрудников; учётная запись агента не подменяет инициатора задачи. Необязательное существующее автоматическое подключение использует BITRIX24_ADMIN_LOGIN / BITRIX24_ADMIN_PASSWORD.

При указанных версиях BITRIX24_VAULT_CONNECTIONS выбирает для канала существующее действующее OAuth-подключение в автономном режиме, принадлежащее регистрирующему пользователю. Используйте поддерживаемое управление нативным хранилищем и подключениями; тот же ID учётных данных выбирается в привязках инструментов. Настоящий владелец регистрирует работающий коннектор в его рабочем пространстве через /v1/admin/connections/channel с отдельным ключом connection-token. В секретной настройке BITRIX24_VAULT_CONNECTIONS задайте endpoint и apiKey по ID пользователя-агента; никогда не помещайте их в профили или запросы агенту. Только хранилище обновляет токены; инструменты сохраняют проверки инициатора и общего доступа. См. OAuth2.

Как используется

  • Входящие: опрос читает сообщения. Медиа скачивается байтами и регистрируется через /v1/inbound/media; агент получает media_id, а не только URL или сведения о файле.
  • Исходящие: Deliver переводит Markdown в BB-code и загружает настоящие байты через im.v2.File.upload. Подтверждение медиа требует настоящих FILE_ID и ID сообщений; текст или ссылка не являются квитанцией файла.

Сохраняйте долговечный журнал доставки при обновлении. Повтор подтверждённой операции возвращает прежнюю квитанцию. Частичный или неизвестный эффект автоматически не отправляется повторно; проверьте его перед повтором.

сотрудник ─▶ чат Bitrix24 ─▶ pull-опрос ─▶ шлюз (маршрутизатор · обработка) ─▶ Deliver (Markdown→BB-code, идемпотентно) ─▶ Bitrix24

Поддерживаемые возможности

  • Реакции и @-упоминания.
  • Набор и ответы, если аккаунт и площадка поддерживают im.dialog.writing и REPLY_ID.
  • Входящие изображения, аудио, голос и файлы с учётом требований к версиям выше.
  • Редактирование/удаление сообщений — только у прежних интеграций с отдельной идентичностью бота; для обычного OAuth-пользователя они не объявляются.

Ограничения

[!WARNING] Интерактивные клавиатуры, кнопки и треды не поддерживаются.

Созданный или подготовленный файл ещё не означает подтверждённую доставку. Частичные, неуспешные и неизвестные результаты должны оставаться видимыми.

Установка

Установите Bitrix24 в один клик из маркетплейса в админ-панели. Deployer скачивает плагин, выполняет шаг установки, генерирует изолированный systemd-юнит и считает установку успешной только после ответа /healthz — см. Установка и обновления. Затем вы подключаете OAuth-учётную запись каждого агента и сопоставляете ACL по дереву подразделений.

Безопасность и ограничения

  • Только внутренний мессенджер для сотрудников — не клиентский омниканал.
  • Отдельная OAuth-учётная запись на каждого агента — агенты не общие bot-аккаунты.
  • ACL по дереву подразделений — доступ соответствует организационной структуре.
  • Без контейнеров — работает под systemd, не в контейнере.

Куда дальше