Bitrix24 Internal Chat Bot Development

Imagine a sales team of 12 managers spending 20 minutes per day on average searching for tasks and contacts in Bitrix24. An internal chatbot can automate these queries, responding to commands like /deals or /client in seconds. We develop bots for Bitrix24's internal chat from scratch: from registering in the im module to asynchronous architecture and OAuth authorization.

Bitrix24's internal chat is not just a messenger — it handles CRM notifications, task reminders, and alerts from external systems. A bot automates the routine: answers employee questions, aggregates data from different modules, and executes commands directly from the chat window. Our experience includes 50+ projects for sales, HR, and IT support departments. The bot works via Bitrix24 REST API and can perform actions on behalf of a user.

What an internal bot offers compared to a client-facing one

A client-facing bot works in open channels and is limited: it has no access to CRM or tasks. An internal bot, on the other hand, gets full access to portal data via REST API, can use a specific user's permissions, and send rich messages to group chats. Registration is done via imbot.register without the OPENLINE: Y flag. This makes it three times more effective for internal process automation.

Typical scenarios and their implementation

HR bot

An employee types /vacation 15.07-28.07 → the bot creates a vacation request via timeman.absence.create, notifies the manager, and marks days in the calendar via calendar.event.add. No need to navigate through Bitrix24 sections.

Reporting bot

A manager types /report sales june → the bot makes a crm.deal.list request with filters by date and responsible person → generates a summary right in the chat: deal count, total amount, conversion by stages.

On-duty bot

Monitors external systems (server, website, task queue) → when thresholds are exceeded, sends an alert to the engineer on duty with buttons "Accepted", "Escalate".

IT helpdesk bot

An employee describes a problem → the bot creates a task in the tech support project via tasks.task.add, assigns a performer by rotation, and sends the ticket number. Ticket status can be queried with /ticket 1234.

Registration and command handling

The bot is registered with a command handler:

POST /rest/imbot.register { "CODE": "internal_helper", "EVENT_MESSAGE_ADD": "https://your-server.com/internal-bot/message", "EVENT_COMMAND_ADD": "https://your-server.com/internal-bot/command", "OPENLINE": "N" } 

Commands are registered via imbot.command.register:

{ "BOT_ID": 456, "COMMAND": "report", "COMMON": "Y", "HIDDEN": "N", "EXTRANET_SUPPORT": "N", "LANG": [{"LANGUAGE_ID": "en", "TITLE": "Sales report", "PARAMS": "period"}] } 

After registration, the command appears in chat autocomplete when typing /. More details on REST API can be found in the official documentation.

Step-by-step registration guide

1. Create an application in Bitrix24 (Developers section).
2. Obtain the application code and set up event handlers.
3. Execute imbot.register with your server handler.
4. Register commands via imbot.command.register with parameters.
5. Set up webhook processing and return 200 OK.

Case study: bot for a sales department

Task: 12 managers frequently ask "how many open deals do I have", "when was the last contact with client X", "what are today's tasks". The client — a company with over 500 deals monthly.

Implementation: Python (FastAPI) + Bitrix24 REST API. Commands:

• /deals → list of a manager's open deals with amounts and stages.
• /client [name] → search for a contact with last activity.
• /tasks → today's tasks with deadlines.
• /call [phone] → initiate an outgoing call.

Authorization: the bot uses the user's token obtained via OAuth on first contact. Tokens are stored in Redis with a TTL of 30 days.

Savings: 15–20 minutes per manager per day, which at an average salary translates to a 30% reduction in routine costs. Load is minimal — 3–5 API requests per command. Payback period: less than a month.

The main challenge: token rotation. Bitrix24 REST tokens last 1 hour, refresh tokens 30 days. If a user doesn't interact with the bot for 30 days, re-authorization is needed. Solution: use a webhook instead of OAuth for portal applications (webhook never expires but uses application permissions, not a specific user's).

Why asynchronous processing is mandatory

The bot service must respond to a Bitrix24 webhook within 3 seconds. Otherwise, Bitrix24 considers the request unsuccessful and repeats it, leading to duplicate messages. Asynchronous processing reduces duplicates by 10x compared to a synchronous approach.

Correct architecture:

1. The webhook receives the request, immediately returns 200 OK.
2. The task is placed in a queue (Redis Queue, RabbitMQ).
3. A worker processes the task asynchronously, replies via imbot.message.add.

Effort estimation

What is included in the work?

• Full cycle: scenario audit, prototyping, development, testing, deployment.
• Documentation for commands and operations.
• Setup of monitoring and alerting.
• Administrator training.
• 6-month warranty on code.

Get a consultation on your bot's architecture — our engineers are 1C-Bitrix certified with 5+ years of bot development experience. Contact us — we will evaluate your project within one day.