WhatsApp Setup in Bitrix24: Official API and Wazzup

Connecting WhatsApp to Bitrix24: Where Correspondence Gets Lost

A client writes on WhatsApp — the fastest channel, and they choose it themselves. A manager replies from a personal number, and only a note "call completed" remains in Bitrix24.

Correspondence with the client in the messenger lives on the employee's phone, not in the deal card.

Then a quiet loss of inquiries begins. The client returns with a question discussed a week ago, and there is no way to pull up the history: messages are on someone else's phone, attachments in someone else's gallery, agreements are not recorded anywhere.

When the deal is handed over, the colleague sees an empty card and asks the client the same questions again.

A separate cost is an employee's departure. The manager's personal number leaves with them: all correspondence on active deals disappears, while clients keep writing to the same chat and get no answer. It cannot be restored from Bitrix24 — that data simply was not there.

Technically, the gap is explained by the fact that the messenger and CRM have no common entry point.

Messages are not linked to a contact and deal, the client has no single identifier — the same person is created in the database several times, and the responsible manager has to be determined manually.

Connecting WhatsApp to Bitrix24 closes exactly this gap: the number becomes corporate, correspondence goes into the card, history stays with the company, not with the employee. We explain how this works and what changes in the department's work.

What Changes After Moving Correspondence into the Deal Card

Dialogues from the messenger go not to the manager's phone, but to the deal card in Bitrix24 — and from there they work as part of the client history. Below is what changes in measurable terms, not in feelings.

A Single Correspondence Window Instead of Personal Phones

Inquiries from all channels converge in one place with links to the client and deal. The share of dialogues with saved history approaches 100% — regardless of who replied and whether the responsible person changed during the correspondence.

First Response Time Stops Being a Blind Spot

Previously, no one measured this metric: the reply went from a personal messenger, and no traces remained. Now every correspondence has a first-touch mark — you can see not only the average but also the tail: how many dialogues hung without an answer for more than an hour.

Request History Lives in the Deal, Not on the Phone

When the responsible person changes, an employee leaves, or the client returns a month later, the context remains in place — from the first request to the last agreement. Repeated clarifications and lost promises made to the client in correspondence disappear.

Dialogue Distribution by Rules, Not by Luck

Routing is configured by direction, workload, and shift schedule: the dialogue goes to an available employee, not to the one who noticed the notification first.

Fewer dialogues are abandoned, and the failure class "the client wrote, but no one saw it" disappears from the statistics.

Client Communication Channels: Official Access and Third-Party Gateways

Connecting WhatsApp to Bitrix24 fits into three scenarios, and the choice between them is dictated not by the interface but by requirements for the business number and the volume of correspondence.

The official communication channel goes through the platform provider: the business account passes verification, the number is assigned to the company, and the dialogue with the client goes into the deal card.

The integration limits are set by the platform itself: outgoing messages outside the open dialogue window are sent only using pre-approved templates, and the number has a limit on new inquiries.

A third-party gateway intermediary, such as Wazzup, bypasses verification but works through an unofficial client — delivery statuses and templates are unavailable, and the number lives under the risk of blocking.

The business number is the main resource in this scheme: a separate line for the channel survives an operator change and does not drag along employees' personal correspondence. Manual transfer remains a temporary measure during launch, not a permanent department workflow.

Procedure for Implementing a Communication Channel in Bitrix24

Connecting a channel is not installing a widget but agreeing on who responds to an inquiry and within what time. First, we analyze how dialogues go now: which numbers are involved, which requests go to the messenger, and where correspondence gets lost between departments.

1. Audit of inquiry scenarios. A list of numbers, typical requests, and handover points — from the first message to the deal. We separate what is appropriate to handle in the messenger from email and telephony.
2. Dialogue routing scheme. Distribution by lines and responsible persons, escalation, work outside the schedule. We agree before enabling — otherwise dialogues go into a common queue and get lost.
3. Channel setup. We link the number via the official API or the integration provider Wazzup, pass verification, and set templates and response rules outside the open correspondence window.
4. Access rights setup. Roles and dialogue visibility, access to attachments and history, linking correspondence to the client card and deal.
5. Acceptance check on live dialogues. We run branches with test inquiries: new and repeat client, non-working hours, unavailable operator, attachment. We check what reaches the deal without losses.
6. Training and handover. Response regulations, operator instructions, review of common errors; we support the first days of the channel's operation.

After that, the channel lives on support: routing edits, new templates, and incident review are introduced without stopping correspondence with clients.

Delivery Package: Templates, Access Rights, Regulations

The work ends not with the message "channel connected" but with a package of settings and documents that the department uses further without us. Below is what exactly remains with the customer after handover and what we check at acceptance.

