Bitrix24
Open channels as a second operator workplace: the setup order, the scopes, what happens to messages.
The model #
For us a CRM is not a separate channel but a second workplace for the operator. The message comes from the widget, the connector shows it in an open channel and returns the manager's reply to the visitor. Telegram can stay on: a reply from either place is visible in both.
We do not import past conversations into the portal: they would arrive as an avalanche of new ones and ruin the statistics.
The setup order #
| Step | Where | What |
|---|---|---|
| 1 | Portal | Developers → Other → Local application, API only |
| 2 | Portal | scopes imopenlines, imconnector, im |
| 3 | Dashboard | portal domain, client_id, client_secret → Save the keys |
| 4 | Portal | paste the install link from the dashboard into Handler path and install |
| 5 | Portal | in the settings of the open channel you need, pick the WidgetChat channel |
A local application works immediately — no Bitrix24 Marketplace review is needed.
The exchange #
Every event's authenticity is checked against application_token before any work: the handler address is not a secret, the client's portal sees it.
Attachments go out as temporary signed links — the portal downloads the file on its side.
| Direction | What happens |
|---|---|
| outbound | imconnector.send.messages: the message and replies from other workplaces |
| inbound | OnImConnectorMessageAdd: the manager's reply joins the visitor's conversation |
| inbound | OnImConnectorDialogFinish: the conversation is closed |
| inbound | OnImConnectorLineDelete, OnImConnectorStatusDelete: the connection goes dark |
| outbound | imconnector.send.status.delivery: the delivery mark for the manager |
Limits and failures #
OPERATION_TIME_LIMIT locks the portal for ten minutes. For that time the tasks are postponed as a whole rather than burnt through as attempts: three queue attempts would pass in fifteen seconds, and every arriving message would end up in the dead list.
The token pair lives an hour and is refreshed under a per-workspace lock. Whatever did not go through is visible in the exchange log in the dashboard.
Tested on a real cloud Bitrix24 portal of our own; the first client connection we do together with the client.