Kommo and WhatsApp: official integration (API) vs unofficial and why this decides if you get banned It is the discussion that separates serious operations from those that will fail suddenly. If you want a “WhatsApp CRM,” the decision that really matters is not the pretty funnel, nor the bot, nor the dashboard: it is connecting via WhatsApp Business Platform (API) through an official provider (BSP) or by unofficial integration via QR code/third party. I've seen accounts get blocked and company numbers disappear — and it almost always starts with the “cheapest and fastest solution.” Cheap ends up very expensive.
I am Luiz Otávio Gonçalves. I come from Mechanical Engineering and became a pioneer in Digital Engineering in Brazil. I implement Kommo CRM and GoHighLevel in real operations, with method, data, and focus on ROI. And when it comes to WhatsApp, I don't improvise: for any serious operation, I only implement official integration. In this article, I will unlock what really changes between official and unofficial: cost, risk, sending limits, templates, 24-hour window, delivery quality, and what you need to plan to avoid getting banned.
What is “official integration (API)” and what is “unofficial (QR)” in practice
Let's get straight to the point, without romanticizing technology.
- Official integration (WhatsApp Business Platform / API): your WhatsApp is connected to Kommo through a official provider (BSP). This is the path supported by Meta for companies that want to scale customer service and automation with governance. Here you work with templates (template messages), conversation rules and charging per conversation, and it has an audit trail.
- Unofficial integration (QR code / “connects as WhatsApp Web”): usually it is a third party that “emulates” WhatsApp Web. You scan a QR code and that's it. It seems magical. It's cheap. It's fast. And it's the shortest path to instability, disconnections, and blocks when the operation grows (volume, automation, multiple agents, IPs, etc.).
If you want predictability, scale, and compliance, the discussion ends here: official. If you want a “quick fix” with low volume and accept operational risk, then you might consider the unofficial — but you have to know the hidden cost.
Why unofficial integration is the fastest way to get banned (and lose the number)
I'll be honest: many people only learn after suffering losses. The ban is not “bad luck.” It is a consequence of operating outside the rules and the standard the platform expects.
The patterns I see causing account bans in unofficial integration:
- Aggressive automation disguised as human: repetitive messages in high volume, mechanical cadence, little variation, and little context.
- Environment switching: multiple logins, multiple devices/servers, frequent reconnections, connector instability. This causes anomalous behavior.
- Use of “chips” and warmed-up numbers the wrong way: they try to scale acquisition using the number as disposable. In a serious company, the number is an asset.
- Without opt-in governance: sending to a cold base, leads that did not request it, or messages out of context. Result: complaints and blocking.
And here is the point no one puts in the spreadsheet: when you get banned, you don't just lose the channel. You lose conversations, customer trust, continuity of service, follow-up, and revenue. If your operation depends on WhatsApp (and almost every SME in Brazil does), this is an existential risk.
Want to build a sustainable operation? Start with the foundation: the official channel.
How Kommo connects WhatsApp officially (the right way)
Kommo is strong at centralizing conversation in the funnel and organizing customer service/sales. But Kommo does not “become official” on its own. Official is the means (WhatsApp Business Platform) and the provider (BSP) that bridges with Meta.
In practice, a well-done official implementation has these steps:
- Define the number: keep the current number (when it makes sense) or create a number dedicated to the API channel.
- Set up the Business Manager: asset structure, permissions, verification (when applicable), and governance.
- Choose a BSP: official provider that offers the connection and management layer (and sometimes additional UI).
- Connect to Kommo: integrate the channel so messages become events in leads, tasks, automations, and reports.
- Implement operational rules: 24-hour window, templates, opt-in, routing, SLA, and metrics.
This is not a “technical setup.” This is operation engineering. And that’s why I emphasize method so much: this is where you protect the channel and create scalable service without relying on heroes.
If you want to understand how I see automation with method (and not guesswork), also read: how to create automation flows from scratch.
What changes the game rules: 24-hour window, templates, and sending
This is the part that most annoys those coming from quick fixes: “before, I sent anything at any time.” Yes. And that’s why you lived at risk.
In the unofficial, you work with two concepts that block the operation at the start — and save the operation in the long run:
- 24-hour window: when the customer sends you a message, it opens a window in which you can respond freely (with rules). After the window, to start a conversation you need a template.
- Templates (template messages): approved messages to start or resume conversations outside the window. Ex.: confirmation, reminder, reactivation, post-sale, collection, order status. This is where you scale follow-up without becoming a spammer.
“Oh, so you can’t sell through official WhatsApp?” You can. What you can’t (or shouldn’t) do is spamming. Serious operations work with:
- Clear opt-in (the customer requested contact)
- Segmentation (right message to the right person)
- smart cadence (timing + context)
- Metric (response rate, first response time, conversion per stage)
If you want to unlock follow-up in a way that increases conversion without burning the number, I recommend complementing with: automatic sales follow-up: what it is and how to build it.
Direct comparison: official (API/BSP) vs unofficial (QR)
I like tables because tables end discussions. Here is the comparison I use with clients before implementing anything:
| Criterion | Official (WhatsApp Business Platform / API via BSP) | Unofficial (QR / “boosted” WhatsApp Web) |
|---|---|---|
| Ban risk | Lower (operates within the platform’s policies and business model) | Higher (anomalous behavior, automation outside the standard, instability, and complaints) |
| Scale (multiple agents) | Made for this | Usually problematic (sessions, disconnections, access concurrency) |
| Templates and 24-hour rules | Yes (requires more mature operation) | Usually “ignores” (until it causes problems) |
| Automation with governance | High (with trail and control) | Low (lots of hacks, little predictability) |
| Cost | Higher and variable (per conversation + possible BSP monthly fee) | Lower and more “fixed” (until it breaks) |
| Long term | Builds asset | Accumulates technical and operational risk |
Cost: what is “real data” and what I will NOT make up here
I won’t throw out a guessed number because that becomes misinformation — and you make the wrong decision.
What is verifiable fact (and does not depend on opinion):
- Kommo charges per user (seat), and this changes according to plan and currency. I keep the values updated on a dedicated page: How much does Kommo CRM cost? Prices and plans in 2026.
- WhatsApp Business Platform (API) charges per conversation and the categories/values vary by country and conversation type (marketing, utility, authentication, service). Meta updates this and you need to check the official source at the time of decision.
- BSP may charge a monthly fee and/or margin in addition to the cost of conversations. Each provider has its commercial policy.
What I see in practice (without making up numbers): when you account for the risk of losing the number, the rework of warming up the channel, the drop in conversion, and the chaos in service, the “cheap” of the unofficial often becomes the biggest cost of the quarter.
If you want to calculate ROI seriously (and not by feeling), here is my standard: how to measure the ROI of business automations.
Who the official integration in Kommo is for (and who it is NOT for)
It's for:
- Operations that treat WhatsApp as critical revenue channel (sales/customer service/after-sales).
- Teams with more than 1 attendant and need for management (SLA, queue, routing).
- Businesses that want automate follow-up with control and metrics.
- Companies that value Predictability and want to scale without relying on “workarounds.”
NOT suitable (or not a priority) for:
- Those who want to do mass messaging to cold lists and call that marketing.
- Those who want to “break rules” because “everyone does it.” Not everyone does — and those who do pay the price.
- Small operation, low volume, where WhatsApp is not a critical channel and you accept risk (then the discussion becomes cost/benefit and tolerance to downtime).
The mistake that breaks the entire operation: choosing the integration before designing the process
The pattern I see most in diagnosis: the company chooses the tool by the “connector” and not by the process. Then they put WhatsApp inside the CRM and think sales are solved. They are not.
The path that delivers ROI is this:
- Map the journey (lead source → qualification → proposal → closing → after-sales).
- Define touchpoints (when it’s human, when it’s automation, when it’s template).
- Implement in Kommo (funnel, fields, rules, automations, routing).
- Connect official WhatsApp (to scale safely).
- Measuring (response rate, response time, conversion per stage, losses due to delay, etc.).
If you’re starting out and want to get the stack choice right (without buying wrong and switching in 60 days), it’s worth reading: how to choose the ideal automation tool.
My practical recommendation (from someone who implements and responds when problems arise)
If you want to use Kommo as a “WhatsApp CRM” and your WhatsApp is the lifeblood of your sales, my recommendation is clear:
- Go with official integration (API/BSP) from the start, or plan a short migration with a set date.
- Treat templates as assets: write, approve, test, and optimize based on response rate.
- Build opt-in and context: ad/landing page/customer service must make clear the client requested contact.
- Monitor signals: drop in response, increase in blocks, complaints, delivery drop. Without data, you only find out when it breaks.
I don’t sell miracles. I build operations that withstand impact. WhatsApp is a channel. A channel without governance becomes a risk. And risk doesn’t scale.
FAQ — real questions about Kommo + official vs unofficial WhatsApp
1) If I use unofficial integration, will I definitely get banned?
There is no “certainty” because risk depends on volume, usage pattern, complaints, and connector stability. What I can say from field experience is: the risk is significantly higher and grows as you automate and scale.
2) Can I use my current WhatsApp Business number on the official (API)?
It depends on the scenario and configuration. In some cases migration is viable; in others, the safest strategy is to use a dedicated number. I decide this based on operational risk (not guesswork).
3) Can I send mass messages on official WhatsApp?
You can send templates to contacts within the rules, with opt-in and policies. “Mass messaging to cold lists” is the kind of thing that destroys number and reputation — official or unofficial.
4) What changes in practice with the 24-hour window?
It means your process needs to be fast and disciplined. Within the window, you can converse more freely. Outside the window, template. This forces the operation to have well-designed SLA and follow-up.
5) Is it worth paying more for official integration?
If WhatsApp is a critical channel, yes — because you are buying continuity, scale and risk reduction. If it’s a secondary channel and low volume, it may not be a priority. The criterion is ROI + risk, not opinion.
If you want me to evaluate your scenario (volume, team, risk, cost per conversation, funnel design and automations) and implement it the right way in Kommo, the next step is simple: request a project.