• Configured channels and queues. The official API and Wazzup are separated by numbers, dialogues are distributed by lines and departments; forwarding during non-working hours and when the queue overflows is configured and tested on test inquiries.
• Access matrix. Roles are described on the principle of least privilege: an operator sees only their lines, a shift supervisor sees all department dialogues, and one or two administrators edit templates and rules. Rights are assigned to groups, so upon dismissal access is revoked along with the account, not manually for each channel.
• Message templates. Greeting, response during non-working hours, request statuses, request for missing data and consent — with substitution of fields from the card so the operator does not type text manually and does not waste time on repetitive answers.
• Escalation regulations. It is fixed what counts as a missed dialogue, how much time is given for the first response, when the shift supervisor gets involved, and who receives the notification; the escalation channel is duplicated outside the messenger.
• Instructions for employees. A short document with screenshots: how to accept a dialogue, send a template, record the result in the deal, what to do on a sending error. It is stored in the Bitrix24 knowledge base and updated together with the rules.
• Actions during failures. The procedure is described for token expiration, number change, and blocking by the messenger: who receives the notification, how to switch lines to a backup channel, and how not to lose open dialogues.
• History and export. It states where correspondence is stored, how to attach it to the deal, and how to export it for reviewing disputed cases.

We hand over the package in working form: we run scenarios on test inquiries, check that messages reach the cards, and only after that do we close the handover.

Case Study: Correspondence from the Messenger Moved into Deal Cards

Before Implementation

The customer is a wholesale company with a sales department of several people. WhatsApp inquiries went to managers' personal phones: the client wrote to whoever's number they had saved, and the dialogue lived outside the system.

When an employee went on vacation or left, the correspondence remained on their phone, and the client was lost — according to the manager's estimate, about half of the inquiries remained unanswered.

What Was Changed

Business numbers were connected via the official API and linked to Bitrix24. An incoming message creates a deal or attaches to an existing one by phone number; the duty schedule distributes dialogues with a forwarding rule if there is no response longer than a specified time. Templates close typical questions, and all correspondence history remains in the card.

What Was Achieved

First response time decreased from several hours to minutes, and the share of unanswered inquiries — from half to zero: every dialogue has an owner and a response deadline.

Managers no longer switch between a personal phone and the card, so one employee handles more dialogues without an increase in workload.

Quality control became measurable: the manager sees all dialogues, not only those they decided to show. Spot checks of responses and a response time report show where the regulations lag — previously, assessment was based on employees' words.

How Does the Official Channel Differ from a Third-Party Gateway?

Both paths bring correspondence into Bitrix24, but they are structured differently. The official channel is a connection through a partner provider: the number is verified on WhatsApp's side and receives a confirmed company profile.

A third-party gateway keeps an open web client session and writes on behalf of the number as an operator would do in a browser.

The risk of blocking is the main difference. The official channel does not eliminate recipient complaints but operates by published rules: there is a warning, speed limiting, and a recovery path.

The gateway is disabled automatically and silently — the logs only show a session break, and dialogue history is lost along with the number.

In terms of launch time, the gap is many times over: the gateway is set up in hours, while the official channel takes weeks for verification and templates.

However, support is structured in the opposite way: the gateway is fixed after every web client update and numbers are re-authorized; the official channel does not need this — efforts go into template quality, not into maintaining the session.

We choose by task: we test a pilot with a small flow on the gateway, while mailings, several operators, and integration with deals are run through the official channel — otherwise, savings at the start turn into a lost number and a repeat launch.

Technical Doubts Before Starting: Review of Common Questions

Before starting, a department head usually checks several things: whether dialogue history will be lost, how several numbers will coexist, who is responsible for the queue, and what to do with an already working integration. The answers below determine the scope of work and the launch procedure.

Can several numbers be connected?

Yes, each number is created as a separate channel with its own rights, templates, and signature. Dialogues do not mix: the client sees which number to write to, and the operator sees which line the request came from.

Numbers can be separated by direction, region, or legal entity while keeping overall reporting in one window.

How are queues and responsible persons configured?

The queue is described by rules: first, the manager assigned to the client responds; if there is no answer, the request goes to the general line and raises a notification to the manager. Every dialogue gets an owner, and the workload is distributed across shifts without manual control.

We already have an integration configured — do we need to redo everything?

Not necessarily. First, we analyze the current scheme: if it relies on an unofficial channel, we move numbers, templates, and scenarios to the official API in stages, leaving the old line in reserve until testing on live dialogues. Bots, funnels, and business processes are preserved.

Let's Discuss the Task and Come Back with an Estimate and Work Plan

For us to come back with a connection scheme and work plan, not general words, it is enough to have the initial data on your setup.

Describe in free form how work with inquiries is currently organized: which numbers are involved, who responds, and at which step the client most often drops off. This is enough to assemble a working scheme, not a template one.

• Current numbers and their status: a personal number linked to an account or a business profile with confirmation — the connection route and timelines depend on this.
• Inquiry scenarios: request intake, deal statuses, reminders, mailings to the database — which templates are needed and where a response should go without an operator.
• Employee roles: who owns the dialogue, who sees correspondence, who closes the deal — from this, the distribution of inquiries within the system is built.
• Control points: first response speed, response quality, escalation when the client is silent — we record them in the plan as acceptance criteria.
• Access on your side: who grants account rights and approves template texts so that work does not stall midway.
• Limitations: what cannot be changed in current processes and which integrations are already working and must not be touched.

Next, we describe the connection scheme in full: message intake, integration with CRM, correspondence history storage, template regulations, and rollback procedure if the scenario does not go as planned.

We break the work plan into stages with control points at each — we check the result before starting the next stage, not at the end of the project.

Describe the task — we will come back with an estimate, connection scheme, and stage-by-stage work plan.