Inline bots and what they actually receive
Most people who’ve used Telegram for more than a week have typed @somebot into a chat, watched a row of results pop up, tapped one, and moved on. It feels local, like autocomplete. It isn’t. The moment you type that query, it leaves your device, goes through Telegram’s servers, and lands on whatever machine the bot’s developer is running. What we want to walk through here is exactly what “lands on” means: which fields actually cross that wire, which ones don’t, and why that matters if you run communities, manage bots, or just care about what a stranger’s code can see about you.
What happens when you type @botname
Inline mode is a specific feature a bot developer turns on through BotFather with the /setinline command. Once it’s on, typing @botname followed by text in any chat, whether it’s a DM, a group, or a channel you can post in, triggers Telegram’s client to send an InlineQuery update to that bot. This happens over the same Bot API channel the bot already uses for everything else, either a webhook the developer’s server exposes or a long-polling connection the bot maintains to Telegram’s servers.
The client debounces this a bit as you type, so it’s not firing a request on every keystroke, but functionally the query text you’re building gets sent to the bot’s backend before you’ve even picked a result. The bot then has to respond within a few seconds with a list of results, which Telegram renders back to you in that dropdown. If you don’t select anything and just close the chat or delete your text, the bot already saw what you typed. There’s no undo on that.
The fields inside an inline query
The InlineQuery object the bot receives has a small, fixed set of fields:
id: a unique identifier for this particular query, used later if you select a result.from: the Telegram user object for whoever is typing. This includes your numeric Telegram user ID, your first and last name as set on your account, your username if you have one, and your language code.query: the literal text you typed after the bot’s username.offset: used for pagination when you scroll through results.chat_type: the category of chat the query was sent from, one ofsender,private,group,supergroup, orchannel. This tells the bot roughly where it’s being invoked, not which chat.location: only present if the bot requested location access when it registered, and only if you’ve granted Telegram permission to share it. Plenty of inline bots never ask for this and never receive it.
That’s the entire payload. No message history from the chat, no list of other members, no chat title, no chat ID. The bot gets a user, a string, and maybe a location. Everything else about the environment you’re typing in is invisible to it by design.
What the bot never sees
This is the part worth sitting with if you’re used to thinking about regular bots added to a group. A regular group bot, once it’s a member, can see messages in that group according to its privacy mode setting, and if privacy mode is off or it’s an admin, it sees everything that flows through. An inline bot doesn’t need to be a member of anything. It’s never added to your group, never appears in the member list, and has no mechanism to pull the chat’s history even if it wanted to. The chat_type field is the only concession Telegram makes toward giving the bot context, and it was added specifically so bots could tailor results without ever learning which actual chat, group, or channel you’re in.
Practically, this means a bot that only offers inline mode and isn’t also added as a normal member has no path to your conversation. It only knows what you typed after its @-mention and who you are as a Telegram account. If you’re vetting a bot for use in a sensitive group and the developer is only asking for inline access, the blast radius of what they can collect is limited to query strings and user IDs, not your group’s content.
Chosen inline result and inline_message_id
If the bot developer enables inline feedback in BotFather, Telegram will also send a ChosenInlineResult update after you tap a result. This carries the result_id of what you picked, the same from user object, the original query text, and optionally an inline_message_id. That last field is an opaque token the bot can use to edit the message it just posted, useful for things like live-updating scores or expiring links, but it isn’t a chat ID and can’t be reverse-engineered into one. The bot can push an edit to that specific message through the API without ever learning which chat it landed in.
Inline feedback is off by default because most bots don’t need it, and turning it on adds a bit of load since Telegram has to report back on selections. If you’re building a bot and don’t have a reason to edit messages after the fact, there’s no reason to enable it.
Inline bots versus bots sitting in your group
We host a fair number of bots for people running communities, and the question that comes up most is some version of “if I add this bot, what can it read.” For a normal bot added as a member, the honest answer is that it depends entirely on privacy mode, which the bot’s developer controls, not you. Default privacy mode limits the bot to seeing commands directed at it and messages that mention it. Disabled privacy mode, which many moderation and logging bots require to function, means the bot sees every message posted in that group while it’s a member.
Inline bots sidestep that entire question because membership isn’t part of the equation. That’s a real advantage if you want functionality, like a search tool, a sticker picker, or a quick lookup, without giving a third party’s code standing access to your group’s message stream. It’s also why a lot of utility bots are built inline-only: it’s the smaller surface area, and it’s the one users can reason about without trusting a developer’s word on privacy settings.
Where proxies fit and where they do not
Since we spend most of our time on proxy configuration for Telegram accounts, it’s worth being precise about where that layer stops mattering. An MTProto proxy, or a SOCKS5 proxy in front of a Telegram client, controls the network path between your device and Telegram’s servers. It changes what IP address Telegram sees you connecting from and can help with censorship or regional routing. It has no effect on what an inline bot receives once your query reaches Telegram’s servers and gets forwarded to the bot’s backend. That leg of the trip, from Telegram to the bot, is entirely separate from your leg, from your device to Telegram, and a bot never learns your IP or your connection details either way. Your proxy setup is about protecting your connection to Telegram. It’s not a privacy control for what happens after you invoke a bot.
Practical account safety notes
The habit worth building is treating an inline query the same way you’d treat text typed into a search bar owned by someone else. Whatever you type after @botname is logged on that bot’s server the instant you type it, whether or not you tap a result. Your Telegram user ID goes with it every time, which means a bot operator can correlate multiple queries from the same account over time even if you never message them directly. If you’re running a bot for your own community, this cuts both ways: you inherit that same query log and user ID stream for everyone who uses your bot, which is a responsibility, not just a feature. Don’t type account credentials, API keys, or anything you wouldn’t paste into a stranger’s form, into an inline query, because functionally that’s what you’re doing.
If you’re hosting bots yourself and want the underlying infrastructure and proxy routing set up correctly so your own inline bots behave predictably under load, that’s exactly the kind of setup work we do at telegramvault.org.
Get new guides and videos first — join the Telegram channel.