Kommo + Telegram Bot: a Custom Bot Inside Your Pipeline

A custom Telegram bot connects to Kommo through the Telegram Bot API on the bot side and the Chats API on the CRM side: incoming messages land in your pipeline as deal chats, and your server sends the outgoing ones. This removes the limits of the built-in Salesbot and marketplace widgets - you write any logic you want, map a chat_id to a deal, and drive movement through stages directly via the API. The bot lives inside the pipeline rather than off to the side of it.

The Exceltic.dev team regularly builds these setups for clients on Kommo, and the reason is almost always the same: the company has already tried Salesbot and scenarios in Zapier or Make, hit a ceiling, and now wants branching, external calls, and state - none of which exist in no-code. We see this on projects with a flow of 300 or more conversations a month, where every extra manual touch from a manager costs money.

The typical picture before the switch: Salesbot answers with templates but cannot reach out to an external API for stock levels, does not remember the context of the previous conversation, and breaks on any branching more complex than “yes/no”. The logic sprawls across a widget, Digital Pipeline rules, and three Zap scenarios, and nobody on the team can say anymore exactly where the bot makes a decision.

The operational pain here is not the bot itself, but the gap between it and the pipeline. A lead writes in Telegram, the bot replies, but the deal either is not created or is created without a link to the conversation, and the manager sees an empty card. The qualification the bot already did in the chat never reaches the deal fields, and the person re-asks what the client wrote five minutes ago. Every such gap means both lost conversion and an annoyed lead.

Why the built-in bot and widget are not enough

Kommo offers two native paths to Telegram, and both hit a ceiling on real scenarios. The boundaries are easier to understand if you break down what each one can do.

Salesbot is a visual builder inside Kommo. It handles linear scenarios perfectly: greet, ask a couple of questions, create a task, hand off to a manager. But as soon as you need nonlinear logic, state between messages, or a call to an external service, the builder starts to resist. Conditional transitions exist, but debugging a tree of twenty branches in a visual editor is a job in itself.

The built-in Telegram integration connects an account or a bot as a channel and drops the conversation into the card. This is a messenger channel, not an automation platform: messages are visible, but you still write the behavior logic in Salesbot or Digital Pipeline.

No-code layers like Zapier and Make take away part of the pain but add their own. Each step is a delay and a consumed operation, the conversation state has to be held together with workarounds, and debugging runs through the logs of someone else’s platform. At a flow of thousands of messages a month, the cost of operations and the lag become noticeable, and the scenario still stays fragile.

A custom bot removes the layer entirely. Your code receives the update directly from Telegram, makes a decision with full access to your database, external APIs, and history, and writes the result into the Kommo deal itself. Between the lead and the pipeline there is exactly one component, and you control it.

What gets built technically

The setup rests on two APIs: the Telegram Bot API for talking to the messenger and the Kommo Chats API for recording the conversation into the pipeline. Below are the key pieces you end up assembling on every such project.

Telegram Bot API: receiving updates

A bot is created through @BotFather, which issues a token. From there Telegram delivers updates in one of two mutually exclusive ways - long polling or webhook.

Long polling - the bot itself calls the getUpdates method in a loop, and Telegram keeps the connection open until new messages appear. It does not require SSL or a public address, which makes it convenient for development. One important limitation: two parallel getUpdates calls with the same token are rejected by Telegram with a 409 Conflict error, so a bot like this does not scale horizontally.

Webhook - you call setWebhook with a public HTTPS address, and Telegram sends each update to your server as a POST request. This requires a valid SSL certificate and a port from the list 443, 80, 88, or 8443. This is the production-ready option: lower latency, and the bot can sit behind a load balancer.

Long polling versus webhook

The two modes are mutually exclusive. While a webhook is active, getUpdates returns 409, and vice versa. When switching to polling you first call deleteWebhook, and for the reverse transition you call setWebhook. Telegram stores unaccepted updates for up to 24 hours and then discards them, so a server outage longer than a day means lost messages.

Term: update - the object Telegram sends the bot for every event: a new message, an inline-button press, a change in the chat. It contains the chat and user identifiers, the text, and metadata. It is from the update that the bot pulls the chat_id for the mapping that follows.

The webhook on the Kommo side and mapping chat_id to a deal

Through the Chats API, Kommo sends a webhook for every message dispatched from the CRM interface to the channel. All such webhooks carry an X-Signature header computed with HMAC-SHA1 - you must verify the signature, and run the business logic in the background, because Kommo sends the webhook exactly once and does not retry on failure.

The key to the whole construction is the mapping of the Telegram chat_id to the Kommo deal. When a lead writes for the first time, the bot creates or finds a deal and stores the correspondence chat_id -> lead_id in its own database. After that, the bot places any message from Telegram into the correct deal, and delivers any manager reply from Kommo into the right chat. This mapping table is exactly what no-code layers cannot hold reliably.

How it works step by step

To see the whole thing, here is the route of a single conversation from the first message to the record in the pipeline.

1. A lead writes to the bot in Telegram. Telegram sends an update to your webhook (or the bot fetches it via getUpdates).
2. The bot pulls the chat_id and text, and checks in its database whether a deal already exists for this chat.
3. If there is no deal, the bot creates a deal and a contact via the Kommo API, sets the source, and stores the mapping chat_id -> lead_id.
4. The bot runs its logic: asks qualifying questions, calls external services, branches on the answers, and writes the result into the deal fields.
5. Based on the qualification, the bot moves the deal to the right pipeline stage and creates a task for the manager or hands the conversation over to a human.
6. When the manager replies from the Kommo interface, a Chats API webhook arrives with the X-Signature signature. The bot verifies the signature, finds the chat_id by the lead_id, and delivers the message to Telegram.

