First DM capture: connecting a bot to Telegram Business

A person who clicks your ad and writes straight to the manager used to be invisible. The tracker knows the people who pressed /start on your bot, and someone who skipped the bot entirely left no row anywhere. Telegram Business changes that: a bot connected to the manager's own account receives the messages of the chats they hand it, and the first inbound message from a new person becomes a first_dm event tied to a click. This guide is the whole exchange - what the manager has to do, what the bot receives, what it costs, and what it still cannot give you.

What the manager does in their own Telegram

Connecting happens outside Leadgram, on the manager's side: Settings → Telegram Business → Chatbots, add your bot, then pick the chats it serves. Nothing outside your manager's account can do it for them.

Checking it from outside is impossible too. We learn about a connection only from the update Telegram sends the bot at the moment it is connected, so until that arrives the First DM capture card on the Bots page says the bot is not connected to any account - and it is telling the truth about everything we know.

The second step is ours, on the same card: Capture mode starts at Off for every bot, and while it sits there no event is written for that bot. Both steps have to be done. Miss either one and the counter stays at zero, with nothing on either side reporting an error.

There is no retrospective. Messages sent before the connection are not handed over by Telegram, so the first day of capture starts at zero instead of filling in last week.

Telegram Premium is not required

Connecting a business bot does not require Telegram Premium - Telegram documents connected bots as available to non-Premium users as well. Premium is what the manager needs for the other business features: working hours, quick replies, greeting messages, business chat links. Handing chats to a bot is not one of them.

So if a manager cannot connect, Premium is not the first thing to check. The next section is.

One business bot per account, and Business Mode

A Telegram account can have only one business bot connected at a time. If the manager already has another one - a CRM, an autoresponder, an assistant - ours will either not show up in their list or be refused at connection; the other one has to be disconnected first. Agencies hit this most often, for the obvious reason: they are the most likely to already run a bot on that account.

The second requirement sits on the bot rather than on the account. Business Mode has to be turned on for it in @BotFather, and while it stays off the bot is simply absent from the Telegram Business chatbot list, however hard the manager looks for it. We read that flag from Telegram when the bot is added, so the card names this case when it knows the answer - and says nothing rather than guessing when it has never asked.

What the bot receives and what we process

This is what the client has to read before the bot is connected. It is the same paragraph the connection card prints, word for word:

Receiving and processing are two different words on purpose. Telegram has no "first message only" subscription: the update a connected bot gets is every message of the chats the client picked, and "first" is decided on our side, by us, on each message that arrives. Anyone promising that the bot reads only the first one is describing something Telegram does not offer.

Whether the bot can reply is a separate switch in the manager's own settings, and it has no effect on receiving. The card states which way it is set for the connected account.

The draft link

Attribution needs something in the message itself. The campaign's target URL becomes a Telegram draft link:

https://t.me/<manager_username>?text=lg-{click_id}

{click_id} is substituted at redirect time; the person arrives in the chat with lg-cm4x8... already in the input box and sends it as their first message. That token is the only direct evidence tying a DM to a click, and Delivery Health shows what share of first DMs arrived carrying one.

Three conditions come with it:

• The manager needs a public @username. The draft opens by that name and no other. Without one there is nothing to build the link from, and the card says so instead of printing a broken one.
• Cyrillic prose in the draft text has to be percent-encoded by you. The redirect builds the destination out of the string as written, deliberately without re-serializing it, so that it never breaks anyone else's macros. Non-ASCII text in the query travels exactly as you typed it.
• The person can clear the draft before sending. Then no token arrives and the DM falls back to a guess from whatever else is known about that Telegram account. A share of DMs stays unattributed permanently. That is the shape of Telegram, not a defect waiting for a fix.

What this changes on your bill

first_dm is a paid event type, and it brings in a class of charge that did not exist before you turned it on.

• A person who arrives straight into the DM is a new billable subscriber. Someone you have already paid for - they pressed /start on your bot at some point - settles as free, because a Telegram account is matched once per workspace with no expiry. Someone who only ever wrote to the manager was never billed, for the simple reason that the tracker never saw them. Now it does, and they are billed like any other first billable event.
• A first_dm reported without a Telegram id is not automatically free. From a connected bot the sender's id is always there, so this concerns only the events you report yourself over the API. Depending on how weak-identity billing is configured on your workspace, such an event either settles free or is billed on the weak ladder - cookie, device or click. Which of the two your workspace is on is a question for support.

Pushes on first_dm

first_dm can trigger a push, and it stays a trigger - but read what delivery needs before you build a flow on it. A push is delivered through the bot's subscribers, keyed by the pair (bot, chat). A person who only ever wrote to the manager has no such row: they never opened your bot. A push armed on their first_dm arms and never sends.

The trigger is therefore useful for people who did both - wrote to the manager and started the bot at some point - and inert for exactly the audience this feature exists to capture. Nothing reports an error, because nothing failed: there is no address to send to. Pushes covers the rest of the delivery rules.

MTProto: our position

The other way to see a first DM is a user session - MTProto, the protocol the Telegram apps themselves speak. We do not run user sessions and we are not going to. This is a position, not a backlog item.

A user session is the client's phone number, their login code and their second-factor password, living on our server. A stolen session is a full takeover of a personal account, not a leaked bot token: messages, contacts, every other chat, all of it. The product has an established home for bot tokens - encrypted at rest, fingerprinted, and confined to an allowlist of Telegram methods - and nothing of the sort for sessions: no storage, no method allowlist, no revocation model. Telegram may also block the client's own account for automation.

The gap that leaves is real, and it is named above: someone who clears the draft and never touched your bot cannot be tied to a click. We would rather report that share honestly on Delivery Health than keep a client's personal account on our disk.