Appearance
Business bots
Not implemented
No part of this works yet — the gateway route is live, but no bot token can be issued, so no method can be called. See implementation status.
Specified in outline only
Business bots exist in the project TZ as B21, at priority P2, in about a page of description. There is no schema, no update payload definition, no rights enumeration, and no implementation behind it.
What follows is that outline plus the Telegram semantics it is modelled on. Read it to understand the shape and the risk, not to build against — the details that matter most for a correct integration are precisely the ones not yet written down.
What makes these different
Every other kind of bot on this platform speaks as itself. A user sees the bot's name, the bot's avatar, and knows they are talking to software.
A business bot does not. It is connected by a human account holder and replies in that person's private chats, as that person. The customer on the other side is having a conversation with a name and a face they recognise. This is built for AI assistants and CRM integrations — the case where a business wants automated first-line replies without the customer being bounced to a separate support bot.
That inversion is the whole feature, and it is also the whole risk. Everything below follows from it.
Connecting
The user connects the bot from their own settings — GROM Business → Chatbots — by entering the bot's username. The bot is not the one initiating this, and it cannot be: there is no method that lets a bot request a business connection. The human starts it, always.
At connection time the user chooses:
- Which chats. All of them, only existing ones, only new ones, or all with an exclusion list.
- Which rights. Reading, replying, deleting, sending media, gift management, and others.
The bot then receives a bot_business_connect update carrying a connection_id, the user_id of the account it now acts for, the granted rights, and an is_enabled flag.
The connection id is the whole permission
connection_id is not a session token or a convenience handle — it is the credential that says this bot may act as this person, within these limits. Store it as carefully as you store the bot token itself, and keep it out of log lines, error reports and crash dumps.
Operating
Once connected, the bot passes business_connection_id on the methods it calls. Messages it sends carry via_business_bot_id, and clients display them with an indicator showing a bot sent them — the account holder can see what went out under their name, and undo it.
Incoming activity arrives as its own update types, separate from ordinary bot updates:
| Update | Meaning |
|---|---|
business_message | A message in a connected chat |
edited_business_message | A message in a connected chat was edited |
deleted_business_messages | Messages in a connected chat were deleted |
bot_business_connect | The connection was created, or its rights or enabled state changed |
Handle these on a distinct code path from your normal updates. They are not the bot's own conversations, and treating them as such is how a business bot ends up replying to a customer with a /start menu.
The permission boundary
This is the part worth being careful about, and the part the specification currently says the least about.
A business bot sees only the chats the user permitted. Not all of the account's chats. Not history from before it was connected, beyond what the connection scope grants. The exclusion list exists specifically so a person can keep some conversations out of reach of software they installed, and honouring it is not optional politeness — it is the boundary the user was shown when they agreed.
Rights can change at any moment. When they do, a fresh bot_business_connect arrives with the new set. The rights you cached at connection time may already be stale by the time you act on them.
Do not cache rights and assume they hold
The pattern that fails: read rights once on connect, store it, and check against the stored copy from then on. A user who revokes the ability to delete messages — or disables the connection entirely — expects that to take effect immediately. A bot acting on a stale grant is acting outside its permission, under a real person's name, in a conversation with their customer.
Re-read rights from every bot_business_connect update, and treat is_enabled: false as a full stop rather than a flag to check later.
The account holder is accountable for what you send. Their customer sees their name. A bot that replies confidently and wrongly does not embarrass the bot's developer — it embarrasses the business that connected it. Build in an escalation path to a human, and make it easy to reach; a business bot that cannot say "let me get someone" is worse than no business bot.
What is not specified yet
Being concrete about the gaps, since you cannot build around a gap you have not been told about:
- The exact field names and types of the rights object.
- Which methods accept
business_connection_id, and what happens when one that does not is called with it. - Whether the bot can read history from before the connection, and how far back.
- How a connection ends — revocation, expiry, what the bot is told, whether it is told at all.
- Rate limits for business-connection traffic, which are not in limits because they have not been set.
If you are planning a CRM or assistant integration, these are the questions to ask before writing code, not after.
Today
Nothing here can be attempted. There is no gateway, no token, no way for a user to connect a bot, and no update to receive.
If you already run something like this on another platform, the transferable work is the part that has nothing to do with the API: knowing when to answer and when to hand off, and keeping the reply quality high enough to be worth putting someone's name on. That part ports. The integration does not exist yet.