From this point the conversation runs both ways through a single component, and the pipeline always reflects the real state of the deal. We covered exactly how stages are laid out for a scenario like this in the piece on how to set up a pipeline in Kommo CRM.

A real case with numbers

To show the order of magnitude, here is a typical project from our practice - a B2B service on Kommo with an inbound flow from Telegram.

Before moving to a custom bot, the company ran on Salesbot plus two scenarios in Make. There were about 1,400 inbound conversations a month, the first manager response took 18 minutes on average, and roughly 55 percent of leads reached the qualification stage without losing context - the rest dropped off on manual re-asks or duplicate cards.

After building a custom bot on a webhook with chat_id mapped to the deal, this is what changed:

• The first meaningful response is instant - the bot qualifies and fills the deal fields itself before a manager even sees it.
• The share of leads that reached qualification with preserved context rose from 55 to 89 percent.
• Operation consumption in Make went to zero - around 14,000 operations a month are no longer being paid for.
• Managers stopped duplicating cards: the chat_id -> lead_id mapping guarantees one deal per conversation.

The numbers for a specific project depend on the flow and the complexity of the scenario, but the direction repeats: the layer is removed, the gaps between chat and pipeline disappear, and the share of manual touches drops. We pulled together the baseline set of CRM capabilities a bot like this relies on in our overview of Kommo CRM features.

Who this is right for

A custom bot is not justified for everyone - it solves a specific class of tasks. Let us break down who actually needs it.

The setup makes sense if you have a flow of several hundred conversations a month, the scenario does not fit into Salesbot’s linear tree, and the bot needs to reach into external systems - to check stock, calculate a price, query your database or a third-party service. Another signal: you already pay for operations in Zapier or Make and are running into their limits or delays.

If, on the other hand, the scenario is simple - greet, ask two questions, create a task - the built-in Salesbot is enough, and there is no point in building custom. The line is drawn where state between messages appears, branching more complex than a couple of conditions, or integration with a system that is not in the marketplace.

It is also worth being honest about the resources: a custom bot is code that needs to be hosted, monitored, and updated to keep up with changes in the Telegram Bot API and the Kommo API. If your team has no developer and no contractor for support, it is better to start with what Kommo offers out of the box. Exactly what the platform includes is easy to check against the Kommo CRM overview before deciding on custom.

Frequently asked questions

How is a custom bot different from Salesbot in Kommo?

Salesbot is a visual builder inside Kommo for linear scenarios: a greeting, a couple of questions, creating a task. A custom bot is your code on a server that talks to Telegram through the Bot API and writes into the pipeline through the Kommo Chats API. The difference is the ceiling: custom can hold state between messages, reach into external APIs, do arbitrary branching, and keep a mapping table of chats and deals. In return, you pay with the need to host and maintain code, whereas Salesbot works out of the box with no infrastructure.

Webhook or long polling - which to choose for production?

For production, webhook. Telegram sends the updates to your HTTPS address itself, latency is lower, and the bot can sit behind a load balancer. You need a valid SSL certificate and port 443, 80, 88, or 8443. Long polling is simpler for development and does not require a public address, but it does not scale: two parallel getUpdates calls with the same token are rejected by Telegram with a 409 Conflict error. The modes are mutually exclusive - before switching to polling you call deleteWebhook.

How does one deal stay tied to one conversation?

That is handled by the chat_id -> lead_id mapping table in the bot’s database. On a lead’s first message, the bot creates a deal in Kommo and stores the link between the Telegram chat identifier and the deal identifier. After that, the bot places any incoming message into the same deal, and delivers a manager’s reply from Kommo into the right chat. It is precisely this durable mapping that no-code layers usually lack, which is what causes duplicate cards and lost context.

Is it safe to accept webhooks from Kommo?

Yes, if you verify the signature. Every Chats API webhook carries an X-Signature header computed with HMAC-SHA1. Your server must recompute the signature from the request body and the secret and compare them - that is how you cut off forged requests. An important detail: Kommo sends the webhook exactly once and does not retry it if processing fails, so you verify the signature immediately and move the heavy business logic into background processing, so you can return a response quickly and not lose the event.

How long does it take to build such a setup?

It depends on the complexity of the scenario. The basic loop - receiving updates, creating a deal, mapping the chat_id, two-way message delivery - comes together in a few days. After that, the time goes into the bot’s own logic: qualification, branching, integrations with external systems, and movement through pipeline stages. Hosting, monitoring, and handling edge cases (repeated messages, a server outage longer than 24 hours, a token change) add their own share. A realistic estimate is from one to several weeks for a production version.

The bottom line

A custom Telegram bot in a Kommo pipeline is needed where the built-in Salesbot and no-code layers have hit a ceiling: at a flow of hundreds of conversations, nonlinear logic, and the need to reach into external systems. Technically it is a combination of the Telegram Bot API and the Kommo Chats API with a durable mapping of chat_id to the deal - it removes the gaps between chat and pipeline, the duplicate cards, and the operation consumption on third-party platforms.

If you are already on Kommo and have run into the limits of Salesbot, Zapier, or Make, you can come to Exceltic.dev with a concrete scenario and work out where the line falls between built-in tools and custom in your particular flow. The starting point is the home page, and from there a focused conversation about your pipeline.

Documentation for technical verification: Telegram Bot API, Kommo Chats API webhooks, and general Kommo developer documentation.