Bitrix24 integration with Slack

Bitrix24 and Slack Integration

Your team works in Slack, but management set up Bitrix24 for CRM and tasks. Within a week, chaos begins: deal notifications get lost in Slack channels, tasks are duplicated manually, and half the conversations happen in a messenger that CRM can't see. Syncing two tools by hand guarantees information loss and frustrated employees.

Integration Architecture

The connection is built using a webhook mechanism: Bitrix24 sends outbound webhooks on CRM events, tasks, and chats, while Slack receives them via Incoming Webhooks or a Slack App with event subscriptions. Between them sits a middleware server that routes data, transforms formats, and handles logic.

Data flow schema:

B24 (event) → Outbound Webhook → Middleware → Slack Incoming Webhook → channel/DM
Slack (team/event) → Slack Events API → Middleware → B24 REST API → CRM/tasks/chat

Middleware is necessary because B24 and Slack use different payload formats. B24 sends data as application/x-www-form-urlencoded, Slack expects JSON with Block Kit markup. Middleware transforms one into the other and adds business logic.

Notification Routing

The key task is delivering B24 notifications to the right Slack channels, not dumping everything into one stream.

We set up mapping:

For each event type in B24, a handler is registered via event.bind. Middleware receives the payload, determines the event type, fetches additional data via REST API (for example, responsible person's name via user.get), and formats a Slack message with Block Kit blocks.

Channel-to-Chat Mapping

Reverse sync: messages from Slack channels are relayed to B24 group chats. This ensures employees who don't use Slack see discussions in their familiar interface.

Technical implementation:

1. Slack App subscribes to message.channels events via Events API.
2. On new message in a mapped channel, middleware receives the payload.
3. Middleware sends the message to the corresponding B24 chat via im.message.add, specifying SYSTEM_ID to identify the source.
4. The author's name from Slack is passed in the message prefix — B24 shows who wrote it.

Reverse direction: on new message in a B24 chat, the ONIMBOTMESSAGEADD event fires (if a bridge bot is added to the chat). Middleware forwards the text to the linked Slack channel.

Important: files and images are transferred via temporary links. Middleware downloads a file from one system, uploads it to the other via the respective API (files.upload for Slack, disk.file.uploadtofolder for B24).

Slash Commands and Slack Bot

Register Slack commands that call B24:

• /b24-lead Company | Comment — creates a lead in CRM via crm.lead.add. Returns a link to the created lead.
• /b24-task Name | Description | @assignee — creates a task via tasks.task.add. Finds a user in B24 by email linked to Slack account.
• /b24-deal ID — shows deal information: stage, sum, responsible, next activity.
• /b24-status — outputs summary: lead count for today, user's open tasks, missed calls.

Each command sends a POST request to middleware. Middleware authenticates the user (Slack User ID → B24 User ID mapping via a lookup table), executes the B24 REST API request, and returns the response in Slack as an ephemeral message (visible only to the command author) or an in-channel message.

User Mapping

For correct operation, a user correspondence table is needed. Two approaches:

• By email. Middleware matches email from Slack profile with B24 user email (via user.get with filter). Works automatically if emails match.
• Manual mapping. Administrator sets pairs via middleware interface. Needed when emails differ or one person uses multiple accounts.

Without mapping, the bot won't create tasks from the right user or route personal notifications.

Error Handling and Queues

Slack and B24 are external services. Both can be unavailable. Middleware uses a message queue (Redis or RabbitMQ):

• If Slack doesn't respond within 3 seconds — message goes to retry queue with exponential backoff.
• If B24 returns QUERY_LIMIT_EXCEEDED (2-request-per-second REST API limit) — middleware waits and retries.
• All unsent messages are saved and processed when connectivity is restored.

Logging: every request is recorded with timestamp, event type, delivery status. Administrator sees the queue and errors in the middleware dashboard.

Security

• Slack Signing Secret — middleware verifies the signature of each incoming request to prevent spoofing.
• B24 webhook tokens — REST API access via OAuth 2.0 with limited scope (only needed methods).
• Middleware is accessible only over HTTPS. CRM data (client names, deal amounts) passes through your server — no third-party intermediaries.

What We Deploy

• Middleware server for bidirectional B24 and Slack sync
• Notification routing from CRM, tasks, and calls to Slack channels
• Bidirectional message sync between B24 chats and Slack channels
• Slash commands for working with CRM and tasks directly from Slack
• User mapping between systems
• Message queue with retry mechanism and logging